draft-ietf-netmod-smi-yang-01.txt   draft-ietf-netmod-smi-yang-02.txt 
Network Working Group J. Schoenwaelder Network Working Group J. Schoenwaelder
Internet-Draft Jacobs University Internet-Draft Jacobs University
Intended status: Standards Track July 1, 2011 Intended status: Standards Track November 25, 2011
Expires: January 2, 2012 Expires: May 28, 2012
Translation of SMIv2 MIB Modules to YANG Modules Translation of SMIv2 MIB Modules to YANG Modules
draft-ietf-netmod-smi-yang-01 draft-ietf-netmod-smi-yang-02
Abstract Abstract
YANG is a data modeling language used to model configuration and YANG is a data modeling language used to model configuration and
state data manipulated by the NETCONF protocol, NETCONF remote state data manipulated by the NETCONF protocol, NETCONF remote
procedure calls, and NETCONF notifications. The Structure of procedure calls, and NETCONF notifications. The Structure of
Management Information (SMIv2) defines fundamental data types, an Management Information (SMIv2) defines fundamental data types, an
object model, and the rules for writing and revising MIB modules for object model, and the rules for writing and revising MIB modules for
use with the SNMP protocol. This document defines a translation of use with the SNMP protocol. This document defines a translation of
SMIv2 MIB modules into YANG modules, enabling read-only access to SMIv2 MIB modules into YANG modules, enabling read-only access to
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 2, 2012. This Internet-Draft will expire on May 28, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 8 skipping to change at page 3, line 8
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Mapping of Special Types . . . . . . . . . . . . . . . . . . . 5 2. Mapping of Well Known Types . . . . . . . . . . . . . . . . . 5
3. Module Prefix Generation . . . . . . . . . . . . . . . . . . . 6 3. Translation of SMIv2 Modules and SMIv2 IMPORT Clauses . . . . 6
4. Translation of SMIv2 Modules and SMIv2 IMPORT Clauses . . . . 7 3.1. Example: IMPORTS of IF-MIB . . . . . . . . . . . . . . . . 7
4.1. Example: IMPORTS of IF-MIB . . . . . . . . . . . . . . . . 8 4. Translation of the MODULE-IDENTITY Macro . . . . . . . . . . . 8
5. Translation of the MODULE-IDENTITY Macro . . . . . . . . . . . 9 4.1. MODULE-IDENTITY Translation Rules . . . . . . . . . . . . 8
5.1. MODULE-IDENTITY Translation Rules . . . . . . . . . . . . 9 4.2. Example: MODULE-IDENTITY of IF-MIB . . . . . . . . . . . . 9
5.2. Example: MODULE-IDENTITY of IF-MIB . . . . . . . . . . . . 10 5. Translation of the TEXTUAL-CONVENTION Macro . . . . . . . . . 10
6. Translation of the TEXTUAL-CONVENTION Macro . . . . . . . . . 11 5.1. TEXTUAL-CONVENTION Translation Rules . . . . . . . . . . . 10
6.1. TEXTUAL-CONVENTION Translation Rules . . . . . . . . . . . 11 5.2. Example: OwnerString and InterfaceIndex of IF-MIB . . . . 11
6.2. Example: OwnerString and InterfaceIndex of IF-MIB . . . . 11 5.3. Example: IfDirection of the DIFFSERV-MIB . . . . . . . . . 11
6.3. Example: IfDirection of the DIFFSERV-MIB . . . . . . . . . 12 6. Translation of OBJECT IDENTIFIER Assignments . . . . . . . . . 13
7. Translation of OBJECT IDENTIFIER Assignments . . . . . . . . . 14 7. Translation of the OBJECT-TYPE Macro . . . . . . . . . . . . . 14
8. Translation of the OBJECT-TYPE Macro . . . . . . . . . . . . . 15 7.1. Scalar and Columnar Object Translation Rules . . . . . . . 14
8.1. Scalar and Columnar Object Translation Rules . . . . . . . 15 7.2. Example: ifNumber and ifIndex of the IF-MIB . . . . . . . 15
8.2. Example: ifNumber and ifIndex of the IF-MIB . . . . . . . 16 7.3. Non-Augmenting Conceptual Table Translation Rules . . . . 16
8.3. Non-Augmenting Conceptual Table Translation Rules . . . . 16 7.4. Example: ifTable of the IF-MIB . . . . . . . . . . . . . . 18
8.4. Example: ifTable of the IF-MIB . . . . . . . . . . . . . . 18 7.5. Example: ifRcvAddressTable of the IF-MIB . . . . . . . . . 18
8.5. Example: ifRcvAddressTable of the IF-MIB . . . . . . . . . 18 7.6. Example: alHostTable of the RMON2-MIB . . . . . . . . . . 20
8.6. Augmenting Conceptual Tables Translation Rules . . . . . . 20 7.7. Augmenting Conceptual Tables Translation Rules . . . . . . 21
8.7. Example: ifXTable of the IF-MIB . . . . . . . . . . . . . 21 7.8. Example: ifXTable of the IF-MIB . . . . . . . . . . . . . 22
9. Translation of the OBJECT-IDENTITY Macro . . . . . . . . . . . 22 8. Translation of the OBJECT-IDENTITY Macro . . . . . . . . . . . 24
9.1. OBJECT-IDENTITY Translation Rules . . . . . . . . . . . . 22 8.1. OBJECT-IDENTITY Translation Rules . . . . . . . . . . . . 24
9.2. Example: diffServTBParamSimpleTokenBucket of the 8.2. Example: diffServTBParamSimpleTokenBucket of the
DIFFSERV-MIB . . . . . . . . . . . . . . . . . . . . . . . 22 DIFFSERV-MIB . . . . . . . . . . . . . . . . . . . . . . . 24
10. Translation of the NOTIFICATION-TYPE Macro . . . . . . . . . . 23 9. Translation of the NOTIFICATION-TYPE Macro . . . . . . . . . . 25
10.1. NOTIFICATION-TYPE Translation Rules . . . . . . . . . . . 23 9.1. NOTIFICATION-TYPE Translation Rules . . . . . . . . . . . 25
10.2. Example: linkDown NOTIFICATION-TYPE of IF-MIB . . . . . . 23 9.2. Example: linkDown NOTIFICATION-TYPE of IF-MIB . . . . . . 25
11. YANG Language Extension Definition . . . . . . . . . . . . . . 26 10. YANG Language Extension Definition . . . . . . . . . . . . . . 28
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
13. Security Considerations . . . . . . . . . . . . . . . . . . . 30 12. Security Considerations . . . . . . . . . . . . . . . . . . . 33
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
14.1. Normative References . . . . . . . . . . . . . . . . . . . 31 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
14.2. Informative References . . . . . . . . . . . . . . . . . . 31 14.1. Normative References . . . . . . . . . . . . . . . . . . . 35
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32 14.2. Informative References . . . . . . . . . . . . . . . . . . 35
Appendix A. Mapping of Well Known Types (normative) . . . . . . . 37
Appendix B. Module Prefix Generation (informative) . . . . . . . 40
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
This document describes an translation of SMIv2 [RFC2578], [RFC2579], This document describes a translation of SMIv2 [RFC2578], [RFC2579],
[RFC2580] MIB modules into YANG [RFC6020] modules, enabling read-only [RFC2580] MIB modules into YANG [RFC6020] modules, enabling read-only
access to data objects defined in SMIv2 MIB modules via NETCONF. The access to data objects defined in SMIv2 MIB modules via NETCONF. The
mapping is illustrated by examples showing the translation of part of mapping is illustrated by examples showing the translation of part of
the IF-MIB [RFC2863] SMIv2 module and the DIFFSERV-MIB [RFC3289] the IF-MIB [RFC2863] SMIv2 module and the DIFFSERV-MIB [RFC3289]
SMIv2 module. SMIv2 module.
SMIv1 modules may be converted to YANG by first following the rules
in [RFC3584] to convert the SMIv1 module to SMIv2, then following the
rules in this document to convert to YANG.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14, [RFC2119]. 14, [RFC2119].
2. Mapping of Special Types 2. Mapping of Well Known Types
The SMIv2 base types and some well known derived textual-conventions The SMIv2 base types and some well known derived textual-conventions
are mapped to YANG types according to Table 1. The mapping of the are mapped to YANG types according to Appendix A. The mapping of the
OCTET STRING depends on the context. If an OCTET STRING type has an OCTET STRING depends on the context. If an OCTET STRING type has an
associated DISPLAY-HINT, then the corresponding YANG base type is the associated DISPLAY-HINT, then the corresponding YANG base type is the
string type. Otherwise, the binary type is used. Similarly, the string type. Otherwise, the binary type is used. Similarly, the
mapping of the INTEGER type depends on its usage as an enumeration or mapping of the INTEGER type depends on its usage as an enumeration or
a 32-bit integral type. Implementations are encouraged to provide a 32-bit integral type. Implementations are encouraged to provide
options to handle situations where DISPLAY-HINTs are added during a options to handle situations where DISPLAY-HINTs are added during a
revision of a module and backwards compatibility must be preserved. revision of a module and backwards compatibility must be preserved.
Mapping of SMIv2 types to YANG types The mappings shown in Appendix A may impact the imports of the
generated YANG module since some SMIv2 types and textual-conventions
+------------+----------------+-----------------+-------------------+ map to YANG types defined in the ietf-yang-types and ietf-inet-types
| SMIv2 | SMIv2 Type | YANG Module | YANG Type | YANG modules [RFC6021]. Implementations MUST add any additional
| Module | | | | imports required by the type mapping.
+------------+----------------+-----------------+-------------------+
| SNMPv2-SMI | INTEGER | | enumeration |
| SNMPv2-SMI | INTEGER | | int32 |
| SNMPv2-SMI | Integer32 | | int32 |
| SNMPv2-SMI | OCTET STRING | | binary |
| SNMPv2-SMI | OCTET STRING | | string |
| SNMPv2-SMI | OBJECT | ietf-yang-types | object-identifier |
| | IDENTIFIER | | |
| SNMPv2-SMI | BITS | | bits |
| SNMPv2-SMI | IpAddress | ietf-inet-types | ipv4-address |
| SNMPv2-SMI | Counter32 | ietf-yang-types | counter32 |
| SNMPv2-SMI | Gauge32 | ietf-yang-types | gauge32 |
| SNMPv2-SMI | TimeTicks | ietf-yang-types | timeticks |
| SNMPv2-SMI | Opaque | | binary |
| SNMPv2-SMI | Counter64 | ietf-yang-types | counter64 |
| SNMPv2-SMI | Unsigned32 | | uint32 |
| SNMPv2-TC | PhysAddress | ietf-yang-types | phys-address |
| SNMPv2-TC | MacAddress | ietf-yang-types | mac-address |
| SNMPv2-TC | TimeStamp | ietf-yang-types | timestamp |
+------------+----------------+-----------------+-------------------+
Table 1
The mappings shown in Table 1 may impact the imports of the generated
YANG module since some SMIv2 types and textual-conventions map to
YANG types defined in the ietf-yang-types and ietf-inet-types YANG
modules [RFC6021]. Implementations MUST add any additional imports
required by the type mapping.
3. Module Prefix Generation
The input of the prefix generation algorithm is a set of prefixes
(usually derived from imported module names) and a specific module
name to be converted into a prefix. The algorithm described below
produces a prefix for the given module name that is unique within the
set of prefixes.
Special prefixes for well known SMIv2 and YANG modules
+---------------------+--------+
| YANG / SMIv2 Module | Prefix |
+---------------------+--------+
| ietf-yang-types | yang |
| ietf-inet-types | inet |
| ietf-yang-smiv2 | smiv2 |
+---------------------+--------+
Table 2
o First, some predefined translations mapping well known SMIv2 and
YANG modules to short prefixes are tried (see Table 2). If a
fixed translation rule exists and leads to a conflict free prefix,
then the fixed translation is used.
o Otherwise, prefixes are generated by tokenizing an SMIv2 module
name, using hyphens as token separators. The tokens derived from
a module name are converted to lowercase characters. The prefix
then becomes the shortest sequence of token concatenated using
hyphens as separators, which includes at least two token and which
is unique among all prefixes used in the YANG module.
In the worst case, the prefix derived from an SMIv2 module name
becomes the SMIv2 module name translated to lower-case. But on
average, much shorter prefixes are generated.
4. Translation of SMIv2 Modules and SMIv2 IMPORT Clauses 3. Translation of SMIv2 Modules and SMIv2 IMPORT Clauses
SMIv2 modules are mapped to corresponding YANG modules. The YANG SMIv2 modules are mapped to corresponding YANG modules. The YANG
module name MUST be the same as the SMIv2 module name. module name MUST be the same as the SMIv2 module name.
The YANG namespace MUST be constructed out of a constant prefix, The YANG namespace MUST be constructed out of a constant prefix
which followed by the SMIv2 module name. Since SMIv2 module names followed by the SMIv2 module name. Since SMIv2 module names can be
can be assumed to be unique (see Section 3 in [RFC2578]), the assumed to be unique (see Section 3 in [RFC2578]), the resulting YANG
resulting YANG namespace is unique. The registered prefix is namespace is unique. The registered prefix is
urn:ietf:params:xml:ns:yang:smiv2:, see the IANA considerations in urn:ietf:params:xml:ns:yang:smiv2:, see the IANA considerations in
Section 12. Section 11.
The YANG prefix MAY be derived from the SMIv2 module name using the The YANG prefix MAY be derived from the SMIv2 module name using the
module prefix generation algorithm described in Section 3. The YANG module prefix generation algorithm described in Appendix B. The YANG
prefix is supposed to be short and it must be unique within the set prefix is supposed to be short and it must be unique within the set
of all prefixes used by a YANG module. The algorithm described in of all prefixes used by a YANG module. The algorithm described in
Section 3 generates such prefixes. Appendix B generates such prefixes.
SMIv2 IMPORT clauses are translated to YANG import statements. One SMIv2 IMPORT clauses are translated to YANG import statements. One
major difference between the SMIv2 import mechanism and the YANG major difference between the SMIv2 import mechanism and the YANG
import mechanism is that SMIv2 IMPORT clauses import specific symbols import mechanism is that SMIv2 IMPORT clauses import specific symbols
from an SMIv2 module while the YANG import statement imports all from an SMIv2 module while the YANG import statement imports all
symbols of the referenced YANG module. symbols of the referenced YANG module.
SMIv2 imports that are ignored in YANG In order to produce correct and complete YANG import statements, the
following rules MUST be used:
+--------------+--------------------+ o Process each item in each SMIv2 IMPORT clause as follows:
| SMIv2 Module | SMIv2 Symbol |
+--------------+--------------------+
| SNMPv2-SMI | MODULE-IDENTITY |
| SNMPv2-SMI | OBJECT-IDENTITY |
| SNMPv2-SMI | OBJECT-TYPE |
| SNMPv2-SMI | NOTIFICATION-TYPE |
| SNMPv2-SMI | mib-2 |
| SNMPv2-TC | TEXTUAL-CONVENTION |
| SNMPv2-MIB | snmpTraps |
| SNMPv2-SMI | * all symbols * |
| SNMPv2-CONF | * all symbols * |
+--------------+--------------------+
Table 3 1. If an import statement for this SMIv2 module has already been
generated, then ignore this item.
In order to produce correct and complete YANG import statements, the 2. Otherwise, if the SMIv2 module name is SNMPv2-SMI or SNMPv2-
following rules MUST be used: CONF, then ignore this item. Note that these two modules can
be completely ignored since all definitions in these modules
are translated by translation rules.
o Ignore all imports listed in Table 3. Note that the modules 3. Otherwise, if this item is a textual convention matching one
SNMPv2-SMI and SNMPv2-CONF are completely ignored since all of the textual conventions in the SMIv2 types column of
definitions in these modules are translated by translation rules Appendix A (e.g., MacAddress, PhysAddress, or TimeStamp) then
defined in this document. ignore this item.
o Add any imports required by the type translations according to the 4. Otherwise, if the item is used in a SYNTAX clause of an
type mapping table. This requires to consider all the types used OBJECT-TYPE whose MAX-ACCESS is not accessible-for-notify,
in the translation unit in order to produce the imports. then generate an import statement as described below.
5. Otherwise, if the item is used in an OBJECTS clause of a
NOTIFICATION-TYPE, then generate an import statement as
described below.
6. Otherwise, if the item is used in an INDEX or AUGMENTS clause,
then generate an import statement as described below.
7. Otherwise, ignore this item. Some examples of this case are
OBJECT IDENTIFIER assignments and objects that are only
referenced in MODULE-COMPLIANCE, OBJECT-GROUP, or
NOTIFICATION-GROUP clauses.
o Generate any additional import statements as required by the type
translations according to the type mapping table Appendix A. This
requires the translator to consider all the types used in the
SMIv2 module in order to produce the imports.
o Generate an import statement for the yang module ietf-yang-smiv2
with the prefix smiv2 if extensions from ietf-yang-smiv2 will be
used in the translated yang module.
The generated import statements use the untranslated SMIv2 module The generated import statements use the untranslated SMIv2 module
names or the names of well-known YANG modules as their argument. The names or the names of well-known YANG modules as their argument. The
import statement must contain a prefix statement. The prefixes MAY import statement must contain a prefix statement. The prefixes MAY
be generated by applying the module prefix generation algorithm be generated by applying the module prefix generation algorithm
described in Section 3. described in Appendix B.
4.1. Example: IMPORTS of IF-MIB 3.1. Example: IMPORTS of IF-MIB
The translation of the IF-MIB [RFC2863] leads to the YANG module The translation of the IF-MIB [RFC2863] leads to the YANG module and
frame and the import statements shown below. The prefix is the namespace/prefix statement and the import statements shown below.
translation of the SMIv2 module name IF-MIB to lowercase (consisting The prefix is the translation of the SMIv2 module name IF-MIB to
of two tokens and thus no further abbreviation). lowercase (consisting of two tokens and thus no further
abbreviation).
module IF-MIB { module IF-MIB {
namespace "urn:ietf:params:xml:ns:yang:smiv2:IF-MIB"; namespace "urn:ietf:params:xml:ns:yang:smiv2:IF-MIB";
prefix "if-mib"; prefix "if-mib";
import IANAifType-MIB { prefix "ianaiftype-mib"; } import IANAifType-MIB { prefix "ianaiftype-mib"; }
import SNMPv2-TC { prefix "smiv2-tc"; } import SNMPv2-TC { prefix "smiv2-tc"; }
import ietf-yang-types { prefix "yang"; } import ietf-yang-types { prefix "yang"; }
import ietf-yang-smiv2 { prefix "smiv2"; } import ietf-yang-smiv2 { prefix "smiv2"; }
} }
5. Translation of the MODULE-IDENTITY Macro 4. Translation of the MODULE-IDENTITY Macro
The SMIv2 requires an invocation of the MODULE-IDENTITY macro to The SMIv2 requires an invocation of the MODULE-IDENTITY macro to
provide contact and revision history for a MIB module. The clauses provide contact and revision history for a MIB module. The clauses
of the SMIv2 MODULE-IDENTITY macro MUST be translated into YANG of the SMIv2 MODULE-IDENTITY macro MUST be translated into YANG
statements as detailed below. statements as detailed below.
5.1. MODULE-IDENTITY Translation Rules 4.1. MODULE-IDENTITY Translation Rules
o The SMIv2 ORGANIZATION clause is mapped to the YANG organization o The SMIv2 ORGANIZATION clause is mapped to the YANG organization
statement. statement.
o The SMIv2 CONTACT-INFO clause is mapped to the YANG contact o The SMIv2 CONTACT-INFO clause is mapped to the YANG contact
statement. statement.
o The SMIv2 DESCRIPTION clause is mapped to the YANG description o The SMIv2 DESCRIPTION clause is mapped to the YANG description
statement. statement.
o Each SMIv2 REVISION clause is mapped to a YANG revision statement. o Each SMIv2 REVISION clause is mapped to a YANG revision statement.
The revision is identified by the date argument of the SMIv2 The revision is identified by the date argument of the SMIv2
REVISION clause. DESCRIPTION sub-clauses of REVISION clauses are REVISION clause. DESCRIPTION sub-clauses of REVISION clauses are
mapped to corresponding description statement nested in revision mapped to corresponding description statement nested in revision
clauses. clauses.
o The SMIv2 LAST-UPDATED clause is ignored if the associated date o The SMIv2 LAST-UPDATED clause is ignored if the associated date
matches a REVISION clause. Otherwise, an additional revision matches a REVISION clause. Otherwise, an additional revision
statement is generated. statement is generated.
o The name of the MODULE-IDENTITY macro invocation is used to o The name of the SMIv2 module is used to generate a top-level
generate a top-level container statement. This container MUST be container statement. This container MUST be config false.
config false.
o The object identifier value of the invocation of the SMIv2 MODULE- o The object identifier value of the invocation of the SMIv2 MODULE-
IDENTITY MAY be translated into an smiv2:oid statement contained IDENTITY is translated into an smiv2:oid statement contained in
in the container representing the MODULE-IDENTITY macro the container representing the MODULE-IDENTITY macro invocation.
invocation, see the YANG extension defined in Section 11. Refer to the YANG extension defined in Section 10.
While all proper SMIv2 modules must have exactly one MODULE-IDENTITY While all proper SMIv2 modules must have exactly one MODULE-IDENTITY
macro invocation, there are a few notable exceptions. The modules macro invocation, there are a few notable exceptions. The modules
defining the SMIv2 language (i.e., the SNMPv2-SMI, SNMPv2-TC, and defining the SMIv2 language (i.e., the SNMPv2-SMI, SNMPv2-TC, and
SNMPv2-CONF modules) do not invoke the MODULE-IDENTITY macro. SNMPv2-CONF modules) do not invoke the MODULE-IDENTITY macro.
Furthermore, SMIv2 modules generated from SMIv1 modules may miss an Furthermore, SMIv2 modules generated from SMIv1 modules may miss an
invocation of the MODULE-IDENTITY macro as well. In such cases, it invocation of the MODULE-IDENTITY macro as well. In such cases, it
is preferable to not generate organization, contact, description, and is preferable to not generate organization, contact, description, and
revision statements. revision statements.
5.2. Example: MODULE-IDENTITY of IF-MIB 4.2. Example: MODULE-IDENTITY of IF-MIB
The translation of the MODULE-IDENTITY of the IF-MIB [RFC2863] leads The translation of the MODULE-IDENTITY of the IF-MIB [RFC2863] leads
to the following YANG statements: to the following YANG statements:
organization organization
"IETF Interfaces MIB Working Group"; "IETF Interfaces MIB Working Group";
contact contact
"Keith McCloghrie "Keith McCloghrie
Cisco Systems, Inc. Cisco Systems, Inc.
skipping to change at page 10, line 44 skipping to change at page 9, line 44
revision "1996-02-28" { revision "1996-02-28" {
description description
"Revisions made by the Interfaces MIB WG, and published in "Revisions made by the Interfaces MIB WG, and published in
RFC 2233."; RFC 2233.";
} }
revision "1993-11-08" { revision "1993-11-08" {
description description
"Initial revision, published as part of RFC 1573."; "Initial revision, published as part of RFC 1573.";
} }
container ifMIB { container IF-MIB {
config false; config false;
description
"[Automatically generated top-level container.]";
smiv2:oid "1.3.6.1.2.1.31";
} }
6. Translation of the TEXTUAL-CONVENTION Macro 5. Translation of the TEXTUAL-CONVENTION Macro
The SMIv2 uses invocations of the TEXTUAL-CONVENTION macro to define The SMIv2 uses invocations of the TEXTUAL-CONVENTION macro to define
new types derived from the SMIv2 base types. Invocations of the new types derived from the SMIv2 base types. Invocations of the
TEXTUAL-CONVENTION macro MUST be translated into YANG typedef TEXTUAL-CONVENTION macro MUST be translated into YANG typedef
statements as detailed below. statements as detailed below.
6.1. TEXTUAL-CONVENTION Translation Rules 5.1. TEXTUAL-CONVENTION Translation Rules
The name of the TEXTUAL-CONVENTION macro invocation is used as the The name of the TEXTUAL-CONVENTION macro invocation is used as the
name of the generated typedef statement. The clauses of the SMIv2 name of the generated typedef statement. The clauses of the SMIv2
TEXTUAL-CONVENTION macro are mapped to YANG statements embedded in TEXTUAL-CONVENTION macro are mapped to YANG statements embedded in
the typedef statement as follows: the typedef statement as follows:
o The SMIv2 DISPLAY-HINT clause is used to determine the type o The SMIv2 DISPLAY-HINT clause is used to determine the type
mapping of types derived form the OCTET STRING type as explained mapping of types derived form the OCTET STRING type as explained
in Section 2. Furthermore, the DISPLAY-HINT value MAY be used to in Section 2. Furthermore, the DISPLAY-HINT value MAY be used to
generate a regular expression for the YANG pattern statement generate a regular expression for the YANG pattern statement
within the type statement. within the type statement.
o The SMIv2 DISPLAY-HINT MAY be translated into an smiv2:display- o The SMIv2 DISPLAY-HINT is translated into an smiv2:display-hint
hint statement, see the YANG extension defined in Section 11. statement. Refer to the YANG extension defined in Section 10.
o The SMIv2 STATUS clause is mapped to the YANG status statement. o The SMIv2 STATUS clause is mapped to the YANG status statement.
The generation of the YANG status statement is skipped if the The generation of the YANG status statement is skipped if the
value of the STATUS clause is current. value of the STATUS clause is current.
o The SMIv2 DESCRIPTION clause is mapped to the YANG description o The SMIv2 DESCRIPTION clause is mapped to the YANG description
statement. statement.
o The SMIv2 REFERENCE clause is mapped to the YANG reference o The SMIv2 REFERENCE clause is mapped to the YANG reference
statement. statement.
o The SMIv2 SYNTAX clause is mapped to the YANG type statement. o The SMIv2 SYNTAX clause is mapped to the YANG type statement.
SMIv2 range restrictions are mapped to YANG range statements while SMIv2 range restrictions are mapped to YANG range statements while
SMIv2 length restrictions are mapped to YANG length statements. SMIv2 length restrictions are mapped to YANG length statements.
SMIv2 INTEGER enumerations and SMIv2 BITS are mapped to YANG enum SMIv2 INTEGER enumerations are mapped to YANG enum/value
/ value and bit / position statements. statements. SMIv2 BITS are mapped to YANG bit/position
statements.
This translation assumes that labels of named numbers and named bits This translation assumes that labels of named numbers and named bits
do not change when an SMIv2 module is revised. This is consistent do not change when an SMIv2 module is revised. This is consistent
with the clarification of the SMIv2 module revision rules in Section with the clarification of the SMIv2 module revision rules in Section
4.9 of [RFC4181]. 4.9 of [RFC4181].
6.2. Example: OwnerString and InterfaceIndex of IF-MIB 5.2. Example: OwnerString and InterfaceIndex of IF-MIB
The translation of the OwnerString and InterfaceIndex textual- The translation of the OwnerString and InterfaceIndex textual-
conventions of the IF-MIB [RFC2863] are shown below. conventions of the IF-MIB [RFC2863] are shown below.
typedef OwnerString { typedef OwnerString {
type string { type string {
length "0..255"; length "0..255";
pattern '\p{IsBasicLatin}{0,255}'; pattern '\p{IsBasicLatin}{0,255}';
} }
status deprecated; status deprecated;
skipping to change at page 12, line 39 skipping to change at page 11, line 44
description description
"A unique value, greater than zero, for each interface or "A unique value, greater than zero, for each interface or
interface sub-layer in the managed system. It is interface sub-layer in the managed system. It is
recommended that values are assigned contiguously starting recommended that values are assigned contiguously starting
from 1. The value for each interface sub-layer must remain from 1. The value for each interface sub-layer must remain
constant at least from one re-initialization of the entity's constant at least from one re-initialization of the entity's
network management system to the next re-initialization."; network management system to the next re-initialization.";
smiv2:display-hint "d"; smiv2:display-hint "d";
} }
6.3. Example: IfDirection of the DIFFSERV-MIB 5.3. Example: IfDirection of the DIFFSERV-MIB
The translation of the IfDirection textual-convention of the The translation of the IfDirection textual-convention of the
DIFFSERV-MIB [RFC3289] is shown below. DIFFSERV-MIB [RFC3289] is shown below.
typedef IfDirection { typedef IfDirection {
type enumeration { type enumeration {
enum inbound { value 1; } enum inbound { value 1; }
enum outbound { value 2; } enum outbound { value 2; }
} }
description description
"IfDirection specifies a direction of data travel on an "IfDirection specifies a direction of data travel on an
interface. 'inbound' traffic is operated on during reception from interface. 'inbound' traffic is operated on during reception from
the interface, while 'outbound' traffic is operated on prior to the interface, while 'outbound' traffic is operated on prior to
transmission on the interface."; transmission on the interface.";
} }
7. Translation of OBJECT IDENTIFIER Assignments 6. Translation of OBJECT IDENTIFIER Assignments
The SMIv2 uses OBJECT IDENTIFIER assignments to introduce names for The SMIv2 uses OBJECT IDENTIFIER assignments to introduce names for
intermediate nodes in the OBJECT IDENTIFIER tree. OBJECT IDENTIFIER intermediate nodes in the OBJECT IDENTIFIER tree. OBJECT IDENTIFIER
assignments are not translated into YANG statements. assignments are translated into smiv2:alias statements. Refer to the
YANG extension defined in Section 10.
8. Translation of the OBJECT-TYPE Macro 7. Translation of the OBJECT-TYPE Macro
The SMIv2 uses the OBJECT-TYPE macro to define objects and the The SMIv2 uses the OBJECT-TYPE macro to define objects and the
structure of conceptual tables. Objects exist either as scalars structure of conceptual tables. Objects exist either as scalars
(exactly one instance within an SNMP context) or columnar objects (exactly one instance within an SNMP context) or columnar objects
within conceptual tables (zero or multiple instances within an SNMP within conceptual tables (zero or multiple instances within an SNMP
context). A number of auxiliary objects define the index (key) of a context). A number of auxiliary objects define the index (key) of a
conceptual table. Furthermore, conceptual tables can be augmented by conceptual table. Furthermore, conceptual tables can be augmented by
other conceptual tables. All these differences must be taken into other conceptual tables. All these differences must be taken into
account when translating SMIv2 OBJECT-TYPE macro invocations to YANG. account when translating SMIv2 OBJECT-TYPE macro invocations to YANG.
Invocations of the OBJECT-TYPE macro MUST be translated into YANG Invocations of the OBJECT-TYPE macro MUST be translated into YANG
statements as detailed below. statements as detailed below.
8.1. Scalar and Columnar Object Translation Rules 7.1. Scalar and Columnar Object Translation Rules
SMIv2 OBJECT-TYPE macro invocations defining scalars or columnar SMIv2 OBJECT-TYPE macro invocations defining scalars or columnar
objects with a MAX-ACCESS of "not-accessible", "read-only", objects with a MAX-ACCESS of "not-accessible", "read-only",
"read-write" and ""read-create" are translated to YANG leaf "read-write" and "read-create" are translated to YANG leaf
statements. The name of the leaf is the name associated with the statements. Additionally, columnar objects with a MAX-ACCESS of
SMIv2 OBJECT-TYPE macro invocation. SMIv2 OBJECT-TYPE macro accessible-for-notify are translated to YANG leaf statements if that
columnar object is part of the INDEX clause of the table containing
that columnar object. The name of the leaf is the name associated
with the SMIv2 OBJECT-TYPE macro invocation. SMIv2 OBJECT-TYPE macro
invocations with a MAX-ACCESS of "accessible-for-notify" are not invocations with a MAX-ACCESS of "accessible-for-notify" are not
translated to YANG data tree leafs but instead into YANG notification translated to YANG data tree leafs but instead into YANG notification
leafs. leafs.
All leaf statements for scalar objects are created in the top-level Leaf statements for scalar objects are created in a container
container representing the SMIv2 module, see Section 5.1. The leaf representing the scalar's parent node in the OID tree. This
container is is named after the scalar's parent node in the OID tree
and placed in the top-level container representing the SMIv2 module,
see Section 4.1. In the rare case that the scalar's parent node has
multiple names, the automatic translation MUST fail with an error and
the name clash needs to be investigated and fixed manually. The leaf
statements representing columnar objects are created in the list statements representing columnar objects are created in the list
representing a conceptual row, see Section 8.3. representing a conceptual row, see Section 7.3.
o The SMIv2 SYNTAX clause is mapped to the YANG type statement. o The SMIv2 SYNTAX clause is mapped to the YANG type statement.
SMIv2 range restrictions are mapped to YANG range statements while SMIv2 range restrictions are mapped to YANG range statements while
SMIv2 length restrictions are mapped to YANG length statements. SMIv2 length restrictions are mapped to YANG length statements.
SMIv2 INTEGER enumerations and SMIv2 BITS are mapped to YANG enum SMIv2 INTEGER enumerations are mapped to YANG enum/value
/ value and bit / position statements. statements. SMIv2 BITS are mapped to YANG bit/position
statements.
o The SMIv2 UNITS clause is mapped to the YANG units statement. o The SMIv2 UNITS clause is mapped to the YANG units statement.
o The SMIv2 MAX-ACCESS MAY be translated into an smiv2:max-access o The SMIv2 MAX-ACCESS is translated into an smiv2:max-access
statement, see the YANG extension defined in Section 11. statement. Refer to the YANG extension defined in Section 10.
o The SMIv2 STATUS clause is mapped to the YANG status statement. o The SMIv2 STATUS clause is mapped to the YANG status statement.
The generation of the YANG status statement is skipped if the The generation of the YANG status statement is skipped if the
value of the STATUS clause is current. value of the STATUS clause is current.
o The SMIv2 DESCRIPTION clause is mapped to the YANG description o The SMIv2 DESCRIPTION clause is mapped to the YANG description
statement. statement.
o The SMIv2 REFERENCE clause is mapped to the YANG reference o The SMIv2 REFERENCE clause is mapped to the YANG reference
statement. statement.
o The value of the SMIv2 OBJECT-TYPE macro invocation MAY be o The SMIv2 DEFVAL clause is mapped to an smiv2:defval statement.
translated into an smiv2:oid statement, see the YANG extension Refer to the YANG extension defined in Section 10.
defined in Section 11.
o The value of the SMIv2 OBJECT-TYPE macro invocation is translated
into an smiv2:oid statement. Refer to the YANG extension defined
in Section 10.
This translation assumes that labels of named numbers and named bits This translation assumes that labels of named numbers and named bits
do not change when an SMIv2 module is revised. This is consistent do not change when an SMIv2 module is revised. This is consistent
with the clarification of the SMIv2 module revision rules in Section with the clarification of the SMIv2 module revision rules in Section
4.9 of [RFC4181]. 4.9 of [RFC4181].
8.2. Example: ifNumber and ifIndex of the IF-MIB 7.2. Example: ifNumber and ifIndex of the IF-MIB
The translations of the ifNumber scalar object and the ifIndex The translations of the ifNumber scalar object and the ifIndex
columnar object of the IF-MIB [RFC2863] are shown below. columnar object of the IF-MIB [RFC2863] are shown below. Since
ifNumber is a scalar object in the interfaces branch of the IF-MIB,
the YANG leaf ifNumber will be placed in a YANG container called
interfaces, which is registered in the top-level container IF-MIB.
leaf ifNumber { leaf ifNumber {
type int32; type int32;
description description
"The number of network interfaces (regardless of their "The number of network interfaces (regardless of their
current state) present on this system."; current state) present on this system.";
smiv2:max-access "read-only"; smiv2:max-access "read-only";
smiv2:oid "1.3.6.1.2.1.2.1"; smiv2:oid "1.3.6.1.2.1.2.1";
} }
skipping to change at page 16, line 44 skipping to change at page 16, line 27
"A unique value, greater than zero, for each interface. It "A unique value, greater than zero, for each interface. It
is recommended that values are assigned contiguously is recommended that values are assigned contiguously
starting from 1. The value for each interface sub-layer starting from 1. The value for each interface sub-layer
must remain constant at least from one re-initialization of must remain constant at least from one re-initialization of
the entity's network management system to the next re- the entity's network management system to the next re-
initialization."; initialization.";
smiv2:max-access "read-only"; smiv2:max-access "read-only";
smiv2:oid "1.3.6.1.2.1.2.2.1.1"; smiv2:oid "1.3.6.1.2.1.2.2.1.1";
} }
8.3. Non-Augmenting Conceptual Table Translation Rules 7.3. Non-Augmenting Conceptual Table Translation Rules
An OBJECT-TYPE macro invocation defining a non-augmenting conceptual An OBJECT-TYPE macro invocation defining a non-augmenting conceptual
table is translated to a YANG container statement using the name of table is translated to a YANG container statement using the name of
the OBJECT-TYPE macro invocation. This container is created in the the OBJECT-TYPE macro invocation. This container is created in the
top-level container representing the SMIv2 module. The clauses of top-level container representing the SMIv2 module. The clauses of
the macro are translated as follows: the macro are translated as follows:
o The SMIv2 SYNTAX clause is ignored o The SMIv2 SYNTAX clause is ignored
o The SMIv2 UNITS clause is ignored. o The SMIv2 UNITS clause is ignored.
skipping to change at page 17, line 21 skipping to change at page 16, line 51
o The SMIv2 STATUS clause is mapped to the YANG status statement. o The SMIv2 STATUS clause is mapped to the YANG status statement.
The generation of the YANG status statement is skipped if the The generation of the YANG status statement is skipped if the
value of the STATUS clause is current. value of the STATUS clause is current.
o The SMIv2 DESCRIPTION clause is mapped to the YANG description o The SMIv2 DESCRIPTION clause is mapped to the YANG description
statement. statement.
o The SMIv2 REFERENCE clause is mapped to the YANG reference o The SMIv2 REFERENCE clause is mapped to the YANG reference
statement. statement.
o The value of the SMIv2 OBJECT-TYPE macro invocation MAY be o The value of the SMIv2 OBJECT-TYPE macro invocation is translated
translated into an smiv2:oid statement, see the YANG extension into an smiv2:oid statement. Refer to the YANG extension defined
defined in Section 11. in Section 10.
An OBJECT-TYPE macro invocation defining a conceptual row is An OBJECT-TYPE macro invocation defining a conceptual row is
translated to a YANG list statement. It is contained in the YANG translated to a YANG list statement. It is contained in the YANG
container representing the conceptual table. The generated list uses container representing the conceptual table. The generated list uses
the name of the row OBJECT-TYPE macro invocation. The clauses of the the name of the row OBJECT-TYPE macro invocation. The clauses of the
OBJECT-TYPE macro are translated as follows: OBJECT-TYPE macro are translated as follows:
o The SMIv2 SYNTAX clause is ignored. o The SMIv2 SYNTAX clause is ignored.
o The SMIv2 UNITS clause is ignored. o The SMIv2 UNITS clause is ignored.
skipping to change at page 17, line 48 skipping to change at page 17, line 29
The generation of the YANG status statement is skipped if the The generation of the YANG status statement is skipped if the
value of the STATUS clause is current. value of the STATUS clause is current.
o The SMIv2 DESCRIPTION clause is mapped to the YANG description o The SMIv2 DESCRIPTION clause is mapped to the YANG description
statement. statement.
o The SMIv2 REFERENCE clause is mapped to the YANG reference o The SMIv2 REFERENCE clause is mapped to the YANG reference
statement. statement.
o The SMIv2 INDEX clause is mapped to the YANG key clause listing o The SMIv2 INDEX clause is mapped to the YANG key clause listing
the columnar objects forming the key of the YANG list. the columnar objects forming the key of the YANG list. If the
same object appears more than once in the INDEX clause, append
'_<n>' to the duplicate object name(s) where '<n>' counts the
occurances of the object in the INDEX clause, starting from 2.
Additional leaf statements must be created to define the leafs
introduced.
o The value of the SMIv2 OBJECT-TYPE macro invocation MAY be o If the SMIv2 INDEX clause contains the IMPLIED keyword, then an
translated into an smiv2:oid statement, see the YANG extension smiv2:implied statement is generated to record the name of the
defined in Section 11. object preceded by the IMPLIED keyword. Refer to the YANG
extension defined in Section 10.
o The value of the SMIv2 OBJECT-TYPE macro invocation is translated
into an smiv2:oid statement. Refer to the YANG extension defined
in Section 10.
Within the list statement, YANG leaf statements are created for Within the list statement, YANG leaf statements are created for
columnar objects as described in Section 8.1. For objects listed in columnar objects as described in Section 7.1. For objects listed in
the SMIv2 INDEX clause that are not part of the conceptual table the SMIv2 INDEX clause that are not part of the conceptual table
itself, YANG leaf statements of type leafref pointing to the itself, YANG leaf statements of type leafref pointing to the
referenced definition are created. referenced definition are created.
8.4. Example: ifTable of the IF-MIB 7.4. Example: ifTable of the IF-MIB
The translation of the definition of the ifTable of the IF-MIB The translation of the definition of the ifTable of the IF-MIB
[RFC2863] is shown below. [RFC2863] is shown below.
container ifTable { container ifTable {
config false;
description description
"A list of interface entries. The number of entries is "A list of interface entries. The number of entries is
given by the value of ifNumber."; given by the value of ifNumber.";
smiv2:oid "1.3.6.1.2.1.2.2"; smiv2:oid "1.3.6.1.2.1.2.2";
list ifEntry { list ifEntry {
key "ifIndex"; key "ifIndex";
description description
"An entry containing management information applicable to a "An entry containing management information applicable to a
particular interface."; particular interface.";
skipping to change at page 18, line 47 skipping to change at page 18, line 40
the entity's network management system to the next re- the entity's network management system to the next re-
initialization."; initialization.";
smiv2:max-access "read-only"; smiv2:max-access "read-only";
smiv2:oid "1.3.6.1.2.1.2.2.1.1"; smiv2:oid "1.3.6.1.2.1.2.2.1.1";
} }
// ... // ...
} }
} }
8.5. Example: ifRcvAddressTable of the IF-MIB 7.5. Example: ifRcvAddressTable of the IF-MIB
The translation of the definition of the ifRcvAddressTable of the IF- The translation of the definition of the ifRcvAddressTable of the IF-
MIB [RFC2863] is shown below. MIB [RFC2863] is shown below.
container ifRcvAddressTable { container ifRcvAddressTable {
description description
"This table contains an entry for each address (broadcast, "This table contains an entry for each address (broadcast,
multicast, or uni-cast) for which the system will receive multicast, or uni-cast) for which the system will receive
packets/frames on a particular interface, except as follows: packets/frames on a particular interface, except as follows:
skipping to change at page 19, line 33 skipping to change at page 19, line 35
list ifRcvAddressEntry { list ifRcvAddressEntry {
key "ifIndex ifRcvAddressAddress"; key "ifIndex ifRcvAddressAddress";
description description
"A list of objects identifying an address for which the "A list of objects identifying an address for which the
system will accept packets/frames on the particular system will accept packets/frames on the particular
interface identified by the index value ifIndex."; interface identified by the index value ifIndex.";
smiv2:oid "1.3.6.1.2.1.31.1.4.1"; smiv2:oid "1.3.6.1.2.1.31.1.4.1";
leaf ifIndex { leaf ifIndex {
type leafref { type leafref {
path "/if-mib:ifMIB/if-mib:ifTable" + path "/if-mib:IF-MIB/if-mib:ifTable" +
"/if-mib:ifEntry/if-mib:ifIndex"; "/if-mib:ifEntry/if-mib:ifIndex";
} }
description
"[Automatically generated leaf for a foreign index.]";
} }
leaf ifRcvAddressAddress { leaf ifRcvAddressAddress {
type yang:phys-address; type yang:phys-address;
description description
"An address for which the system will accept packets/frames "An address for which the system will accept packets/frames
on this entry's interface."; on this entry's interface.";
smiv2:max-access "not-accessible"; smiv2:max-access "not-accessible";
smiv2:oid "1.3.6.1.2.1.31.1.4.1.1"; smiv2:oid "1.3.6.1.2.1.31.1.4.1.1";
} }
// ... // ...
} }
} }
8.6. Augmenting Conceptual Tables Translation Rules 7.6. Example: alHostTable of the RMON2-MIB
The translation of the definition of the alHostTable of the RMON2-MIB
[RFC4502] is shown below.
container alHostTable {
description
"A collection of statistics for a particular protocol from a
particular network address that has been discovered on an
interface of this device.
The probe will populate this table for all protocols in the
protocol directory table whose value of
protocolDirHostConfig is equal to supportedOn(3), and
will delete any entries whose protocolDirEntry is deleted or
has a protocolDirHostConfig value of supportedOff(2).
The probe will add to this table all addresses
seen as the source or destination address in all packets with
no MAC errors and will increment octet and packet counts in
the table for all packets with no MAC errors. Further,
entries will only be added to this table if their address
exists in the nlHostTable and will be deleted from this table
if their address is deleted from the nlHostTable.";
smiv2:oid "1.3.6.1.2.1.16.16.1";
list alHostEntry {
key "hlHostControlIndex alHostTimeMark protocolDirLocalIndex "
"nlHostAddress protocolDirLocalIndex_2";
description
"A conceptual row in the alHostTable.
The hlHostControlIndex value in the index identifies the
hlHostControlEntry on whose behalf this entry was created.
The first protocolDirLocalIndex value in the index identifies
the network-layer protocol of the address.
The nlHostAddress value in the index identifies the network-
layer address of this entry.
The second protocolDirLocalIndex value in the index identifies
the protocol that is counted by this entry.
An example of the indexing in this entry is
alHostOutPkts.1.783495.18.4.128.2.6.6.34.
Note that some combinations of index values may result in an
index that exceeds 128 sub-identifiers in length, which exceeds
the maximum for the SNMP protocol. Implementations should take
care to avoid such combinations.";
smiv2:oid "1.3.6.1.2.1.16.16.1.1";
// ...
leaf protocolDirLocalIndex {
type leafref {
path "/rmon2-mib:RMON2-MIB/"
"rmon2-mib:protocolDirTable/"
"rmon2-mib:"protocolDirEntryf/"
"rmon2-mib:protocolDirLocalIndex";
}
}
// ...
leaf protocolDirLocalIndex_2 {
type leafref {
path "/rmon2-mib:RMON2-MIB/"
"rmon2-mib:protocolDirTable/"
"rmon2-mib:protocolDirEntry/"
"rmon2-mib:protocolDirLocalIndex";
}
}
// ...
}
}
7.7. Augmenting Conceptual Tables Translation Rules
An OBJECT-TYPE macro invocation defining an augmenting conceptual An OBJECT-TYPE macro invocation defining an augmenting conceptual
table is not translated to a YANG statement. The name assigned by table is translated to a YANG smiv2:alias statement. Refer to the
the OBJECT-TYPE macro invocation to the augmenting conceptual table YANG extension defined in Section 10. The clauses of the macro are
MAY be captured in a comment. The clauses of the macro are
translated as follows: translated as follows:
o The SMIv2 SYNTAX clause is ignored. o The SMIv2 SYNTAX clause is ignored.
o The SMIv2 UNITS clause is ignored. o The SMIv2 UNITS clause is ignored.
o The SMIv2 MAX-ACCESS clause is ignored. o The SMIv2 MAX-ACCESS clause is ignored.
o The SMIv2 STATUS clause is ignored. o The SMIv2 STATUS clause is mapped to the YANG status statement.
The generation of the YANG status statement is skipped if the
value of the STATUS clause is current.
o The SMIv2 DESCRIPTION clause MAY be captured in a comment. o The SMIv2 DESCRIPTION clause is mapped to the YANG description
statement.
o The SMIv2 REFERENCE clause MAY be captured in a comment. o The SMIv2 REFERENCE clause is mapped to the YANG reference
statement.
o The value of the SMIv2 OBJECT-TYPE macro invocation MAY be o The value of the SMIv2 OBJECT-TYPE macro invocation is translated
captured in a comment. into an smiv2:oid statement. Refer to the YANG extension defined
in Section 10.
An OBJECT-TYPE macro invocation defining a conceptual row An OBJECT-TYPE macro invocation defining a conceptual row
augmentation is translated to a YANG augment statement using the path augmentation is translated to a YANG smiv2:alias statement and a YANG
to the augmented table as its argument. The clauses of the OBJECT- augment statement using the path to the augmented table as its
TYPE macro are translated as follows: argument. The clauses of the OBJECT-TYPE macro are translated as
follows:
o The SMIv2 SYNTAX clause is ignored. o The SMIv2 SYNTAX clause is ignored.
o The SMIv2 UNITS clause is ignored. o The SMIv2 UNITS clause is ignored.
o The SMIv2 MAX-ACCESS clause is ignored. o The SMIv2 MAX-ACCESS clause is ignored.
o The SMIv2 STATUS clause is mapped to the YANG status statement. o The SMIv2 STATUS clause is mapped to the YANG status statement.
The generation of the YANG status statement is skipped if the The generation of the YANG status statement is skipped if the
value of the STATUS clause is current. value of the STATUS clause is current.
o The SMIv2 DESCRIPTION clause is mapped to the YANG description o The SMIv2 DESCRIPTION clause is mapped to the YANG description
statement. statement.
o The SMIv2 REFERENCE clause is mapped to the YANG reference o The SMIv2 REFERENCE clause is mapped to the YANG reference
statement. statement.
o The value of the SMIv2 OBJECT-TYPE macro invocation MAY be o The value of the SMIv2 OBJECT-TYPE macro invocation is translated
translated into an smiv2:oid statement, see the YANG extension into an smiv2:oid statement. Refer to the YANG extension defined
defined in Section 11. in Section 10.
Within the augment statement, YANG leaf statements are created as Within the augment statement, YANG leaf statements are created as
described in Section 8.1. described in Section 7.1.
8.7. Example: ifXTable of the IF-MIB 7.8. Example: ifXTable of the IF-MIB
The translation of the definition of the ifXTable of the IF-MIB The translation of the definition of the ifXTable of the IF-MIB
[RFC2863] is shown below. [RFC2863] is shown below.
/* smiv2:alias "ifXTable" {
* ifXTable (1.3.6.1.2.1.31.1.1) description
* "A list of interface entries. The number of entries is
* A list of interface entries. The number of entries is given by the value of ifNumber. This table contains
* given by the value of ifNumber. This table contains additional objects for the interface table.";
* additional objects for the interface table. smiv2:oid "1.3.6.1.2.1.31.1.1";
*/ }
augment "/if-mib:ifMIB/if-mib:ifTable/if-mib:ifEntry" { smiv2:alias "ifXEntry" {
description
"An entry containing additional management information
applicable to a particular interface.";
smiv2:oid "1.3.6.1.2.1.31.1.1.1";
}
augment "/if-mib:IF-MIB/if-mib:ifTable/if-mib:ifEntry" {
description description
"An entry containing additional management information "An entry containing additional management information
applicable to a particular interface."; applicable to a particular interface.";
smiv2:oid "1.3.6.1.2.1.31.1.1.1"; smiv2:oid "1.3.6.1.2.1.31.1.1.1";
leaf ifName { leaf ifName {
type snmpv2-tc:DisplayString; type snmpv2-tc:DisplayString;
description description
"The textual name of the interface. The value of this "The textual name of the interface. The value of this
object should be the name of the interface as assigned by object should be the name of the interface as assigned by
skipping to change at page 22, line 5 skipping to change at page 24, line 5
If there is no local name, or this object is otherwise not If there is no local name, or this object is otherwise not
applicable, then this object contains a zero-length string."; applicable, then this object contains a zero-length string.";
smiv2:max-access "read-only"; smiv2:max-access "read-only";
smiv2:oid "1.3.6.1.2.1.31.1.1.1.1"; smiv2:oid "1.3.6.1.2.1.31.1.1.1.1";
} }
// ... // ...
} }
9. Translation of the OBJECT-IDENTITY Macro 8. Translation of the OBJECT-IDENTITY Macro
The SMIv2 uses invocations of the OBJECT-IDENTITY macro to define The SMIv2 uses invocations of the OBJECT-IDENTITY macro to define
information about an OBJECT IDENTIFIER assignment. Invocations of information about an OBJECT IDENTIFIER assignment. Invocations of
the OBJECT-IDENTITY macro MUST be translated into YANG identity the OBJECT-IDENTITY macro MUST be translated into YANG identity
statements as detailed below. statements as detailed below.
9.1. OBJECT-IDENTITY Translation Rules 8.1. OBJECT-IDENTITY Translation Rules
The name of the OBJECT-IDENTITY macro invocation is used as the name The name of the OBJECT-IDENTITY macro invocation is used as the name
of the generated identity statement. The generated identity of the generated identity statement. The generated identity
statement uses the smiv2:object-identity defined in Section 11 as its statement uses the smiv2:object-identity defined in Section 10 as its
base. The clauses of the SMIv2 OBJECT-IDENTITY macro are mapped to base. The clauses of the SMIv2 OBJECT-IDENTITY macro are mapped to
YANG statements as follows: YANG statements as follows:
o The SMIv2 STATUS clause is mapped to the YANG status statement. o The SMIv2 STATUS clause is mapped to the YANG status statement.
The generation of the YANG status statement is skipped if the The generation of the YANG status statement is skipped if the
value of the STATUS clause is current. value of the STATUS clause is current.
o The SMIv2 DESCRIPTION clause is mapped to the YANG description o The SMIv2 DESCRIPTION clause is mapped to the YANG description
statement. statement.
o The SMIv2 REFERENCE clause is mapped to the YANG reference o The SMIv2 REFERENCE clause is mapped to the YANG reference
statement. statement.
o The value of the SMIv2 OBJECT-IDENTITY macro invocation MAY be o The value of the SMIv2 OBJECT-IDENTITY macro invocation is
translated into an smiv2:oid statement, see the YANG extension translated into an smiv2:oid statement. Refer to the YANG
defined in Section 11. extension defined in Section 10.
9.2. Example: diffServTBParamSimpleTokenBucket of the DIFFSERV-MIB 8.2. Example: diffServTBParamSimpleTokenBucket of the DIFFSERV-MIB
The translation of the diffServTBParamSimpleTokenBucket of the The translation of the diffServTBParamSimpleTokenBucket of the
DIFFSERV-MIB [RFC3289] is shown below. DIFFSERV-MIB [RFC3289] is shown below.
identity diffServTBParamSimpleTokenBucket { identity diffServTBParamSimpleTokenBucket {
base "smiv2:object-identity"; base "smiv2:object-identity";
description description
"Two Parameter Token Bucket Meter as described in the Informal "Two Parameter Token Bucket Meter as described in the Informal
Differentiated Services Model section 5.2.3."; Differentiated Services Model section 5.2.3.";
smiv2:oid "1.3.6.1.2.1.97.3.1.1"; smiv2:oid "1.3.6.1.2.1.97.3.1.1";
} }
10. Translation of the NOTIFICATION-TYPE Macro 9. Translation of the NOTIFICATION-TYPE Macro
The SMIv2 provides the NOTIFICATION-TYPE macro to define event The SMIv2 provides the NOTIFICATION-TYPE macro to define event
notifications. YANG provides the notification statement for the same notifications. YANG provides the notification statement for the same
purpose. Invocations of the NOTIFICATION-TYPE macro MUST be purpose. Invocations of the NOTIFICATION-TYPE macro MUST be
translated into YANG notification statements as detailed below. translated into YANG notification statements as detailed below.
10.1. NOTIFICATION-TYPE Translation Rules 9.1. NOTIFICATION-TYPE Translation Rules
The name of the NOTIFICATION-TYPE macro invocation is used as the The name of the NOTIFICATION-TYPE macro invocation is used as the
name of the generated notification statement. The clauses of the name of the generated notification statement. The clauses of the
NOTIFICATION-TYPE macro are mapped to YANG statements embedded in the NOTIFICATION-TYPE macro are mapped to YANG statements embedded in the
notification statement as follows. notification statement as follows.
o The SMIv2 OBJECTS clause is mapped to a sequence of YANG o The SMIv2 OBJECTS clause is mapped to a sequence of YANG
containers. For each object listed in the OBJECTS clause value, a containers. For each object listed in the OBJECTS clause value, a
YANG container statement is generated. The name of this container YANG container statement is generated. The name of this container
is the string "object-<n>", where <n> is the position of the is the string "object-<n>", where <n> is the position of the
object in the value of the OBJECTS clause (first element has object in the value of the OBJECTS clause (first element has
position 1). If the current object belongs to a conceptual table, position 1). If the current object belongs to a conceptual table,
then a sequence of leaf statements is generated for each INDEX then a sequence of leaf statements is generated for each INDEX
object of the conceptual table. These leafs are named after the object of the conceptual table. These leafs are named after the
INDEX objects and of type leafref. Finally, a leaf statement is INDEX objects and of type leafref. Finally, a leaf statement is
generated named after the current object. If the current object generated named after the current object. If the current object
has a MAX-ACCESS of "read-only", "read-write" or ""read-create", has a MAX-ACCESS of "read-only", "read-write" or "read-create",
then the generated leaf is of type leafref. Otherwise, if the then the generated leaf is of type leafref. Otherwise, if the
current object has a MAX-ACCESS of "accessible-for-notify", then a current object has a MAX-ACCESS of "accessible-for-notify", then a
leaf is generated, following the itemized steps in Section 8.1. leaf is generated, following the itemized steps in Section 7.1.
o The SMIv2 STATUS clause is mapped to the YANG status statement. o The SMIv2 STATUS clause is mapped to the YANG status statement.
The generation of the YANG status statement is skipped if the The generation of the YANG status statement is skipped if the
value of the STATUS clause is current. value of the STATUS clause is current.
o The SMIv2 DESCRIPTION clause is mapped to the YANG description o The SMIv2 DESCRIPTION clause is mapped to the YANG description
statement. statement.
o The SMIv2 REFERENCE clause is mapped to the YANG reference o The SMIv2 REFERENCE clause is mapped to the YANG reference
statement. statement.
o The value of the SMIv2 NOTIFICATION-TYPE macro invocation MAY be o The value of the SMIv2 NOTIFICATION-TYPE macro invocation is
translated into an smiv2:oid statement, see the YANG extension translated into an smiv2:oid statement. Refer to the YANG
defined in Section 11. extension defined in Section 10.
10.2. Example: linkDown NOTIFICATION-TYPE of IF-MIB 9.2. Example: linkDown NOTIFICATION-TYPE of IF-MIB
The translation of the linkDown notification of the IF-MIB [RFC2863] The translation of the linkDown notification of the IF-MIB [RFC2863]
is shown below. is shown below.
notification linkDown { notification linkDown {
description
"A linkDown trap signifies that the SNMP entity, acting in
an agent role, has detected that the ifOperStatus object for
one of its communication links is about to enter the down
state from some other state (but not from the notPresent
state). This other state is indicated by the included value
of ifOperStatus.";
smiv2:oid "1.3.6.1.6.3.1.1.5.3";
container object-1 {
description description
"[Automatically generated container for a notification object."; "A linkDown trap signifies that the SNMP entity, acting in
an agent role, has detected that the ifOperStatus object for
one of its communication links is about to enter the down
state from some other state (but not from the notPresent
state). This other state is indicated by the included value
of ifOperStatus.";
smiv2:oid "1.3.6.1.6.3.1.1.5.3";
leaf ifIndex { container object-1 {
type leafref { leaf ifIndex {
path "/if-mib:ifMIB/if-mib:ifTable" + type leafref {
"/if-mib:ifEntry/if-mib:ifIndex"; path "/if-mib:IF-MIB/if-mib:ifTable" +
"/if-mib:ifEntry/if-mib:ifIndex";
}
} }
description
"[Automatically generated leaf for a notification object.]";
} }
}
container object-2 {
description
"[Automatically generated container for a notification object.";
leaf ifIndex { container object-2 {
type leafref { leaf ifIndex {
path "/if-mib:ifMIB/if-mib:ifTable" + type leafref {
"/if-mib:ifEntry/if-mib:ifIndex"; path "/if-mib:IF-MIB/if-mib:ifTable" +
"/if-mib:ifEntry/if-mib:ifIndex";
}
} }
description leaf ifAdminStatus {
"[Automatically generated leaf for a notification object type leafref {
index.]"; path "/if-mib:IF-MIB/if-mib:ifTable" +
} "/if-mib:ifEntry/if-mib:ifAdminStatus";
leaf ifAdminStatus { }
type leafref {
path "/if-mib:ifMIB/if-mib:ifTable" +
"/if-mib:ifEntry/if-mib:ifAdminStatus";
} }
description
"[Automatically generated leaf for a notification object.]";
} }
}
container object-3 {
description
"[Automatically generated container for a notification object.";
leaf ifIndex { container object-3 {
type leafref { leaf ifIndex {
path "/if-mib:ifMIB/if-mib:ifTable" + type leafref {
"/if-mib:ifEntry/if-mib:ifIndex"; path "/if-mib:IF-MIB/if-mib:ifTable" +
"/if-mib:ifEntry/if-mib:ifIndex";
}
} }
description leaf ifOperStatus {
"[Automatically generated leaf for a notification object type leafref {
index.]"; path "/if-mib:IF-MIB/if-mib:ifTable" +
} "/if-mib:ifEntry/if-mib:ifOperStatus";
leaf ifOperStatus { }
type leafref {
path "/if-mib:ifMIB/if-mib:ifTable" +
"/if-mib:ifEntry/if-mib:ifOperStatus";
} }
description
"[Automatically generated leaf for a notification object.]";
} }
} }
}
11. YANG Language Extension Definition 10. YANG Language Extension Definition
This section defines some YANG extension statements that can be used This section defines some YANG extension statements that can be used
to capture some information present in SMIv2 modules that is not to capture some information present in SMIv2 modules that is not
translated into core YANG statements. The YANG module references translated into core YANG statements. The YANG module references
[RFC2578] and [RFC2579]. [RFC2578] and [RFC2579].
<CODE BEGINS> file "ietf-yang-smiv2@2011-07-01.yang" <CODE BEGINS> file "ietf-yang-smiv2@2011-11-25.yang"
module ietf-yang-smiv2 { module ietf-yang-smiv2 {
namespace "urn:ietf:params:xml:ns:yang:ietf-yang-smiv2"; namespace "urn:ietf:params:xml:ns:yang:ietf-yang-smiv2";
prefix "smiv2"; prefix "smiv2";
organization organization
"IETF NETMOD (NETCONF Data Modeling Language) Working Group"; "IETF NETMOD (NETCONF Data Modeling Language) Working Group";
contact contact
skipping to change at page 27, line 6 skipping to change at page 29, line 6
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
// RFC Ed.: replace XXXX with actual RFC number and remove this note // RFC Ed.: replace XXXX with actual RFC number and remove this note
// RFC Ed.: please update the date to the date of publication // RFC Ed.: please update the date to the date of publication
revision 2011-07-01 { revision 2011-11-25 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: Translation of SMIv2 MIB Modules to YANG Modules"; "RFC XXXX: Translation of SMIv2 MIB Modules to YANG Modules";
// RFC Ed.: replace XXXX with actual RFC number and remove this note // RFC Ed.: replace XXXX with actual RFC number and remove this note
} }
identity object-identity { identity object-identity {
description description
"Base identity for all SMIv2 OBJECT-IDENTITYs."; "Base identity for all SMIv2 OBJECT-IDENTITYs.";
} }
extension oid { typedef opaque {
argument "value"; type binary;
description description
"The oid statement takes as an argument the object identifier "The Opaque type supports the capability to pass arbitrary ASN.1
assigned to an SMIv2 definition. The object identifier value syntax. A value is encoded using the ASN.1 Basic Encoding Rules
is written in decimal dotted notation."; into a string of octets. This, in turn, is encoded as an OCTET
STRING, in effect 'double-wrapping' the original ASN.1 value.
In the value set and its semantics, this type is equivalent to
the Opaque type of the SMIv2. This type exists in the SMIv2
solely for backward-compatibility reasons and this is also
true for this YANG data type.";
reference reference
"RFC2578: Structure of Management Information Version 2 (SMIv2)"; "RFC 2578: Structure of Management Information Version 2 (SMIv2)";
} }
extension display-hint { extension display-hint {
argument "format"; argument "format";
description description
"The display-hint statement takes as an argument the DISPLAY-HINT "The display-hint statement takes as an argument the DISPLAY-HINT
assigned to an SMIv2 textual convention."; assigned to an SMIv2 textual convention.";
reference reference
"RFC2579: Textual Conventions for SMIv2"; "RFC2579: Textual Conventions for SMIv2";
} }
skipping to change at page 27, line 46 skipping to change at page 30, line 4
} }
extension max-access { extension max-access {
argument "access"; argument "access";
description description
"The max-access statement takes as an argument the MAX-ACCESS "The max-access statement takes as an argument the MAX-ACCESS
assigned to an SMIv2 object definition"; assigned to an SMIv2 object definition";
reference reference
"RFC2578: Structure of Management Information Version 2 (SMIv2)"; "RFC2578: Structure of Management Information Version 2 (SMIv2)";
} }
extension defval { extension defval {
argument "value"; argument "value";
description description
"The defval statement takes as an argument a default value defined "The defval statement takes as an argument a default value
by an SMIv2 DEFVAL clause."; defined by an SMIv2 DEFVAL clause. Note that the value is in
the SMIv2 value space defined by the SMIv2 syntax of the
corresponding object and not in the YANG value space
defined by the corresponding YANG data type.";
reference reference
"RFC2578: Structure of Management Information Version 2 (SMIv2)"; "RFC2578: Structure of Management Information Version 2 (SMIv2)";
} }
extension implied {
argument "index";
description
"If an SMIv2 INDEX object is preceded by the IMPLIED keyword, then
the implied statement is present in the yang module and takes as
an argument the name of the IMPLIED index object.";
reference
"RFC2578: Structure of Management Information Version 2 (SMIv2)";
}
extension alias { extension alias {
argument "descriptor" argument "descriptor";
description description
"The alias statement introduces an SMIv2 descriptor. The body of "The alias statement introduces an SMIv2 descriptor. The body of
the alias statement is expected to contain an oid statement that the alias statement is expected to contain an oid statement that
provides the numeric OID associated with the descriptor."; provides the numeric OID associated with the descriptor.";
reference reference
"RFC2578: Structure of Management Information Version 2 (SMIv2)"; "RFC2578: Structure of Management Information Version 2 (SMIv2)";
} }
extension oid {
argument "value";
description
"The oid statement takes as an argument the object identifier
assigned to an SMIv2 definition. The object identifier value
is written in decimal dotted notation.";
reference
"RFC2578: Structure of Management Information Version 2 (SMIv2)";
}
extension subid {
argument "value";
description
"The subid statement takes as an argument the last sub-identifier
of the object identifier assigned to an SMIv2 definition. The
sub-identifier value is a single positive decimal natural number.
The subid statement may not be used as a substatement to any
top-level node in a YANG document. The subid substatement may
be used only as a substatement to a node having a parent node
defined with either a smiv2:oid or smiv2:subid substatement.";
reference
"RFC2578: Structure of Management Information Version 2 (SMIv2)";
}
} }
<CODE ENDS> <CODE ENDS>
12. IANA Considerations 11. IANA Considerations
This document registers two URIs in the IETF XML registry [RFC3688]. This document registers two URIs in the IETF XML registry [RFC3688].
Following the format in RFC 3688, the following registrations have Following the format in RFC 3688, the following registrations have
been made. been made.
URI: urn:ietf:params:xml:ns:yang:ietf-yang-smiv2 URI: urn:ietf:params:xml:ns:yang:ietf-yang-smiv2
Registrant Contact: The NETMOD WG of the IETF. Registrant Contact: The NETMOD WG of the IETF.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
skipping to change at page 30, line 5 skipping to change at page 33, line 5
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
This document registers a YANG module in the YANG Module Names This document registers a YANG module in the YANG Module Names
registry [RFC6020]. registry [RFC6020].
name: ietf-yang-smiv2 name: ietf-yang-smiv2
namespace: urn:ietf:params:xml:ns:yang:ietf-yang-smiv2 namespace: urn:ietf:params:xml:ns:yang:ietf-yang-smiv2
prefix: smiv2 prefix: smiv2
reference: RFC XXXX reference: RFC XXXX
13. Security Considerations 12. Security Considerations
This document defines a translation of SMIv2 MIB modules into YANG This document defines a translation of SMIv2 MIB modules into YANG
modules, enabling read-only access to data objects defined in SMIv2 modules, enabling read-only access to data objects defined in SMIv2
MIB modules via NETCONF. The translation itself has no security MIB modules via NETCONF. The translation itself has no security
impact on the Internet. impact on the Internet.
Users of translated SMIv2 models that have been published as RFCs Users of translated SMIv2 models that have been published as RFCs
should consult the security considerations of the respective RFCs. should consult the security considerations of the respective RFCs.
In addition, the security considerations for the NETCONF protocol In addition, the security considerations for the NETCONF protocol
[RFC6241] should be consulted to understand how NETCONF protects [RFC6241] should be consulted to understand how NETCONF protects
potentially sensitive information. potentially sensitive information.
13. Acknowledgements
The editor wishes to thank the following individuals for providing
helpful comments on various versions of this document: Andy Bierman,
Martin Bjorklund, David Reid, and David Spakes.
14. References 14. References
14.1. Normative References 14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
skipping to change at page 31, line 40 skipping to change at page 35, line 40
14.2. Informative References 14.2. Informative References
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, June 2000. MIB", RFC 2863, June 2000.
[RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information [RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information
Base for the Differentiated Services Architecture", Base for the Differentiated Services Architecture",
RFC 3289, May 2002. RFC 3289, May 2002.
[RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen,
"Coexistence between Version 1, Version 2, and Version 3
of the Internet-standard Network Management Framework",
RFC 3584, August 2003.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB
Documents", BCP 111, RFC 4181, September 2005. Documents", BCP 111, RFC 4181, September 2005.
[RFC4502] Waldbusser, S., "Remote Network Monitoring Management
Information Base Version 2", RFC 4502, May 2006.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, June 2011. (NETCONF)", RFC 6241, June 2011.
Appendix A. Mapping of Well Known Types (normative)
SMIv2 Module: SNMPv2-SMI
SMIv2 Type: INTEGER (used as an enumeration)
Yang Type: enumeration
SMIv2 Module: SNMPv2-SMI
SMIv2 Type: INTEGER (used as a numeric type)
Yang Type: int32
SMIv2 Module: SNMPv2-SMI
SMIv2 Type: Integer32
Yang Type: int32
SMIv2 Module: SNMPv2-SMI
SMIv2 Type: OCTET STRING (used as a binary string)
Yang Type: binary
SMIv2 Module: SNMPv2-SMI
SMIv2 Type: OCTET STRING (used to hold UTF8/ASCII characters)
Yang Type: string
SMIv2 Module: SNMPv2-SMI
SMIv2 Type: OBJECT IDENTIFIER
YANG Module: ietf-yang-types
Yang Type: object-identifier-128
SMIv2 Module: SNMPv2-SMI
SMIv2 Type: BITS
Yang Type: bits
SMIv2 Module: SNMPv2-SMI
SMIv2 Type: IpAddress
YANG Module: ietf-inet-types
Yang Type: ipv4-address
SMIv2 Module: SNMPv2-SMI
SMIv2 Type: Counter32
YANG Module: ietf-yang-types
Yang Type: counter32
SMIv2 Module: SNMPv2-SMI
SMIv2 Type: Gauge32
YANG Module: ietf-yang-types
Yang Type: gauge32
SMIv2 Module: SNMPv2-SMI
SMIv2 Type: TimeTicks
YANG Module: ietf-yang-types
Yang Type: timeticks
SMIv2 Module: SNMPv2-SMI
SMIv2 Type: Counter64
YANG Module: ietf-yang-types
Yang Type: counter64
SMIv2 Module: SNMPv2-SMI
SMIv2 Type: Unsigned32
Yang Type: uint32
SMIv2 Module: SNMPv2-SMI
SMIv2 Type: Opaque
YANG Module: ietf-yang-smiv2
Yang Type: opaque
SMIv2 Module: SNMPv2-TC
SMIv2 Type: PhysAddress
YANG Module: ietf-yang-types
Yang Type: phys-address
SMIv2 Module: SNMPv2-TC
SMIv2 Type: MacAddress
YANG Module: ietf-yang-types
Yang Type: mac-address
SMIv2 Module: SNMPv2-TC
SMIv2 Type: TruthValue
Yang Type: boolean
SMIv2 Module: SNMPv2-TC
SMIv2 Type: TimeStamp
YANG Module: ietf-yang-types
Yang Type: timestamp
SMIv2 Module: RMON2-MIB
SMIv2 Type: ZeroBasedCounter32
YANG Module: ietf-yang-types
Yang Type: zero-based-counter32
SMIv2 Module: HCNUM-TC
SMIv2 Type: ZeroBasedCounter64
YANG Module: ietf-yang-types
Yang Type: zero-based-counter64
SMIv2 Module: HCNUM-TC
SMIv2 Type: CounterBasedGauge64
YANG Module: ietf-yang-types
Yang Type: gauge64
SMIv2 Module: INET-ADDRESS-MIB
SMIv2 Type: InetAutonomousSystemNumber
YANG Module: ietf-inet-types
Yang Type: as-number
SMIv2 Module: INET-ADDRESS-MIB
SMIv2 Type: InetVersion
YANG Module: ietf-inet-types
Yang Type: ip-version
SMIv2 Module: INET-ADDRESS-MIB
SMIv2 Type: InetPortNumber
YANG Module: ietf-inet-types
Yang Type: port-number
SMIv2 Module: DIFFSERV-DSCP-TC
SMIv2 Type: Dscp
YANG Module: ietf-inet-types
Yang Type: dscp
SMIv2 Module: IPV6-FLOW-LABEL-MIB
SMIv2 Type: IPv6FlowLabel
YANG Module: ietf-inet-types
Yang Type: ipv6-flow-label
SMIv2 Module: URI-TC-MIB
SMIv2 Type: Uri
YANG Module: ietf-inet-types
Yang Type: uri
Appendix B. Module Prefix Generation (informative)
This section describes an algorithm to generate module prefixes, to
be used in the import statements. The input of the prefix generation
algorithm is a set of prefixes (usually derived from imported module
names) and a specific module name to be converted into a prefix. The
algorithm described below produces a prefix for the given module name
that is unique within the set of prefixes.
+-----------------+--------+
| YANG Module | Prefix |
+-----------------+--------+
| ietf-yang-types | yang |
| ietf-inet-types | inet |
| ietf-yang-smiv2 | smiv2 |
+-----------------+--------+
Table 1: Special prefixes for well known YANG modules
o First, some predefined translations mapping well known YANG
modules to short prefixes are tried (see Table 1). If a fixed
translation rule exists and leads to a conflict free prefix, then
the fixed translation is used.
o Otherwise, prefixes are generated by tokenizing a YANG module
name, using hyphens as token separators. The tokens derived from
the module name are converted to lowercase characters. The prefix
then becomes the shortest sequence of tokens concatenated using
hyphens as separators, which includes at least two tokens and
which is unique among all prefixes used in the YANG module.
In the worst case, the prefix derived from an SMIv2 module name
becomes the SMIv2 module name translated to lower-case. But on
average, much shorter prefixes are generated.
Author's Address Author's Address
Juergen Schoenwaelder Juergen Schoenwaelder
Jacobs University Jacobs University
Email: j.schoenwaelder@jacobs-university.de Email: j.schoenwaelder@jacobs-university.de
 End of changes. 112 change blocks. 
315 lines changed or deleted 582 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/