draft-ietf-netmod-smi-yang-05.txt   rfc6643.txt 
Network Working Group J. Schoenwaelder Internet Engineering Task Force (IETF) J. Schoenwaelder
Internet-Draft Jacobs University Request for Comments: 6643 Jacobs University
Intended status: Standards Track April 20, 2012 Category: Standards Track July 2012
Expires: October 22, 2012 ISSN: 2070-1721
Translation of SMIv2 MIB Modules to YANG Modules Translation of Structure of Management Information Version 2 (SMIv2)
draft-ietf-netmod-smi-yang-05 MIB Modules to YANG Modules
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 Network Configuration Protocol
procedure calls, and NETCONF notifications. The Structure of (NETCONF), NETCONF remote procedure calls, and NETCONF notifications.
Management Information (SMIv2) defines fundamental data types, an The Structure of Management Information (SMIv2) defines fundamental
object model, and the rules for writing and revising MIB modules for data types, an object model, and the rules for writing and revising
use with the SNMP protocol. This document defines a translation of MIB modules for use with the Simple Network Management Protocol
SMIv2 MIB modules into YANG modules, enabling read-only (config (SNMP). This document defines a translation of SMIv2 MIB modules
false) access to data objects defined in SMIv2 MIB modules via into YANG modules, enabling read-only (config false) access to data
NETCONF. objects defined in SMIv2 MIB modules via NETCONF.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on October 22, 2012. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6643.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 Well Known Types . . . . . . . . . . . . . . . . . 5 2. Mapping of Well-Known Types . . . . . . . . . . . . . . . . . 4
3. Translation of SMIv2 Modules and SMIv2 IMPORT Clauses . . . . 6 3. Translation of SMIv2 Modules and SMIv2 IMPORT Clauses . . . . 5
3.1. Example: IMPORTS of IF-MIB . . . . . . . . . . . . . . . . 7 3.1. Example: IMPORTS of IF-MIB . . . . . . . . . . . . . . . . 6
4. Translation of the MODULE-IDENTITY Macro . . . . . . . . . . . 8 4. Translation of the MODULE-IDENTITY Macro . . . . . . . . . . . 7
4.1. MODULE-IDENTITY Translation Rules . . . . . . . . . . . . 8 4.1. MODULE-IDENTITY Translation Rules . . . . . . . . . . . . 7
4.2. Example: MODULE-IDENTITY of IF-MIB . . . . . . . . . . . . 9 4.2. Example: MODULE-IDENTITY of IF-MIB . . . . . . . . . . . . 8
5. Translation of the TEXTUAL-CONVENTION Macro . . . . . . . . . 10 5. Translation of the TEXTUAL-CONVENTION Macro . . . . . . . . . 9
5.1. TEXTUAL-CONVENTION Translation Rules . . . . . . . . . . . 10 5.1. TEXTUAL-CONVENTION Translation Rules . . . . . . . . . . . 9
5.2. Example: OwnerString and InterfaceIndex of IF-MIB . . . . 11 5.2. Example: OwnerString and InterfaceIndex of IF-MIB . . . . 10
5.3. Example: IfDirection of the DIFFSERV-MIB . . . . . . . . . 11 5.3. Example: IfDirection of the DIFFSERV-MIB . . . . . . . . . 11
6. Translation of OBJECT IDENTIFIER Assignments . . . . . . . . . 13 6. Translation of OBJECT IDENTIFIER Assignments . . . . . . . . . 11
7. Translation of the OBJECT-TYPE Macro . . . . . . . . . . . . . 14 7. Translation of the OBJECT-TYPE Macro . . . . . . . . . . . . . 11
7.1. Scalar and Columnar Object Translation Rules . . . . . . . 14 7.1. Scalar and Columnar Object Translation Rules . . . . . . . 11
7.2. Example: ifNumber and ifIndex of the IF-MIB . . . . . . . 15 7.2. Example: ifNumber and ifIndex of the IF-MIB . . . . . . . 13
7.3. Non-Augmenting Conceptual Table Translation Rules . . . . 16 7.3. Non-Augmenting Conceptual Table Translation Rules . . . . 13
7.4. Example: ifTable of the IF-MIB . . . . . . . . . . . . . . 18 7.4. Example: ifTable of the IF-MIB . . . . . . . . . . . . . . 15
7.5. Example: ifRcvAddressTable of the IF-MIB . . . . . . . . . 18 7.5. Example: ifRcvAddressTable of the IF-MIB . . . . . . . . . 16
7.6. Example: alHostTable of the RMON2-MIB . . . . . . . . . . 20 7.6. Example: alHostTable of the RMON2-MIB . . . . . . . . . . 17
7.7. Augmenting Conceptual Tables Translation Rules . . . . . . 21 7.7. Augmenting Conceptual Tables Translation Rules . . . . . . 18
7.8. Example: ifXTable of the IF-MIB . . . . . . . . . . . . . 22 7.8. Example: ifXTable of the IF-MIB . . . . . . . . . . . . . 20
8. Translation of the OBJECT-IDENTITY Macro . . . . . . . . . . . 24 8. Translation of the OBJECT-IDENTITY Macro . . . . . . . . . . . 21
8.1. OBJECT-IDENTITY Translation Rules . . . . . . . . . . . . 24 8.1. OBJECT-IDENTITY Translation Rules . . . . . . . . . . . . 21
8.2. Example: diffServTBParamSimpleTokenBucket of the 8.2. Example: diffServTBParamSimpleTokenBucket of the
DIFFSERV-MIB . . . . . . . . . . . . . . . . . . . . . . . 24 DIFFSERV-MIB . . . . . . . . . . . . . . . . . . . . . . . 21
9. Translation of the NOTIFICATION-TYPE Macro . . . . . . . . . . 25 9. Translation of the NOTIFICATION-TYPE Macro . . . . . . . . . . 22
9.1. NOTIFICATION-TYPE Translation Rules . . . . . . . . . . . 25 9.1. NOTIFICATION-TYPE Translation Rules . . . . . . . . . . . 22
9.2. Example: linkDown NOTIFICATION-TYPE of IF-MIB . . . . . . 25 9.2. Example: linkDown NOTIFICATION-TYPE of IF-MIB . . . . . . 23
10. YANG Language Extension Definition . . . . . . . . . . . . . . 28 10. YANG Language Extension Definition . . . . . . . . . . . . . . 24
11. Implementing Configuration Data Nodes . . . . . . . . . . . . 32 11. Implementing Configuration Data Nodes . . . . . . . . . . . . 27
11.1. Example: addressMapControlTable of RMON2-MIB . . . . . . . 32 11.1. Example: addressMapControlTable of RMON2-MIB . . . . . . . 28
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
13. Security Considerations . . . . . . . . . . . . . . . . . . . 36 13. Security Considerations . . . . . . . . . . . . . . . . . . . 30
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
15.1. Normative References . . . . . . . . . . . . . . . . . . . 38 15.1. Normative References . . . . . . . . . . . . . . . . . . . 31
15.2. Informative References . . . . . . . . . . . . . . . . . . 38 15.2. Informative References . . . . . . . . . . . . . . . . . . 31
Appendix A. Mapping of Well Known Types (normative) . . . . . . . 40 Appendix A. Mapping of Well-Known Types (Normative) . . . . . . . 33
Appendix B. Module Prefix Generation (informative) . . . . . . . 43 Appendix B. Module Prefix Generation (Informative) . . . . . . . 35
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction 1. Introduction
This document describes a 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
(config false) access to SMIv2 objects defined in SMIv2 MIB modules (config false, as defined in Section 7.19.1 of RFC 6020) access to
via NETCONF [RFC6241]. For a discussion why SMIv2 read-write or SMIv2 objects defined in SMIv2 MIB modules via NETCONF [RFC6241].
read-create objects are translated to read-only (config false) YANG For a discussion why SMIv2 read-write or read-create objects are
objects, see Section 11. translated to read-only (config false) YANG objects, see Section 11.
YANG modules generated from SMIv2 modules should not be modified. YANG modules generated from SMIv2 modules should not be modified.
Any necessary changes should be made by modifying the original SMIv2 Any necessary changes should be made by modifying the original SMIv2
modules (with proper updates of the SMIv2 LAST-UPDATED and REVISION modules (with proper updates of the SMIv2 LAST-UPDATED and REVISION
clauses) and then running the translation defined in this memo again. clauses) and then running the translation defined in this memo again.
Note that this does not affect the usage of YANG augments and or YANG Note that this does not affect the usage of YANG augments and or YANG
deviations: YANG modules generated from SMIv2 modules can be deviations: YANG modules generated from SMIv2 modules can be
augmented and like any other YANG module and YANG deviations can be augmented like any other YANG module, and YANG deviations can be used
used to document how an implementation deviates from the generated to document how an implementation deviates from the generated YANG
YANG module. module.
SMIv1 modules can be converted to YANG by first following the rules SMIv1 modules can be converted to YANG by first following the rules
in [RFC3584] to convert the SMIv1 module to SMIv2 and then following in [RFC3584] to convert the SMIv1 module to SMIv2 and then following
the rules in this document to convert the obtained SMIv2 module to the rules in this document to convert the obtained SMIv2 module to
YANG. YANG.
The SMIv2 to YANG mapping is illustrated by examples showing the The SMIv2-to-YANG mapping is illustrated by examples showing the
translation of parts of the IF-MIB [RFC2863], the DIFFSERV-MIB translation of parts of the IF-MIB [RFC2863], the DIFFSERV-MIB
[RFC3289], and the RMON2-MIB [RFC4502] SMIv2 module. [RFC3289], and the RMON2-MIB [RFC4502] SMIv2 modules.
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 Well Known 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 Appendix A. 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. An implementation MUST format an OCTET STRING value
mapping of the INTEGER type depends on its usage as an enumeration or according to the DISPLAY-HINT, as described in RFC 2579. If an
a 32-bit integral type. Implementations should provide OCTECT STRING type does not have an associated DISPLAY-HINT, the
implementation specific options to handle situations where DISPLAY- binary type is used. Similarly, the mapping of the INTEGER type
HINTs are added during a revision of a module and backwards depends on its usage as an enumeration or a 32-bit integral type.
compatibility must be preserved, i.e., an added DISPLAY-HINT needs to Implementations should provide implementation-specific options to
be ignored. handle situations where DISPLAY- HINTs are added during a revision of
a module and backwards compatibility must be preserved, i.e., an
added DISPLAY-HINT needs to be ignored.
The mappings shown in Appendix A may require to import the ietf-yang- The mappings shown in Appendix A may require to import the ietf-yang-
types, ietf-inet-types, or ietf-yang-smiv2 YANG modules since some types, ietf-inet-types, or ietf-yang-smiv2 YANG modules since some
SMIv2 types and textual conventions map to YANG types defined in the SMIv2 types and textual conventions map to YANG types defined in the
ietf-yang-types and ietf-inet-types YANG modules defined in [RFC6021] ietf-yang-types and ietf-inet-types YANG modules defined in [RFC6021]
and the ietf-yang-smiv2 YANG module defined in this document. and the ietf-yang-smiv2 YANG module defined in this document.
Implementations MUST add any additional imports required by the type Implementations MUST add any additional imports required by the type
mapping. mapping.
3. 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 SMIv2 modules are mapped to corresponding YANG modules. The
generated YANG module name MUST be the same as the SMIv2 module name. generated YANG module name MUST be the same as the SMIv2 module name.
The YANG namespace MUST be constructed out of the IANA registered The YANG namespace MUST be constructed out of the IANA-registered
prefix urn:ietf:params:xml:ns:yang:smiv2: (see Section 12) followed prefix urn:ietf:params:xml:ns:yang:smiv2: (see Section 12) followed
by the SMIv2 module name. Since SMIv2 module names can be assumed to by the SMIv2 module name. Since SMIv2 module names can be assumed to
be unique (see Section 3 in [RFC2578]), the resulting YANG namespace be unique (see Section 3 in [RFC2578]), the resulting YANG namespace
is unique. is unique.
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 Appendix B. 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
Appendix B 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.
In order to produce correct and complete YANG import statements, the In order to produce correct and complete YANG import statements, the
following rules MUST be used: following rules MUST be used:
o Process each item in each SMIv2 IMPORT clause as follows: o Process each item in each SMIv2 IMPORT clause as follows:
1. If an import statement for this SMIv2 module has already been 1. If an import statement for this SMIv2 module has already been
generated, then ignore this item. generated, then ignore this item.
skipping to change at page 8, line 7 skipping to change at page 7, line 7
prefix "if-mib"; prefix "if-mib";
import IANAifType-MIB { prefix "ianaiftype-mib"; } import IANAifType-MIB { prefix "ianaiftype-mib"; }
import SNMPv2-TC { prefix "snmpv2-tc"; } import SNMPv2-TC { prefix "snmpv2-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"; }
} }
4. Translation of the MODULE-IDENTITY Macro 4. Translation of the MODULE-IDENTITY Macro
The SMIv2 requires an invocation of the MODULE-IDENTITY macro to SMIv2 requires an invocation of the MODULE-IDENTITY macro to provide
provide contact and revision history for a MIB module. The clauses contact and revision history for a MIB module. The clauses of the
of the SMIv2 MODULE-IDENTITY macro MUST be translated into YANG SMIv2 MODULE-IDENTITY macro MUST be translated into YANG statements
statements as detailed below. as detailed below.
4.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
skipping to change at page 8, line 34 skipping to change at page 7, line 34
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 A top-level YANG container is generated. The container's name is o A top-level YANG container is generated. The container's name is
the SMIv2 module name and the container MUST be config false. The the SMIv2 module name, and the container MUST be config false.
generation of the top-level container MAY be skipped if the SMIv2 The generation of the top-level container MAY be skipped if the
module does not define any objects that go into the top-level SMIv2 module does not define any objects that go into the top-
container (e.g., an SMIv2 module only defining textual level container (e.g., an SMIv2 module only defining textual
conventions). conventions).
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 is translated into an smiv2:oid statement contained in an IDENTITY is translated into an smiv2:oid statement contained in an
smiv2:alias statement representing the MODULE-IDENTITY macro smiv2:alias statement representing the MODULE-IDENTITY macro
invocation. Refer to the YANG extension defined in Section 10. invocation. 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, or
revision statements. revision statements.
4.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";
skipping to change at page 10, line 39 skipping to change at page 9, line 39
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,
SMIv2 length restrictions are mapped to YANG length statements. while SMIv2 length restrictions are mapped to YANG length
SMIv2 INTEGER enumerations are mapped to YANG enum/value statements. SMIv2 INTEGER enumerations are mapped to YANG enum/
statements. SMIv2 BITS are mapped to YANG bit/position value statements. SMIv2 BITS are mapped to YANG bit/position
statements. For OCTET STRING types that are mapped to a YANG statements. For OCTET STRING types that are mapped to a YANG
string base type (see Section 2), the length specified in the YANG string base type (see Section 2), the length specified in the YANG
length statement must be consistent with the stringified length statement must be consistent with the stringified
representation of values. If an implementation is unable to representation of values. If an implementation is unable to
derive a proper length restrictions, then the YANG length derive a proper length restrictions, then the YANG length
statement MUST be omitted. statement MUST be omitted.
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
skipping to change at page 12, line 5 skipping to change at page 11, line 10
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";
} }
5.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
"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.";
} }
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 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 translated into smiv2:alias statements. Refer to the assignments are translated into smiv2:alias statements. Refer to the
YANG extension defined in Section 10. YANG extension defined in Section 10.
7. Translation of the OBJECT-TYPE Macro 7. Translation of the OBJECT-TYPE Macro
skipping to change at page 14, line 22 skipping to change at page 11, line 46
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.
7.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. Additionally, columnar objects with a MAX-ACCESS of statements. Additionally, columnar objects with a MAX-ACCESS of
accessible-for-notify are translated to YANG leaf statements if that "accessible-for-notify" are translated to YANG leaf statements if
columnar object is part of the INDEX clause of the table containing that columnar object is part of the INDEX clause of the table
that columnar object. The name of the leaf is the name associated containing that columnar object. The name of the leaf is the name
with the SMIv2 OBJECT-TYPE macro invocation. SMIv2 OBJECT-TYPE macro associated with the SMIv2 OBJECT-TYPE macro invocation. SMIv2
invocations with a MAX-ACCESS of "accessible-for-notify" are not OBJECT-TYPE macro invocations with a MAX-ACCESS of
translated to YANG data tree leafs but instead into YANG notification "accessible-for-notify" are not translated to YANG data tree leafs
leafs. but instead are translated into YANG notification leafs.
Leaf statements for scalar objects are created in a container Leaf statements for scalar objects are created in a container
representing the scalar's parent node in the OID tree. This representing the scalar's parent node in the OID tree. This
container is named after the scalar's parent node in the OID tree and container is named after the scalar's parent node in the OID tree and
placed in the top-level container representing the SMIv2 module, see 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 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 multiple names, the automatic translation MUST fail with an error,
the name clash needs to be investigated and fixed manually. In case and the name clash needs to be investigated and fixed manually. In
a previous revision of the SMIv2 module did not have an ambiguity, case a previous revision of the SMIv2 module did not have an
then the name used by the previous revision MUST be used. The leaf ambiguity, then the name used by the previous revision MUST be used.
statements representing columnar objects are created in the list The leaf statements representing columnar objects are created in the
representing a conceptual row, see Section 7.3. list 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,
SMIv2 length restrictions are mapped to YANG length statements. while SMIv2 length restrictions are mapped to YANG length
SMIv2 INTEGER enumerations are mapped to YANG enum/value statements. SMIv2 INTEGER enumerations are mapped to YANG enum/
statements. SMIv2 BITS are mapped to YANG bit/position value statements. SMIv2 BITS are mapped to YANG bit/position
statements. For OCTET STRING types that are mapped to a YANG statements. For OCTET STRING types that are mapped to a YANG
string base type (see Section 2), the length specified in the YANG string base type (see Section 2), the length specified in the YANG
length statement must be consistent with the stringified length statement must be consistent with the stringified
representation of values. If an implementation is unable to representation of values. If an implementation is unable to
derive a proper length restrictions, then the YANG length derive proper length restrictions, then the YANG length statement
statement MUST be omitted. MUST be omitted.
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 is translated into an smiv2:max-access o The SMIv2 MAX-ACCESS is translated into an smiv2:max-access
statement. Refer to the YANG extension defined in Section 10. 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.
skipping to change at page 17, line 32 skipping to change at page 14, line 45
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. If the the columnar objects forming the key of the YANG list. If the
same object appears more than once in the INDEX clause, append same object appears more than once in the INDEX clause, append
'_<n>' to the duplicate object name(s) where '<n>' counts the '_<n>' to the duplicate object name(s) where '<n>' counts the
occurances of the object in the INDEX clause, starting from 2. occurrences of the object in the INDEX clause, starting from 2.
Additional leaf statements must be created to define the leafs Additional leaf statements must be created to define the leafs
introduced. introduced.
o If the SMIv2 INDEX clause contains the IMPLIED keyword, then an o If the SMIv2 INDEX clause contains the IMPLIED keyword, then an
smiv2:implied statement is generated to record the name of the smiv2:implied statement is generated to record the name of the
object preceded by the IMPLIED keyword. Refer to the YANG object preceded by the IMPLIED keyword. Refer to the YANG
extension defined in Section 10. extension defined in Section 10.
o The value of the SMIv2 OBJECT-TYPE macro invocation is translated o The value of the SMIv2 OBJECT-TYPE macro invocation is translated
into an smiv2:oid statement. Refer to the YANG extension defined into an smiv2:oid statement. Refer to the YANG extension defined
skipping to change at page 18, line 42 skipping to change at page 16, line 7
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";
} }
// ... // ...
} }
} }
7.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
MIB [RFC2863] is shown below. IF-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:
- for an interface operating in promiscuous mode, entries - for an interface operating in promiscuous mode, entries are
are only required for those addresses for which the system only required for those addresses for which the system would
would receive frames were it not operating in promiscuous receive frames were it not operating in promiscuous mode.
mode.
- for 802.5 functional addresses, only one entry is - for 802.5 functional addresses, only one entry is required,
required, for the address which has the functional address for the address which has the functional address bit ANDed
bit ANDed with the bit mask of all functional addresses for with the bit mask of all functional addresses for which the
which the interface will accept frames. interface will accept frames.
A system is normally able to use any unicast address which A system is normally able to use any unicast address which
corresponds to an entry in this table as a source address."; corresponds to an entry in this table as a source address.";
smiv2:oid "1.3.6.1.2.1.31.1.4"; smiv2:oid "1.3.6.1.2.1.31.1.4";
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
skipping to change at page 24, line 37 skipping to change at page 21, line 39
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 is o The value of the SMIv2 OBJECT-IDENTITY macro invocation is
translated into an smiv2:oid statement. Refer to the YANG translated into an smiv2:oid statement. Refer to the YANG
extension defined in Section 10. extension defined in Section 10.
8.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. (Please note that the
description should refer to RFC 3290, Section 5.1.3.)
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";
} }
9. Translation of the NOTIFICATION-TYPE Macro 9. Translation of the NOTIFICATION-TYPE Macro
The SMIv2 provides the NOTIFICATION-TYPE macro to define event 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.
9.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.
skipping to change at page 25, line 29 skipping to change at page 22, line 29
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 7.1. leaf is generated, following the 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.
skipping to change at page 27, line 4 skipping to change at page 24, line 9
"/if-mib:ifEntry/if-mib:ifIndex"; "/if-mib:ifEntry/if-mib:ifIndex";
} }
} }
leaf ifOperStatus { leaf ifOperStatus {
type leafref { type leafref {
path "/if-mib:IF-MIB/if-mib:ifTable" + path "/if-mib:IF-MIB/if-mib:ifTable" +
"/if-mib:ifEntry/if-mib:ifOperStatus"; "/if-mib:ifEntry/if-mib:ifOperStatus";
} }
} }
} }
} }
10. 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].
RFC Ed.: update the date below with the revision date of the YANG <CODE BEGINS> file "ietf-yang-smiv2@2012-06-22.yang"
module and remove this note.
<CODE BEGINS> file "ietf-yang-smiv2@2012-04-20.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
"WG Web: <http://tools.ietf.org/wg/netmod/> "WG Web: <http://tools.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org> WG List: <mailto:netmod@ietf.org>
WG Chair: David Kessens WG Chair: David Kessens
<mailto:david.kessens@nsn.com> <mailto:david.kessens@nsn.com>
WG Chair: Juergen Schoenwaelder WG Chair: Juergen Schoenwaelder
<mailto:j.schoenwaelder@jacobs-university.de> <mailto:j.schoenwaelder@jacobs-university.de>
Editor: Juergen Schoenwaelder Editor: Juergen Schoenwaelder
<mailto:j.schoenwaelder@jacobs-university.de>"; <mailto:j.schoenwaelder@jacobs-university.de>";
description description
"This module defines YANG extensions that are used to translate "This module defines YANG extensions that are used to translate
SMIv2 concepts into YANG. SMIv2 concepts into YANG.
Copyright (c) 2012 IETF Trust and the persons identified as Copyright (c) 2012 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
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 6643; 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.: please update the date to the date of publication revision 2012-06-22 {
revision 2012-04-20 { description
description "Initial revision.";
"Initial revision."; reference
reference "RFC 6643: Translation of Structure of Management Information
"RFC XXXX: Translation of SMIv2 MIB Modules to YANG Modules"; Version 2 (SMIv2) MIB Modules to YANG Modules";
// 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.";
} }
typedef opaque { typedef opaque {
type binary; type binary;
description description
"The Opaque type supports the capability to pass arbitrary ASN.1 "The Opaque type supports the capability to pass arbitrary ASN.1
syntax. A value is encoded using the ASN.1 Basic Encoding Rules 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 into a string of octets. This, in turn, is encoded as an OCTET
STRING, in effect 'double-wrapping' the original ASN.1 value. STRING, in effect 'double-wrapping' the original ASN.1 value.
In the value set and its semantics, this type is equivalent to In the value set and its semantics, this type is equivalent to
the Opaque type of the SMIv2. This type exists in the SMIv2 the Opaque type of the SMIv2. This type exists in the SMIv2
solely for backward-compatibility reasons and this is also solely for backward-compatibility reasons and this is also
true for this YANG data type."; true for this YANG data type.";
reference reference
"RFC 2578: 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"; "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.
extension max-access { The MAX-ACCESS value is SMIv2 specific and has no impact on
argument "access"; the access provided to YANG objects through protocols such
description as NETCONF.";
"The max-access statement takes as an argument the MAX-ACCESS reference
assigned to an SMIv2 object definition. "RFC 2578: Structure of Management Information Version 2 (SMIv2)";
}
The MAX-ACCESS value is SMIv2 specific and has no impact on extension defval {
the access provided to YANG objects through protocols such argument "value";
as NETCONF."; description
reference "The defval statement takes as an argument a default value
"RFC2578: Structure of Management Information Version 2 (SMIv2)"; 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 defval { extension implied {
argument "value"; argument "index";
description description
"The defval statement takes as an argument a default value "If an SMIv2 INDEX object is preceded by the IMPLIED keyword, then
defined by an SMIv2 DEFVAL clause. Note that the value is in the implied statement is present in the YANG module and takes as
the SMIv2 value space defined by the SMIv2 syntax of the an argument the name of the IMPLIED index object.";
corresponding object and not in the YANG value space reference
defined by the corresponding YANG data type."; "RFC 2578: Structure of Management Information Version 2 (SMIv2)";
reference }
"RFC2578: Structure of Management Information Version 2 (SMIv2)";
}
extension implied { extension alias {
argument "index"; argument "descriptor";
description description
"If an SMIv2 INDEX object is preceded by the IMPLIED keyword, then "The alias statement introduces an SMIv2 descriptor. The body of
the implied statement is present in the yang module and takes as the alias statement is expected to contain an oid statement that
an argument the name of the IMPLIED index object."; provides the numeric OID associated with the descriptor.";
reference reference
"RFC2578: Structure of Management Information Version 2 (SMIv2)"; "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 alias { extension subid {
argument "descriptor"; argument "value";
description description
"The alias statement introduces an SMIv2 descriptor. The body of "The subid statement takes as an argument the last sub-identifier
the alias statement is expected to contain an oid statement that of the object identifier assigned to an SMIv2 definition. The
provides the numeric OID associated with the descriptor."; sub-identifier value is a single positive decimal natural number.
reference The subid statement may not be used as a substatement to any
"RFC2578: Structure of Management Information Version 2 (SMIv2)"; 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.";
extension oid { reference
argument "value"; "RFC 2578: Structure of Management Information Version 2 (SMIv2)";
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>
11. Implementing Configuration Data Nodes 11. Implementing Configuration Data Nodes
The result of the translation of SMIv2 MIB modules into YANG modules, The result of the translation of SMIv2 MIB modules into YANG modules,
even if SMIv2 objects are read-write or read-create, consists of even if SMIv2 objects are read-write or read-create, consists of
read-only (config false) YANG objects. One reason is that the read-only (config false) YANG objects. One reason is that the
persistency models of the underlying protocols, SNMP and NETCONF, are persistency models of the underlying protocols, SNMP and NETCONF, are
quite different. With SNMP, the persistency of a writable object quite different. With SNMP, the persistency of a writable object
skipping to change at page 35, line 26 skipping to change at page 30, line 38
URI: urn:ietf:params:xml:ns:yang:smiv2 URI: urn:ietf:params:xml:ns: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.
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 6643
13. Security Considerations 13. 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 (config false) access to data objects modules, enabling read-only (config false) access to data objects
defined in SMIv2 MIB modules via NETCONF. The translation itself has defined in SMIv2 MIB modules via NETCONF. The translation itself has
no security impact on the Internet. no security impact on the Internet.
Users of YANG data models generated from SMIv2 data models that have Users of YANG data models generated from SMIv2 data models that have
been published in the RFC series are advised to consult the security been published in the RFC series are advised to consult the security
considerations of the respective RFCs. The security considerations considerations of the respective RFCs. The security considerations
of RFCs containing SMIv2 data models explain which objects are of RFCs containing SMIv2 data models explain which objects are
sensitive and important to protect. NETCONF users are encouraged to sensitive and important to protect. NETCONF users are encouraged to
make use of the NETCONF access control model [RFC6536], which allows make use of the NETCONF access control model [RFC6536], which allows
to specify access control rules to protect potentially sensitive the specification of access control rules to protect potentially
information. sensitive information.
14. Acknowledgements 14. Acknowledgements
The editor wishes to thank the following individuals for providing The author wishes to thank the following individuals for providing
helpful comments on various versions of this document: Andy Bierman, helpful comments on various draft versions of this document: Andy
Benoit Claise, Martin Bjorklund, Leif Johansson, David Reid, Dan Bierman, Benoit Claise, Martin Bjorklund, Leif Johansson, David Reid,
Romascanu, and David Spakes. Dan Romascanu, and David Spakes.
15. References 15. References
15.1. Normative References 15.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
skipping to change at page 40, line 5 skipping to change at page 33, line 5
Information Base Version 2", RFC 4502, May 2006. 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.
[RFC6536] Bierman, A., Ed. and M. Bjorklund, Ed., "Network [RFC6536] Bierman, A., Ed. and M. Bjorklund, Ed., "Network
Configuration Protocol (NETCONF) Access Control Model", Configuration Protocol (NETCONF) Access Control Model",
RFC 6536, March 2012. RFC 6536, March 2012.
Appendix A. Mapping of Well Known Types (normative) Appendix A. Mapping of Well-Known Types (Normative)
This normative appendix describes the mapping of SMIv2 types to YANG This normative appendix describes the mapping of SMIv2 types to YANG
types. The mapping is fully consistent with Table 1 and Table 2 of types. The mapping is fully consistent with Tables 1 and 2 of
[RFC6021]. [RFC6021].
SMIv2 Module: SNMPv2-SMI SMIv2 Module: SNMPv2-SMI
SMIv2 Type: INTEGER (used as an enumeration) SMIv2 Type: INTEGER (used as an enumeration)
YANG Type: 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 Module: SNMPv2-SMI
SMIv2 Type: OCTET STRING (used as a binary string) SMIv2 Type: INTEGER (used as a numeric type)
YANG Type: binary YANG Type: int32
SMIv2 Module: SNMPv2-SMI SMIv2 Module: SNMPv2-SMI
SMIv2 Type: OCTET STRING (used to hold UTF8/ASCII characters) SMIv2 Type: Integer32
YANG Type: string YANG Type: int32
SMIv2 Module: SNMPv2-SMI SMIv2 Module: SNMPv2-SMI
SMIv2 Type: OBJECT IDENTIFIER SMIv2 Type: OCTET STRING (used as a binary string)
YANG Module: ietf-yang-types YANG Type: binary
YANG Type: object-identifier-128
SMIv2 Module: SNMPv2-SMI SMIv2 Module: SNMPv2-SMI
SMIv2 Type: BITS SMIv2 Type: OCTET STRING (used to hold UTF-8 or ASCII characters)
YANG Type: bits YANG Type: string
SMIv2 Module: SNMPv2-SMI SMIv2 Module: SNMPv2-SMI
SMIv2 Type: IpAddress SMIv2 Type: OBJECT IDENTIFIER
YANG Module: ietf-inet-types YANG Module: ietf-yang-types
YANG Type: ipv4-address YANG Type: object-identifier-128
SMIv2 Module: SNMPv2-SMI SMIv2 Module: SNMPv2-SMI
SMIv2 Type: Counter32 SMIv2 Type: BITS
YANG Module: ietf-yang-types YANG Type: bits
YANG Type: counter32
SMIv2 Module: SNMPv2-SMI SMIv2 Module: SNMPv2-SMI
SMIv2 Type: Gauge32 SMIv2 Type: IpAddress
YANG Module: ietf-yang-types YANG Module: ietf-inet-types
YANG Type: gauge32 YANG Type: ipv4-address
SMIv2 Module: SNMPv2-SMI SMIv2 Module: SNMPv2-SMI
SMIv2 Type: TimeTicks SMIv2 Type: Counter32
YANG Module: ietf-yang-types YANG Module: ietf-yang-types
YANG Type: timeticks YANG Type: counter32
SMIv2 Module: SNMPv2-SMI
SMIv2 Type: Gauge32
YANG Module: ietf-yang-types
YANG Type: gauge32
SMIv2 Module: SNMPv2-SMI SMIv2 Module: SNMPv2-SMI
SMIv2 Type: Counter64 SMIv2 Type: TimeTicks
YANG Module: ietf-yang-types YANG Module: ietf-yang-types
YANG Type: counter64 YANG Type: timeticks
SMIv2 Module: SNMPv2-SMI SMIv2 Module: SNMPv2-SMI
SMIv2 Type: Unsigned32 SMIv2 Type: Counter64
YANG Type: uint32 YANG Module: ietf-yang-types
YANG Type: counter64
SMIv2 Module: SNMPv2-SMI SMIv2 Module: SNMPv2-SMI
SMIv2 Type: Opaque SMIv2 Type: Unsigned32
YANG Module: ietf-yang-smiv2 YANG Type: uint32
YANG Type: opaque
SMIv2 Module: SNMPv2-TC SMIv2 Module: SNMPv2-SMI
SMIv2 Type: PhysAddress SMIv2 Type: Opaque
YANG Module: ietf-yang-types YANG Module: ietf-yang-smiv2
YANG Type: phys-address YANG Type: opaque
SMIv2 Module: SNMPv2-TC SMIv2 Module: SNMPv2-TC
SMIv2 Type: MacAddress SMIv2 Type: PhysAddress
YANG Module: ietf-yang-types YANG Module: ietf-yang-types
YANG Type: mac-address YANG Type: phys-address
SMIv2 Module: SNMPv2-TC SMIv2 Module: SNMPv2-TC
SMIv2 Type: TruthValue SMIv2 Type: MacAddress
YANG Type: boolean YANG Module: ietf-yang-types
YANG Type: mac-address
SMIv2 Module: SNMPv2-TC SMIv2 Module: SNMPv2-TC
SMIv2 Type: TimeStamp SMIv2 Type: TruthValue
YANG Module: ietf-yang-types YANG Type: boolean
YANG Type: timestamp
SMIv2 Module: RMON2-MIB SMIv2 Module: SNMPv2-TC
SMIv2 Type: ZeroBasedCounter32 SMIv2 Type: TimeStamp
YANG Module: ietf-yang-types YANG Module: ietf-yang-types
YANG Type: zero-based-counter32 YANG Type: timestamp
SMIv2 Module: HCNUM-TC SMIv2 Module: RMON2-MIB
SMIv2 Type: ZeroBasedCounter64 SMIv2 Type: ZeroBasedCounter32
YANG Module: ietf-yang-types YANG Module: ietf-yang-types
YANG Type: zero-based-counter64 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 Module: HCNUM-TC
SMIv2 Type: CounterBasedGauge64 SMIv2 Type: CounterBasedGauge64
YANG Module: ietf-yang-types YANG Module: ietf-yang-types
YANG Type: gauge64 YANG Type: gauge64
SMIv2 Module: INET-ADDRESS-MIB SMIv2 Module: INET-ADDRESS-MIB
SMIv2 Type: InetAutonomousSystemNumber SMIv2 Type: InetAutonomousSystemNumber
YANG Module: ietf-inet-types YANG Module: ietf-inet-types
YANG Type: as-number YANG Type: as-number
SMIv2 Module: INET-ADDRESS-MIB SMIv2 Module: INET-ADDRESS-MIB
SMIv2 Type: InetVersion SMIv2 Type: InetVersion
YANG Module: ietf-inet-types YANG Module: ietf-inet-types
YANG Type: ip-version YANG Type: ip-version
SMIv2 Module: INET-ADDRESS-MIB SMIv2 Module: INET-ADDRESS-MIB
SMIv2 Type: InetPortNumber SMIv2 Type: InetPortNumber
YANG Module: ietf-inet-types YANG Module: ietf-inet-types
YANG Type: port-number YANG Type: port-number
SMIv2 Module: DIFFSERV-DSCP-TC SMIv2 Module: DIFFSERV-DSCP-TC
SMIv2 Type: Dscp SMIv2 Type: Dscp
YANG Module: ietf-inet-types YANG Module: ietf-inet-types
YANG Type: dscp YANG Type: dscp
SMIv2 Module: IPV6-FLOW-LABEL-MIB SMIv2 Module: IPV6-FLOW-LABEL-MIB
SMIv2 Type: IPv6FlowLabel SMIv2 Type: IPv6FlowLabel
YANG Module: ietf-inet-types YANG Module: ietf-inet-types
YANG Type: ipv6-flow-label YANG Type: ipv6-flow-label
SMIv2 Module: URI-TC-MIB SMIv2 Module: URI-TC-MIB
SMIv2 Type: Uri SMIv2 Type: Uri
YANG Module: ietf-inet-types YANG Module: ietf-inet-types
YANG Type: uri YANG Type: uri
Appendix B. Module Prefix Generation (informative) Appendix B. Module Prefix Generation (Informative)
This section describes an algorithm to generate module prefixes, to This section describes an algorithm to generate module prefixes to be
be used in the import statements. The input of the prefix generation used in the import statements. The input of the prefix generation
algorithm is a set of prefixes (usually derived from imported module algorithm is a set of prefixes (usually derived from imported module
names) and a specific module name to be converted into a prefix. The names) and a specific module name to be converted into a prefix. The
algorithm described below produces a prefix for the given module name algorithm described below produces a prefix for the given module name
that is unique within the set of prefixes. that is unique within the set of prefixes.
+-----------------+--------+ +-----------------+--------+
| YANG Module | Prefix | | YANG Module | Prefix |
+-----------------+--------+ +-----------------+--------+
| ietf-yang-types | yang | | ietf-yang-types | yang |
| ietf-inet-types | inet | | ietf-inet-types | inet |
| ietf-yang-smiv2 | smiv2 | | ietf-yang-smiv2 | smiv2 |
+-----------------+--------+ +-----------------+--------+
Table 1: Special prefixes for well known YANG modules Table 1: Special Prefixes For Well-Known YANG Modules
o First, some predefined translations mapping well known YANG o First, some predefined translations mapping well-known YANG
modules to short prefixes are tried (see Table 1). If a fixed modules to short prefixes are tried (see Table 1). If a fixed
translation rule exists and leads to a conflict free prefix, then translation rule exists and leads to a conflict-free prefix, then
the fixed translation is used. the fixed translation is used.
o Otherwise, prefixes are generated by tokenizing a YANG module o Otherwise, prefixes are generated by tokenizing a YANG module
name, using hyphens as token separators. The tokens derived from name, using hyphens as token separators. The tokens derived from
the module name are converted to lowercase characters. The prefix the module name are converted to lowercase characters. The prefix
then becomes the shortest sequence of tokens concatenated using then becomes the shortest sequence of tokens concatenated using
hyphens as separators, which includes at least two tokens and hyphens as separators, which includes at least two tokens and
which is unique among all prefixes used in the YANG module. which is unique among all prefixes used in the YANG module.
In the worst case, the prefix derived from an SMIv2 module name In the worst case, the prefix derived from an SMIv2 module name
becomes the SMIv2 module name translated to lower-case. But on becomes the SMIv2 module name translated to lowercase. But on
average, much shorter prefixes are generated. 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. 102 change blocks. 
396 lines changed or deleted 385 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/