RFC 6643
Translation of Structure of Management Information Version 2 (SMIv2) MIB Modules to YANG Modules
RFC 6643 🎀
Translation of Structure of Management Information Version 2 (SMIv2) MIB Modules to YANG Modules
Okay so this one is by J. Schoenwaelder at Jacobs University 💅. It's a Standards Track doc, which means it's the real deal, and it came out in July 2012 with ISSN 2070-1721 ✨. The header doesn't list any obsoletes or updates, so there's nothing to flag there 🌸.
Abstract
Okay, so YANG is the data modeling language used to describe configuration and state data that gets handled by NETCONF, NETCONF remote procedure calls, and NETCONF notifications 🦋. SMIv2 is the thing that defines the basic data types, the object model, and the rules for writing and revising MIB modules for SNMP 🌸. This doc explains how to translate SMIv2 MIB modules into YANG modules, so you get read-only (config false) access to SMIv2 data objects over NETCONF 💖.
Status of This Memo
This is an Internet Standards Track document 🔥.
It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 5741 🧚.
For the current status, any errata, and how to send feedback, head to http://www.rfc-editor.org/info/rfc6643 🌈.
Copyright Notice
The copyright here is 2012, held by the IETF Trust and the people listed as the document authors. All rights reserved 💜.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please read those carefully, because they spell out your rights and restrictions for this document 🙈. Any Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes.
This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people who control the copyright in some of that older material may not have given the IETF Trust permission to allow changes outside the IETF Standards Process. Unless you get an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The one exceptions are formatting it for publication as an RFC or translating it into languages other than English 💅.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Mapping of Well-Known Types . . . . . . . . . . . . . . . . . 4
3. Translation of SMIv2 Modules and SMIv2 IMPORT Clauses . . . . 5
3.1. Example: IMPORTS of IF-MIB . . . . . . . . . . . . . . . . 6
4. Translation of the MODULE-IDENTITY Macro . . . . . . . . . . . 7
4.1. MODULE-IDENTITY Translation Rules . . . . . . . . . . . . 7
4.2. Example: MODULE-IDENTITY of IF-MIB . . . . . . . . . . . . 8
5. Translation of the TEXTUAL-CONVENTION Macro . . . . . . . . . 9
5.1. TEXTUAL-CONVENTION Translation Rules . . . . . . . . . . . 9
5.2. Example: OwnerString and InterfaceIndex of IF-MIB . . . . 10
5.3. Example: IfDirection of the DIFFSERV-MIB . . . . . . . . . 11
6. Translation of OBJECT IDENTIFIER Assignments . . . . . . . . . 11
7. Translation of the OBJECT-TYPE Macro . . . . . . . . . . . . . 11
7.1. Scalar and Columnar Object Translation Rules . . . . . . . 11
7.2. Example: ifNumber and ifIndex of the IF-MIB . . . . . . . 13
7.3. Non-Augmenting Conceptual Table Translation Rules . . . . 13
7.4. Example: ifTable of the IF-MIB . . . . . . . . . . . . . . 15
7.5. Example: ifRcvAddressTable of the IF-MIB . . . . . . . . . 16
7.6. Example: alHostTable of the RMON2-MIB . . . . . . . . . . 17
7.7. Augmenting Conceptual Tables Translation Rules . . . . . . 18
7.8. Example: ifXTable of the IF-MIB . . . . . . . . . . . . . 20
8. Translation of the OBJECT-IDENTITY Macro . . . . . . . . . . . 21
8.1. OBJECT-IDENTITY Translation Rules . . . . . . . . . . . . 21
8.2. Example: diffServTBParamSimpleTokenBucket of the
DIFFSERV-MIB . . . . . . . . . . . . . . . . . . . . . . . 21
9. Translation of the NOTIFICATION-TYPE Macro . . . . . . . . . . 22
9.1. NOTIFICATION-TYPE Translation Rules . . . . . . . . . . . 22
9.2. Example: linkDown NOTIFICATION-TYPE of IF-MIB . . . . . . 23
10. YANG Language Extension Definition . . . . . . . . . . . . . . 24
11. Implementing Configuration Data Nodes . . . . . . . . . . . . 27
11.1. Example: addressMapControlTable of RMON2-MIB . . . . . . . 28
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
13. Security Considerations . . . . . . . . . . . . . . . . . . . 30
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
15.1. Normative References . . . . . . . . . . . . . . . . . . . 31
15.2. Informative References . . . . . . . . . . . . . . . . . . 31
Appendix A. Mapping of Well-Known Types (Normative) . . . . . . . 33
Appendix B. Module Prefix Generation (Informative) . . . . . . . 351. Introduction ✨
Okay so this doc describes how to translate SMIv2 [RFC2578], [RFC2579], [RFC2580] MIB modules into YANG [RFC6020] modules 🦋. The result is read-only access (config false, as defined in Section 7.19.1 of RFC 6020) to SMIv2 objects in those MIB modules, through NETCONF [RFC6241] 💖. If you're wondering why SMIv2 read-write or read-create objects end up as read-only (config false) YANG objects, the reasoning is in Section 11 🧚.
Generated YANG modules should not be modified 🙈. If something needs to change, you fix the original SMIv2 module instead (and update its LAST-UPDATED and REVISION clauses properly), then run this translation again. This doesn't stop you from using YANG augments and or YANG deviations, though. Generated modules can be augmented like any other YANG module, and YANG deviations are how you document where an implementation differs from the generated module 💅.
SMIv1 modules can be converted too. First you follow the rules in [RFC3584] to turn the SMIv1 module into SMIv2, then you follow the rules in this doc to turn that SMIv2 module into YANG 🌸.
The examples show how the translation works using parts of the IF-MIB [RFC2863], the DIFFSERV-MIB [RFC3289], and the RMON2-MIB [RFC4502] SMIv2 modules 💜.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] 🔥.
2. Mapping of Well-Known Types ✨
The SMIv2 base types, plus some well-known derived textual conventions, get mapped to YANG types according to Appendix A 🌈. How an OCTET STRING gets mapped depends on context. If an OCTET STRING has an associated DISPLAY- HINT, the YANG base type is the string type. An implementation MUST format an OCTET STRING value according to that DISPLAY-HINT, as described in RFC 2579 💖. If an OCTECT STRING doesn't have a DISPLAY-HINT, the binary type gets used instead 🫶. The INTEGER type works the same way: its mapping depends on whether it's used as an enumeration or as a 32-bit integral type 🦋.
Implementations should provide implementation-specific options for when DISPLAY- HINTs get added during a module revision and backwards compatibility has to be kept. In that case, an added DISPLAY-HINT needs to be ignored 🧚.
Heads up, the mappings in Appendix A may need you to import the ietf-yang-types, ietf-inet-types, or ietf-yang-smiv2 YANG modules. Some SMIv2 types and textual conventions map to YANG types that live in ietf-yang-types and ietf-inet-types (defined in [RFC6021]), and some live in the ietf-yang-smiv2 YANG module defined in this document 👑. Implementations MUST add any extra imports the type mapping needs 💅.
3. Translation of SMIv2 Modules and SMIv2 IMPORT Clauses ✨
Okay bestie, time for the imports and module names 💖 SMIv2 modules get mapped to matching YANG modules. The generated YANG module name MUST be the same as the SMIv2 module name. 🎀
The YANG namespace MUST be built from the IANA-registered prefix urn:ietf:params:xml:ns:yang:smiv2: (see Section 12), followed by the SMIv2 module name. SMIv2 module names can be assumed to be unique (see Section 3 in [RFC2578]), so the resulting YANG namespace is unique too 🦋
The YANG prefix MAY be derived from the SMIv2 module name using the module prefix generation algorithm in Appendix B. The YANG prefix is supposed to be short, and it must be unique within the set of all prefixes used by a YANG module. Appendix B's algorithm generates prefixes like that, so you're covered 🌸
SMIv2 IMPORT clauses become YANG import statements. The big difference is that SMIv2 IMPORT clauses pull in specific symbols from an SMIv2 module, while a YANG import statement pulls in all the symbols of the referenced YANG module. Very different vibes 💅
To produce correct and complete YANG import statements, the following rules MUST be used:
- Process each item in each SMIv2 IMPORT clause as follows:
- If an import statement for this SMIv2 module has already been generated, then ignore this item.
- Otherwise, if the SMIv2 module name is SNMPv2-SMI or SNMPv2-CONF, then ignore this item. These two modules can be completely ignored since all definitions in them are translated by translation rules ✨
- Otherwise, if this item is a textual convention matching one of the textual conventions in the SMIv2 types column of Appendix A (e.g., MacAddress, PhysAddress, or TimeStamp), then ignore this item.
- Otherwise, if the item is used in a SYNTAX clause of an OBJECT-TYPE whose MAX-ACCESS is not accessible-for-notify, then generate an import statement as described below.
- Otherwise, if the item is used in an OBJECTS clause of a NOTIFICATION-TYPE, then generate an import statement as described below.
- Otherwise, if the item is used in an INDEX or AUGMENTS clause, then generate an import statement as described below.
- 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.
- Generate any additional import statements required by the type translations according to the type mapping table in Appendix A. This means the translator has to consider all the types used in the SMIv2 module to produce the imports 🧚
- Generate an import statement for the YANG module ietf-yang-smiv2 with the prefix smiv2.
The generated import statements use either the untranslated SMIv2 module names or the names of well-known YANG modules as their argument. The import statement must contain a prefix statement. The prefixes MAY be generated by applying the module prefix generation algorithm in Appendix B 🍓
3.1. Example: IMPORTS of IF-MIB
Let's look at IF-MIB [RFC2863] as an example 🎀 Its translation gives us the YANG module, the namespace/prefix statement, and the import statements shown below. The prefix is just the translation of the SMIv2 module name IF-MIB into lowercase (it has two tokens, so no further abbreviation needed) 💖
module IF-MIB {
namespace "urn:ietf:params:xml:ns:yang:smiv2:IF-MIB";
prefix "if-mib";
import IANAifType-MIB { prefix "ianaiftype-mib"; }
import SNMPv2-TC { prefix "snmpv2-tc"; }
import ietf-yang-types { prefix "yang"; }
import ietf-yang-smiv2 { prefix "smiv2"; }
}4. Translation of the MODULE-IDENTITY Macro 🌈
SMIv2 needs an invocation of the MODULE-IDENTITY macro to give a MIB module its contact info and revision history. The clauses of the SMIv2 MODULE-IDENTITY macro MUST be translated into YANG statements as detailed below 📝
4.1. MODULE-IDENTITY Translation Rules
- The SMIv2 ORGANIZATION clause is mapped to the YANG organization statement.
- The SMIv2 CONTACT-INFO clause is mapped to the YANG contact statement.
- The SMIv2 DESCRIPTION clause is mapped to the YANG description statement.
- Each SMIv2 REVISION clause is mapped to a YANG revision statement. The revision is identified by the date argument of the SMIv2 REVISION clause. DESCRIPTION sub-clauses of REVISION clauses are mapped to the corresponding description statement nested in revision clauses 🦋
- The SMIv2 LAST-UPDATED clause is ignored if the associated date matches a REVISION clause. Otherwise, an additional revision statement is generated.
- A top-level YANG container is generated. The container's name is the SMIv2 module name, and the container MUST be config false. The generation of the top-level container MAY be skipped if the SMIv2 module does not define any objects that go into the top-level container (e.g., an SMIv2 module that only defines textual conventions) 🌸
- The object identifier value of the invocation of the SMIv2 MODULE-IDENTITY is translated into an smiv2:oid statement contained in an smiv2:alias statement representing the MODULE-IDENTITY macro invocation. Refer to the YANG extension defined in Section 10 ✨
While all proper SMIv2 modules must have exactly one MODULE-IDENTITY macro invocation, there are a few notable exceptions 👀 The modules that define the SMIv2 language (i.e., the SNMPv2-SMI, SNMPv2-TC, and SNMPv2-CONF modules) do not invoke the MODULE-IDENTITY macro. Also, SMIv2 modules generated from SMIv1 modules may miss an invocation of the MODULE-IDENTITY macro as well. In those cases, it is preferable to not generate organization, contact, description, or revision statements 🙈
4.2. Example: MODULE-IDENTITY of IF-MIB
The translation of the MODULE-IDENTITY of IF-MIB [RFC2863] leads to the following YANG statements 💅
organization
"IETF Interfaces MIB Working Group";
contact
"Keith McCloghrie
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
US
408-526-5260
kzm@cisco.com";
description
"The MIB module to describe generic objects for network
interface sub-layers. This MIB is an updated version of
MIB-II's ifTable, and incorporates the extensions defined in
RFC 1229.";
revision "2000-06-14" {
description
"Clarifications agreed upon by the Interfaces MIB WG, and
published as RFC 2863.";
}
revision "1996-02-28" {
description
"Revisions made by the Interfaces MIB WG, and published in
RFC 2233.";
}
revision "1993-11-08" {
description
"Initial revision, published as part of RFC 1573.";
}
container IF-MIB {
config false;
}5. Translation of the TEXTUAL-CONVENTION Macro 🎀
SMIv2 uses invocations of the TEXTUAL-CONVENTION macro to define new types derived from the SMIv2 base types. Invocations of the TEXTUAL-CONVENTION macro MUST be translated into YANG typedef statements as detailed below 💖
5.1. TEXTUAL-CONVENTION Translation Rules
The name of the TEXTUAL-CONVENTION macro invocation becomes the name of the generated typedef statement. The clauses of the SMIv2 TEXTUAL-CONVENTION macro are mapped to YANG statements embedded in the typedef statement, like this 🧚
- The SMIv2 DISPLAY-HINT clause is used to determine the type mapping of types derived form the OCTET STRING type, as explained in Section 2. Furthermore, the DISPLAY-HINT value MAY be used to generate a regular expression for the YANG pattern statement within the type statement 🌈
- The SMIv2 DISPLAY-HINT is translated into an smiv2:display-hint statement. Refer to the YANG extension defined in Section 10.
- 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 🍓
- The SMIv2 DESCRIPTION clause is mapped to the YANG description statement.
- The SMIv2 REFERENCE clause is mapped to the YANG reference statement.
- The SMIv2 SYNTAX clause is mapped to the YANG type statement. SMIv2 range restrictions are mapped to YANG range statements, while SMIv2 length restrictions are mapped to YANG length statements. SMIv2 INTEGER enumerations are mapped to YANG enum/value statements. SMIv2 BITS are mapped to YANG bit/position statements. For OCTET STRING types that are mapped to a YANG string base type (see Section 2), the length specified in the YANG length statement must be consistent with the stringified representation of values. If an implementation is unable to derive proper length restrictions, then the YANG length statement MUST be omitted 👑
This translation assumes that the labels of named numbers and named bits do not change when an SMIv2 module is revised. That's consistent with the clarification of the SMIv2 module revision rules in Section 4.9 of [RFC4181] 🦋
5.2. Example: OwnerString and InterfaceIndex of IF-MIB
Here are the translations of the OwnerString and InterfaceIndex textual conventions from IF-MIB [RFC2863] 💖
typedef OwnerString {
type string {
length "0..255";
pattern '\p{IsBasicLatin}{0,255}';
}
status deprecated;
description
"This data type is used to model an administratively
assigned name of the owner of a resource. This information
is taken from the NVT ASCII character set. It is suggested
that this name contain one or more of the following: ASCII
form of the manager station's transport address, management
station name (e.g., domain name), network management
personnel's name, location, or phone number. In some cases
the agent itself will be the owner of an entry. In these
cases, this string shall be set to a string starting with
'agent'.";
smiv2:display-hint "255a";
}
typedef InterfaceIndex {
type int32 {
range "1..2147483647";
}
description
"A unique value, greater than zero, for each interface or
interface sub-layer in the managed system. It is
recommended that values are assigned contiguously starting
from 1. The value for each interface sub-layer must remain
constant at least from one re-initialization of the entity's
network management system to the next re-initialization.";
smiv2:display-hint "d";
}5.3. Example: IfDirection of the DIFFSERV-MIB
Last but not least, the translation of the IfDirection textual convention from DIFFSERV-MIB [RFC3289] looks like this 🌸✨
typedef IfDirection {
type enumeration {
enum inbound { value 1; }
enum outbound { value 2; }
}
description
"IfDirection specifies a direction of data travel on an
interface. 'inbound' traffic is operated on during reception
from the interface, while 'outbound' traffic is operated on
prior to transmission on the interface.";
}6. Translation of OBJECT IDENTIFIER Assignments ✨
okay so SMIv2 uses OBJECT IDENTIFIER assignments to give names to intermediate nodes in the OBJECT IDENTIFIER tree 🌳 and those get translated into smiv2:alias statements. for the YANG extension behind that, check out Section 10 💖
7. Translation of the OBJECT-TYPE Macro 🎀
SMIv2 uses the OBJECT-TYPE macro to define objects and the structure of conceptual tables. objects can be scalars (exactly one instance within an SNMP context) or columnar objects inside conceptual tables (zero or multiple instances within an SNMP context) 👀 a bunch of auxiliary objects define the index (key) of a conceptual table, and conceptual tables can also get augmented by other conceptual tables. all of these differences have to be handled when translating SMIv2 OBJECT-TYPE macro invocations to YANG, so no skipping! Invocations of the OBJECT-TYPE macro MUST be translated into YANG statements as detailed below ✨
7.1. Scalar and Columnar Object Translation Rules 🦋
SMIv2 OBJECT-TYPE macro invocations that define scalars, or columnar objects with a MAX-ACCESS of "not-accessible", "read-only", "read-write", and "read-create", get translated to YANG leaf statements. columnar objects with a MAX-ACCESS of "accessible-for-notify" also become YANG leaf statements, but only if that columnar object is part of the INDEX clause of the table containing it. the leaf's name is the name from the SMIv2 OBJECT-TYPE macro invocation. SMIv2 OBJECT-TYPE macro invocations with a MAX-ACCESS of "accessible-for-notify" are not turned into YANG data tree leafs. they become YANG notification leafs instead 🔔
leaf statements for scalar objects are created in a container that represents the scalar's parent node in the OID tree. that container is named after the scalar's parent node and placed in the top-level container for the SMIv2 module (see Section 4.1). now, 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 🙈 but if a previous revision of the SMIv2 module didn't have that ambiguity, then the name used by that previous revision MUST be used. and the leaf statements for columnar objects get created in the list that represents a conceptual row (see Section 7.3) 💅
- The SMIv2 SYNTAX clause is mapped to the YANG type statement. SMIv2 range restrictions get mapped to YANG range statements, while SMIv2 length restrictions get mapped to YANG length statements. SMIv2 INTEGER enumerations get mapped to YANG enum/value statements, and SMIv2 BITS get mapped to YANG bit/position statements. for OCTET STRING types that map to a YANG string base type (see Section 2), the length in the YANG length statement must be consistent with the stringified representation of values. if an implementation can't derive proper length restrictions, then the YANG length statement MUST be omitted.
- The SMIv2 UNITS clause is mapped to the YANG units statement.
- The SMIv2 MAX-ACCESS is translated into an
smiv2:max-accessstatement. refer to the YANG extension defined in Section 10 ✨ - The SMIv2 STATUS clause is mapped to the YANG status statement. the YANG status statement generation is skipped if the STATUS clause value is current 🌸
- The SMIv2 DESCRIPTION clause is mapped to the YANG description statement.
- The SMIv2 REFERENCE clause is mapped to the YANG reference statement.
- The SMIv2 DEFVAL clause is mapped to an
smiv2:defvalstatement. refer to the YANG extension defined in Section 10. - The value of the SMIv2 OBJECT-TYPE macro invocation is translated into an
smiv2:oidstatement. refer to the YANG extension defined in Section 10.
this translation assumes that labels of named numbers and named bits do not change when an SMIv2 module is revised. that lines up with the clarification of the SMIv2 module revision rules in Section 4.9 of [RFC4181] 🧚
7.2. Example: ifNumber and ifIndex of the IF-MIB 💜
here's how the ifNumber scalar object and the ifIndex columnar object of the IF-MIB [RFC2863] get translated 🍓 since ifNumber is a scalar object in the interfaces branch of the IF-MIB, the YANG leaf ifNumber ends up in a YANG container called interfaces, which is registered in the top-level container IF-MIB.
leaf ifNumber {
type int32;
description
"The number of network interfaces (regardless of their
current state) present on this system.";
smiv2:max-access "read-only";
smiv2:oid "1.3.6.1.2.1.2.1";
}
leaf ifIndex {
type if-mib:InterfaceIndex;
description
"A unique value, greater than zero, for each interface. It
is recommended that values are assigned contiguously
starting from 1. The value for each interface sub-layer
must remain constant at least from one re-initialization of
the entity's network management system to the next re-
initialization.";
smiv2:max-access "read-only";
smiv2:oid "1.3.6.1.2.1.2.2.1.1";
}7.3. Non-Augmenting Conceptual Table Translation Rules 🌈
an OBJECT-TYPE macro invocation that defines a non-augmenting conceptual table gets translated to a YANG container statement, named after the OBJECT-TYPE macro invocation. that container gets created in the top-level container for the SMIv2 module. the macro's clauses get translated like this 💖
- The SMIv2 SYNTAX clause is ignored
- The SMIv2 UNITS clause is ignored.
- The SMIv2 MAX-ACCESS clause is ignored.
- The SMIv2 STATUS clause is mapped to the YANG status statement. the YANG status statement generation is skipped if the STATUS clause value is current.
- The SMIv2 DESCRIPTION clause is mapped to the YANG description statement.
- The SMIv2 REFERENCE clause is mapped to the YANG reference statement.
- The value of the SMIv2 OBJECT-TYPE macro invocation is translated into an
smiv2:oidstatement. refer to the YANG extension defined in Section 10.
an OBJECT-TYPE macro invocation that defines a conceptual row gets translated to a YANG list statement. that list lives inside the YANG container representing the conceptual table, and it uses the name of the row's OBJECT-TYPE macro invocation 🦋 the OBJECT-TYPE macro clauses get translated as follows:
- The SMIv2 SYNTAX clause is ignored.
- The SMIv2 UNITS clause is ignored.
- The SMIv2 MAX-ACCESS clause is ignored.
- The SMIv2 STATUS clause is mapped to the YANG status statement. the YANG status statement generation is skipped if the STATUS clause value is current.
- The SMIv2 DESCRIPTION clause is mapped to the YANG description statement.
- The SMIv2 REFERENCE clause is mapped to the YANG reference statement.
- The SMIv2 INDEX clause is mapped to the YANG key clause, listing the columnar objects that form the key of the YANG list. if the same object shows up more than once in the INDEX clause, append '_<n>' to the duplicate object name(s), where '<n>' counts the occurrences of the object in the INDEX clause, starting from 2. additional leaf statements must be created to define the leafs introduced 🧁
- If the SMIv2 INDEX clause contains the IMPLIED keyword, then an
smiv2:impliedstatement is generated to record the name of the object preceded by the IMPLIED keyword. refer to the YANG extension defined in Section 10. - The value of the SMIv2 OBJECT-TYPE macro invocation is translated into an
smiv2:oidstatement. refer to the YANG extension defined in Section 10.
inside the list statement, YANG leaf statements get created for columnar objects as described in Section 7.1 ✨ and for objects listed in the SMIv2 INDEX clause that aren't part of the conceptual table itself, YANG leaf statements of type leafref pointing to the referenced definition get created too 🫶
7.4. Example: ifTable of the IF-MIB 🌸
here's the translation of the ifTable definition of the IF-MIB [RFC2863] 💅
container ifTable {
description
"A list of interface entries. The number of entries is
given by the value of ifNumber.";
smiv2:oid "1.3.6.1.2.1.2.2";
list ifEntry {
key "ifIndex";
description
"An entry containing management information applicable to a
particular interface.";
smiv2:oid "1.3.6.1.2.1.2.2.1";
leaf ifIndex {
type if-mib:InterfaceIndex;
description
"A unique value, greater than zero, for each interface. It
is recommended that values are assigned contiguously
starting from 1. The value for each interface sub-layer
must remain constant at least from one re-initialization of
the entity's network management system to the next re-
initialization.";
smiv2:max-access "read-only";
smiv2:oid "1.3.6.1.2.1.2.2.1.1";
}
// ...
}
}7.5. Example: ifRcvAddressTable of the IF-MIB 🦋
and here's the translation of the ifRcvAddressTable definition of the IF-MIB [RFC2863] 🧚
container ifRcvAddressTable {
description
"This table contains an entry for each address (broadcast,
multicast, or uni-cast) for which the system will receive
packets/frames on a particular interface, except as follows:
- for an interface operating in promiscuous mode, entries are
only required for those addresses for which the system would
receive frames were it not operating in promiscuous mode.
- for 802.5 functional addresses, only one entry is required,
for the address which has the functional address bit ANDed
with the bit mask of all functional addresses for which the
interface will accept frames.
A system is normally able to use any unicast address which
corresponds to an entry in this table as a source address.";
smiv2:oid "1.3.6.1.2.1.31.1.4";
list ifRcvAddressEntry {
key "ifIndex ifRcvAddressAddress";
description
"A list of objects identifying an address for which the
system will accept packets/frames on the particular
interface identified by the index value ifIndex.";
smiv2:oid "1.3.6.1.2.1.31.1.4.1";
leaf ifIndex {
type leafref {
path "/if-mib:IF-MIB/if-mib:ifTable" +
"/if-mib:ifEntry/if-mib:ifIndex";
}
}
leaf ifRcvAddressAddress {
type yang:phys-address;
description
"An address for which the system will accept packets/frames
on this entry's interface.";
smiv2:max-access "not-accessible";
smiv2:oid "1.3.6.1.2.1.31.1.4.1.1";
}
// ...
}
}7.6. Example: alHostTable of the RMON2-MIB 🌸
Okay, this one is giving big table energy. Here's the alHostTable from the RMON2-MIB [RFC4502] translated into YANG.
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:protocolDirEntry/"
+ "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 💅
Okay, so an OBJECT-TYPE macro that defines an augmenting conceptual table turns into a YANG smiv2:alias statement. Check out the YANG extension in Section 10 for the details. Here's how each clause gets translated:
- The SMIv2 SYNTAX clause is ignored.
- The SMIv2 UNITS clause is ignored.
- The SMIv2 MAX-ACCESS clause is ignored.
- The SMIv2 STATUS clause maps to the YANG
statusstatement. The YANGstatusstatement is skipped if the STATUS clause value is current, because that's the default vibe anyway 🙈 - The SMIv2 DESCRIPTION clause maps to the YANG
descriptionstatement. - The SMIv2 REFERENCE clause maps to the YANG
referencestatement. - The value of the SMIv2 OBJECT-TYPE macro invocation is translated into an
smiv2:oidstatement. Refer to the YANG extension defined in Section 10.
An OBJECT-TYPE macro that defines a conceptual row augmentation becomes a YANG smiv2:alias statement and a YANG augment statement. The augment statement uses the path to the augmented table as its argument. The clauses of the OBJECT-TYPE macro are translated like this:
- The SMIv2 SYNTAX clause is ignored.
- The SMIv2 UNITS clause is ignored.
- The SMIv2 MAX-ACCESS clause is ignored.
- The SMIv2 STATUS clause maps to the YANG
statusstatement. The YANGstatusstatement is skipped if the STATUS clause value is current. - The SMIv2 DESCRIPTION clause maps to the YANG
descriptionstatement. - The SMIv2 REFERENCE clause maps to the YANG
referencestatement. - The value of the SMIv2 OBJECT-TYPE macro invocation is translated into an
smiv2:oidstatement. Refer to the YANG extension defined in Section 10.
Inside the augment statement, YANG leaf statements get created the way Section 7.1 describes. ✨
7.8. Example: ifXTable of the IF-MIB 🎀
Here's the ifXTable from the IF-MIB [RFC2863], translated.
smiv2:alias "ifXTable" {
description
"A list of interface entries. The number of entries is
given by the value of ifNumber. This table contains
additional objects for the interface table.";
smiv2:oid "1.3.6.1.2.1.31.1.1";
}
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
"An entry containing additional management information
applicable to a particular interface.";
smiv2:oid "1.3.6.1.2.1.31.1.1.1";
leaf ifName {
type snmpv2-tc:DisplayString;
description
"The textual name of the interface. The value of this
object should be the name of the interface as assigned by
the local device and should be suitable for use in commands
entered at the device's `console'. This might be a text
name, such as `le0' or a simple port number, such as `1',
depending on the interface naming syntax of the device. If
several entries in the ifTable together represent a single
interface as named by the device, then each will have the
same value of ifName. Note that for an agent which responds
to SNMP queries concerning an interface on some other
(proxied) device, then the value of ifName for such an
interface is the proxied device's local name for it.
If there is no local name, or this object is otherwise not
applicable, then this object contains a zero-length string.";
smiv2:max-access "read-only";
smiv2:oid "1.3.6.1.2.1.31.1.1.1.1";
}
// ...
}8. Translation of the OBJECT-IDENTITY Macro 🦋
SMIv2 uses invocations of the OBJECT-IDENTITY macro to define information about an OBJECT IDENTIFIER assignment. Invocations of the OBJECT-IDENTITY macro MUST be translated into YANG identity statements, as detailed below. No skipping allowed, bestie!
8.1. OBJECT-IDENTITY Translation Rules 🍓
The name of the OBJECT-IDENTITY macro invocation becomes the name of the generated identity statement. The generated identity statement uses smiv2:object-identity, which is defined in Section 10, as its base. The clauses of the SMIv2 OBJECT-IDENTITY macro map to YANG statements like this:
- The SMIv2 STATUS clause maps to the YANG
statusstatement. The YANGstatusstatement is skipped if the STATUS clause value is current. - The SMIv2 DESCRIPTION clause maps to the YANG
descriptionstatement. - The SMIv2 REFERENCE clause maps to the YANG
referencestatement. - The value of the SMIv2 OBJECT-IDENTITY macro invocation is translated into an
smiv2:oidstatement. Refer to the YANG extension defined in Section 10.
8.2. Example: diffServTBParamSimpleTokenBucket of the DIFFSERV-MIB 🧚
Here's diffServTBParamSimpleTokenBucket from the DIFFSERV-MIB [RFC3289], translated. (Please note that the description should refer to RFC 3290, Section 5.1.3.)
identity diffServTBParamSimpleTokenBucket {
base "smiv2:object-identity";
description
"Two Parameter Token Bucket Meter as described in the Informal
Differentiated Services Model section 5.2.3.";
smiv2:oid "1.3.6.1.2.1.97.3.1.1";
}9. Translation of the NOTIFICATION-TYPE Macro 🔔
SMIv2 gives us the NOTIFICATION-TYPE macro for defining event notifications. YANG has the notification statement for the same job. Invocations of the NOTIFICATION-TYPE macro MUST be translated into YANG notification statements, as detailed below. Yes, MUST, no exceptions, periodt 💅
9.1. NOTIFICATION-TYPE Translation Rules 🌈
The name of the NOTIFICATION-TYPE macro invocation becomes the name of the generated notification statement. The clauses of the NOTIFICATION-TYPE macro map to YANG statements embedded in the notification statement, like so:
- The SMIv2 OBJECTS clause maps to a sequence of YANG containers. For each object listed in the OBJECTS clause value, a YANG
containerstatement is generated. The name of this container is the string "object-<n>", where <n> is the position of the object in the value of the OBJECTS clause (the first element has position 1). If the current object belongs to a conceptual table, then a sequence ofleafstatements is generated for each INDEX object of the conceptual table. These leafs are named after the INDEX objects and are of typeleafref. Finally, aleafstatement is generated, named after the current object. If the current object has a MAX-ACCESS of "read-only", "read-write", or "read-create", then the generated leaf is of typeleafref. Otherwise, if the current object has a MAX-ACCESS of "accessible-for-notify", then a leaf is generated, following the steps in Section 7.1. 🫶 - The SMIv2 STATUS clause maps to the YANG
statusstatement. The YANGstatusstatement is skipped if the STATUS clause value is current. - The SMIv2 DESCRIPTION clause maps to the YANG
descriptionstatement. - The SMIv2 REFERENCE clause maps to the YANG
referencestatement. - The value of the SMIv2 NOTIFICATION-TYPE macro invocation is translated into an
smiv2:oidstatement. Refer to the YANG extension defined in Section 10.
9.2. Example: linkDown NOTIFICATION-TYPE of IF-MIB ✨
okay so here's the translation of the linkDown notification from the IF-MIB [RFC2863] 🦋 it's giving "watch the link go down in real time" energy 📉
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 {
leaf ifIndex {
type leafref {
path "/if-mib:IF-MIB/if-mib:ifTable" +
"/if-mib:ifEntry/if-mib:ifIndex";
}
}
}
container object-2 {
leaf ifIndex {
type leafref {
path "/if-mib:IF-MIB/if-mib:ifTable" +
"/if-mib:ifEntry/if-mib:ifIndex";
}
}
leaf ifAdminStatus {
type leafref {
path "/if-mib:IF-MIB/if-mib:ifTable" +
"/if-mib:ifEntry/if-mib:ifAdminStatus";
}
}
}
container object-3 {
leaf ifIndex {
type leafref {
path "/if-mib:IF-MIB/if-mib:ifTable" +
"/if-mib:ifEntry/if-mib:ifIndex";
}
}
leaf ifOperStatus {
type leafref {
path "/if-mib:IF-MIB/if-mib:ifTable" +
"/if-mib:ifEntry/if-mib:ifOperStatus";
}
}
}
}10. YANG Language Extension Definition 🎀
okay this section is all about some YANG extension statements 💅 they're for capturing bits of info from SMIv2 modules that don't turn into core YANG statements. The YANG module references [RFC2578] and [RFC2579] 🌸
Here's the module itself:
<CODE BEGINS> file "ietf-yang-smiv2@2012-06-22.yang"
module ietf-yang-smiv2 {
namespace "urn:ietf:params:xml:ns:yang:ietf-yang-smiv2";
prefix "smiv2";
organization
"IETF NETMOD (NETCONF Data Modeling Language) Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org>
WG Chair: David Kessens
<mailto:david.kessens@nsn.com>
WG Chair: Juergen Schoenwaelder
<mailto:j.schoenwaelder@jacobs-university.de>
Editor: Juergen Schoenwaelder
<mailto:j.schoenwaelder@jacobs-university.de>";
description
"This module defines YANG extensions that are used to translate
SMIv2 concepts into YANG.
Copyright (c) 2012 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 6643; see
the RFC itself for full legal notices.";
revision 2012-06-22 {
description
"Initial revision.";
reference
"RFC 6643: Translation of Structure of Management Information
Version 2 (SMIv2) MIB Modules to YANG Modules";
}
identity object-identity {
description
"Base identity for all SMIv2 OBJECT-IDENTITYs.";
}
typedef opaque {
type binary;
description
"The Opaque type supports the capability to pass arbitrary ASN.1
syntax. A value is encoded using the ASN.1 Basic Encoding Rules
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
"RFC 2578: Structure of Management Information Version 2 (SMIv2)";
}
extension display-hint {
argument "format";
description
"The display-hint statement takes as an argument the DISPLAY-HINT
assigned to an SMIv2 textual convention.";
reference
"RFC 2579: Textual Conventions for SMIv2";
}
extension max-access {
argument "access";
description
"The max-access statement takes as an argument the MAX-ACCESS
assigned to an SMIv2 object definition.
The MAX-ACCESS value is SMIv2 specific and has no impact on
the access provided to YANG objects through protocols such
as NETCONF.";
reference
"RFC 2578: Structure of Management Information Version 2 (SMIv2)";
}
extension defval {
argument "value";
description
"The defval statement takes as an argument a default value
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
"RFC 2578: 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
"RFC 2578: Structure of Management Information Version 2 (SMIv2)";
}
extension alias {
argument "descriptor";
description
"The alias statement introduces an SMIv2 descriptor. The body of
the alias statement is expected to contain an oid statement that
provides the numeric OID associated with the descriptor.";
reference
"RFC 2578: 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
"RFC 2578: 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 an smiv2:oid or smiv2:subid substatement.";
reference
"RFC 2578: Structure of Management Information Version 2 (SMIv2)";
}
}
<CODE ENDS>11. Implementing Configuration Data Nodes 🔐
okay real talk, this part is so important bestie 🫶 even when SMIv2 objects are read-write or read-create, the translation ends up as read-only (config false) YANG objects 🙈 The big reason is that SNMP and NETCONF handle persistency super differently. With SNMP, a writable object's persistency depends on either its own definition (the text in the DESCRIPTION clause) or the persistency of the conceptual row it lives in, sometimes controlled by a columnar object using the StorageType textual convention. With NETCONF, configuration persistency is decided by the underlying datastore 💾 Plus NETCONF as defined in [RFC6241] doesn't have a standard operation to change operational state. The <edit-config> and <copy-config> operations only touch configuration data. So yeah, it's not possible to automatically generate YANG configuration data nodes from SMIv2 definitions 😭
BUT (lowkey the plot twist 👑) for selected SMIv2 objects where the SNMP and NETCONF persistency semantics line up, implementations may choose to implement some YANG data nodes generated from SMIv2 definitions as configuration data nodes ✨ That kind of deviation from the generated read-only YANG module should be formally documented in a separate YANG module that uses YANG deviation statements to flip the config property from false to true for those nodes 🦋 Deviations that only change config from false to true, with no other changes to the semantics of the data node, don't affect compliance with the YANG module generated from an SMIv2 module. Periodt 💖
11.1. Example: addressMapControlTable of RMON2-MIB 🍓
this example shows how some columnar objects of the addressMapControlTable of the RMON2-MIB [RFC4502] can become YANG configuration data nodes 🧚 Note that YANG deviations only affect the property of the target node and are not inherited downwards 💅
module acme-RMON2-MIB-deviations {
namespace "http://acme.example.com/RMON2-MIB-deviations";
prefix "acme-rmon2-devs";
import RMON2-MIB {
prefix "rmon2-mib";
revision-date 2006-05-02;
}
revision 2012-01-11 {
description
"First version.";
}
deviation "/rmon2-mib:RMON2-MIB" {
deviate replace {
config true;
}
}
deviation "/rmon2-mib:RMON2-MIB/"
+ "rmon2-mib:addressMapControlTable" {
deviate replace {
config true;
}
}
deviation "/rmon2-mib:RMON2-MIB/"
+ "rmon2-mib:addressMapControlTable/"
+ "rmon2-mib:addressMapControlEntry" {
deviate replace {
config true;
}
}
deviation "/rmon2-mib:RMON2-MIB/"
+ "rmon2-mib:addressMapControlTable/"
+ "rmon2-mib:addressMapControlEntry/"
+ "rmon2-mib:addressMapControlIndex" {
deviate replace {
config true;
}
}
deviation "/rmon2-mib:RMON2-MIB/"
+ "rmon2-mib:addressMapControlTable/"
+ "rmon2-mib:addressMapControlEntry/"
+ "rmon2-mib:addressMapControlDataSource" {
deviate replace {
config true;
}
}
deviation "/rmon2-mib:RMON2-MIB/"
+ "rmon2-mib:addressMapControlTable/"
+ "rmon2-mib:addressMapControlEntry/"
+ "rmon2-mib:addressMapControlOwner" {
deviate replace {
config true;
}
}
}A NETCONF server that implements the RMON2-MIB module with these deviations would advertise the following capabilities in its <hello> message 📣 (whitespace has been added so it's easier to read 🎀):
<capability>
urn:ietf:params:xml:ns:yang:smiv2:RMON2-MIB?
module=RMON2-MIB&
revision=2006-05-02&
deviations=acme-RMON2-MIB-deviations
</capability>
<capability>
http://acme.example.com/RMON2-MIB-deviations?
module=acme-RMON2-MIB-deviations&
revision=2012-01-11
</capability>12. IANA Considerations 📝✨
okay so this section is all about the registry paperwork 💅 this document registers two URIs in the IETF XML registry [RFC3688]. following the format from RFC 3688, these are the registrations that got made:
URI: urn:ietf:params:xml:ns:yang:ietf-yang-smiv2
Registrant Contact: The NETMOD WG of the IETF.
XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:smiv2
Registrant Contact: The NETMOD WG of the IETF.
XML: N/A, the requested URI is an XML namespace.the doc also registers a YANG module in the YANG Module Names registry [RFC6020] 🎀 here's how that one looks:
Name: ietf-yang-smiv2
Namespace: urn:ietf:params:xml:ns:yang:ietf-yang-smiv2
Prefix: smiv2
Reference: RFC 664313. Security Considerations 🔐💀
okay bestie, this part is serious, so pay attention 👀 this document defines a translation of SMIv2 MIB modules into YANG modules, which lets NETCONF users get read-only access (config false) to data objects defined in SMIv2 MIB modules 🦋 the translation itself has no security impact on the Internet, so the translating part is chill.
BUT. anyone using YANG data models generated from SMIv2 data models that were published in the RFC series should check the security considerations of those respective RFCs 🚨 those sections explain which objects are sensitive and important to protect, so don't skip them, periodt. NETCONF users are also encouraged to use the NETCONF access control model [RFC6536], which lets you write access control rules to guard potentially sensitive info. 🔒 protect your data, babes!
14. Acknowledgements 🫶
the author wants to thank the following people for their super helpful comments on the different draft versions of this document: Andy Bierman, Benoit Claise, Martin Bjorklund, Leif Johansson, David Reid, Dan Romascanu, and David Spakes 💜 literal legends.
15. References 📚
15.1. Normative References 🌸
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Textual Conventions for SMIv2",
STD 58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Conformance Statements for SMIv2", STD 58, RFC 2580,
April 1999.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
[RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021,
October 2010.15.2. Informative References 🧚
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, June 2000.
[RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information
Base for the Differentiated Services Architecture",
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,
January 2004.
[RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB
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.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, June 2011.
[RFC6536] Bierman, A., Ed. and M. Bjorklund, Ed., "Network
Configuration Protocol (NETCONF) Access Control Model",
RFC 6536, March 2012.Appendix A. Mapping of Well-Known Types (Normative) 🎀
this normative appendix is the cheat sheet for mapping SMIv2 types to YANG types 🍓 the mapping is fully consistent with Tables 1 and 2 of [RFC6021], so it's totally aligned.
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 UTF-8 or 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: uriAppendix B. Module Prefix Generation (Informative) 🌈
this section explains an algorithm for generating module prefixes to use in import statements 💖 the input is a set of prefixes (usually pulled from imported module names) plus one specific module name that needs to become a prefix. the algorithm spits out a prefix for that module name that's unique within the set, so no clashes, no drama.
+-----------------+--------+
| YANG Module | Prefix |
+-----------------+--------+
| ietf-yang-types | yang |
| ietf-inet-types | inet |
| ietf-yang-smiv2 | smiv2 |
+-----------------+--------+
Table 1: Special Prefixes For Well-Known YANG Moduleshere's the step-by-step, bestie:
- First, the algorithm tries some predefined translations that map well-known YANG modules to short prefixes (see Table 1). If a fixed translation exists and gives a conflict-free prefix, that fixed translation gets used. ✨
- Otherwise, the prefix gets generated by tokenizing the YANG module name, using hyphens as token separators. The tokens are converted to lowercase characters. The prefix then becomes the shortest sequence of those tokens joined with hyphens, as long as it has at least two tokens and is unique among all prefixes used in the YANG module. 🦋
in the worst case, the prefix from an SMIv2 module name just becomes that module name in lowercase 😭 but on average, you get way shorter prefixes, so it's giving efficiency 💅
Author's Address 🖋️
Juergen Schoenwaelder
Jacobs University
EMail: j.schoenwaelder@jacobs-university.de📦 where this page comes from
- ietf: rfc6643 2012-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms