draft-ietf-netmod-smi-yang-02.txt   draft-ietf-netmod-smi-yang-03.txt 
Network Working Group J. Schoenwaelder Network Working Group J. Schoenwaelder
Internet-Draft Jacobs University Internet-Draft Jacobs University
Intended status: Standards Track November 25, 2011 Intended status: Standards Track December 8, 2011
Expires: May 28, 2012 Expires: June 10, 2012
Translation of SMIv2 MIB Modules to YANG Modules Translation of SMIv2 MIB Modules to YANG Modules
draft-ietf-netmod-smi-yang-02 draft-ietf-netmod-smi-yang-03
Abstract Abstract
YANG is a data modeling language used to model configuration and YANG is a data modeling language used to model configuration and
state data manipulated by the NETCONF protocol, NETCONF remote state data manipulated by the NETCONF protocol, NETCONF remote
procedure calls, and NETCONF notifications. The Structure of procedure calls, and NETCONF notifications. The Structure of
Management Information (SMIv2) defines fundamental data types, an Management Information (SMIv2) defines fundamental data types, an
object model, and the rules for writing and revising MIB modules for object model, and the rules for writing and revising MIB modules for
use with the SNMP protocol. This document defines a translation of use with the SNMP protocol. This document defines a translation of
SMIv2 MIB modules into YANG modules, enabling read-only access to SMIv2 MIB modules into YANG modules, enabling read-only access to
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 28, 2012. This Internet-Draft will expire on June 10, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 10 skipping to change at page 4, line 10
14.2. Informative References . . . . . . . . . . . . . . . . . . 35 14.2. Informative References . . . . . . . . . . . . . . . . . . 35
Appendix A. Mapping of Well Known Types (normative) . . . . . . . 37 Appendix A. Mapping of Well Known Types (normative) . . . . . . . 37
Appendix B. Module Prefix Generation (informative) . . . . . . . 40 Appendix B. Module Prefix Generation (informative) . . . . . . . 40
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 41 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 41
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
access to data objects defined in SMIv2 MIB modules via NETCONF. The access to data objects defined in SMIv2 MIB modules via NETCONF. The
mapping is illustrated by examples showing the translation of part of mapping is illustrated by examples showing the translation of parts
the IF-MIB [RFC2863] SMIv2 module and the DIFFSERV-MIB [RFC3289] of the IF-MIB [RFC2863], the DIFFSERV-MIB [RFC3289], and the RMON2-
SMIv2 module. MIB [RFC4502] SMIv2 module.
SMIv1 modules may be converted to YANG by first following the rules SMIv1 modules may be converted to YANG by first following the rules
in [RFC3584] to convert the SMIv1 module to SMIv2, then following the in [RFC3584] to convert the SMIv1 module to SMIv2, then following the
rules in this document to convert to YANG. rules in this document to convert to YANG.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14, [RFC2119]. 14, [RFC2119].
2. Mapping of 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. Otherwise, the binary type is used. Similarly, the
mapping of the INTEGER type depends on its usage as an enumeration or mapping of the INTEGER type depends on its usage as an enumeration or
a 32-bit integral type. Implementations are encouraged to provide a 32-bit integral type. Implementations are encouraged to provide
options to handle situations where DISPLAY-HINTs are added during a options to handle situations where DISPLAY-HINTs are added during a
revision of a module and backwards compatibility must be preserved. revision of a module and backwards compatibility must be preserved.
The mappings shown in Appendix A may impact the imports of the The mappings shown in Appendix A may impact the imports of the
generated YANG module since some SMIv2 types and textual-conventions generated YANG module since some SMIv2 types and textual conventions
map to YANG types defined in the ietf-yang-types and ietf-inet-types map to YANG types defined in the ietf-yang-types and ietf-inet-types
YANG modules [RFC6021]. Implementations MUST add any additional YANG modules defined in [RFC6021] and the ietf-yang-smiv2 YANG module
defined in this document. Implementations MUST add any additional
imports required by the type mapping. imports required by the type 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 YANG SMIv2 modules are mapped to corresponding YANG modules. The YANG
module name MUST be the same as the SMIv2 module name. module name MUST be the same as the SMIv2 module name.
The YANG namespace MUST be constructed out of a constant prefix The YANG namespace MUST be constructed out of a constant prefix
followed by the SMIv2 module name. Since SMIv2 module names can be followed by the SMIv2 module name. Since SMIv2 module names can be
assumed to be unique (see Section 3 in [RFC2578]), the resulting YANG assumed to be unique (see Section 3 in [RFC2578]), the resulting YANG
skipping to change at page 7, line 19 skipping to change at page 7, line 19
7. Otherwise, ignore this item. Some examples of this case are 7. Otherwise, ignore this item. Some examples of this case are
OBJECT IDENTIFIER assignments and objects that are only OBJECT IDENTIFIER assignments and objects that are only
referenced in MODULE-COMPLIANCE, OBJECT-GROUP, or referenced in MODULE-COMPLIANCE, OBJECT-GROUP, or
NOTIFICATION-GROUP clauses. NOTIFICATION-GROUP clauses.
o Generate any additional import statements as required by the type o Generate any additional import statements as required by the type
translations according to the type mapping table Appendix A. This translations according to the type mapping table Appendix A. This
requires the translator to consider all the types used in the requires the translator to consider all the types used in the
SMIv2 module in order to produce the imports. SMIv2 module in order to produce the imports.
o Generate an import statement for the yang module ietf-yang-smiv2 o Generate an import statement for the YANG module ietf-yang-smiv2
with the prefix smiv2 if extensions from ietf-yang-smiv2 will be with the prefix smiv2.
used in the translated yang module.
The generated import statements use the untranslated SMIv2 module The generated import statements use the untranslated SMIv2 module
names or the names of well-known YANG modules as their argument. The names or the names of well-known YANG modules as their argument. The
import statement must contain a prefix statement. The prefixes MAY import statement must contain a prefix statement. The prefixes MAY
be generated by applying the module prefix generation algorithm be generated by applying the module prefix generation algorithm
described in Appendix B. described in Appendix B.
3.1. Example: IMPORTS of IF-MIB 3.1. Example: IMPORTS of IF-MIB
The translation of the IF-MIB [RFC2863] leads to the YANG module and The translation of the IF-MIB [RFC2863] leads to the YANG module and
skipping to change at page 7, line 43 skipping to change at page 7, line 42
The prefix is the translation of the SMIv2 module name IF-MIB to The prefix is the translation of the SMIv2 module name IF-MIB to
lowercase (consisting of two tokens and thus no further lowercase (consisting of two tokens and thus no further
abbreviation). abbreviation).
module IF-MIB { module IF-MIB {
namespace "urn:ietf:params:xml:ns:yang:smiv2:IF-MIB"; namespace "urn:ietf:params:xml:ns:yang:smiv2:IF-MIB";
prefix "if-mib"; prefix "if-mib";
import IANAifType-MIB { prefix "ianaiftype-mib"; } import IANAifType-MIB { prefix "ianaiftype-mib"; }
import SNMPv2-TC { prefix "smiv2-tc"; } import SNMPv2-TC { prefix "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 The SMIv2 requires an invocation of the MODULE-IDENTITY macro to
provide contact and revision history for a MIB module. The clauses provide contact and revision history for a MIB module. The clauses
of the SMIv2 MODULE-IDENTITY macro MUST be translated into YANG of the SMIv2 MODULE-IDENTITY macro MUST be translated into YANG
statements as detailed below. statements as detailed below.
skipping to change at page 8, line 33 skipping to change at page 8, line 33
o Each SMIv2 REVISION clause is mapped to a YANG revision statement. o Each SMIv2 REVISION clause is mapped to a YANG revision statement.
The revision is identified by the date argument of the SMIv2 The revision is identified by the date argument of the SMIv2
REVISION clause. DESCRIPTION sub-clauses of REVISION clauses are REVISION clause. DESCRIPTION sub-clauses of REVISION clauses are
mapped to corresponding description statement nested in revision mapped to corresponding description statement nested in revision
clauses. clauses.
o The SMIv2 LAST-UPDATED clause is ignored if the associated date o The SMIv2 LAST-UPDATED clause is ignored if the associated date
matches a REVISION clause. Otherwise, an additional revision matches a REVISION clause. Otherwise, an additional revision
statement is generated. statement is generated.
o The name of the SMIv2 module is used to generate a top-level o A top-level YANG container is generated. The container's name is
container statement. This container MUST be config false. 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 only defining textual
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 IDENTITY is translated into an smiv2:oid statement contained in an
the container representing the MODULE-IDENTITY macro invocation. smiv2:alias statement representing the MODULE-IDENTITY macro
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, and
revision statements. revision statements.
skipping to change at page 11, line 7 skipping to change at page 11, line 7
statements. SMIv2 BITS are mapped to YANG bit/position statements. SMIv2 BITS are mapped to YANG bit/position
statements. statements.
This translation assumes that labels of named numbers and named bits This translation assumes that labels of named numbers and named bits
do not change when an SMIv2 module is revised. This is consistent do not change when an SMIv2 module is revised. This is consistent
with the clarification of the SMIv2 module revision rules in Section with the clarification of the SMIv2 module revision rules in Section
4.9 of [RFC4181]. 4.9 of [RFC4181].
5.2. Example: OwnerString and InterfaceIndex of IF-MIB 5.2. Example: OwnerString and InterfaceIndex of IF-MIB
The translation of the OwnerString and InterfaceIndex textual- The translation of the OwnerString and InterfaceIndex textual
conventions of the IF-MIB [RFC2863] are shown below. conventions of the IF-MIB [RFC2863] are shown below.
typedef OwnerString { typedef OwnerString {
type string { type string {
length "0..255"; length "0..255";
pattern '\p{IsBasicLatin}{0,255}'; pattern '\p{IsBasicLatin}{0,255}';
} }
status deprecated; status deprecated;
description description
"This data type is used to model an administratively "This data type is used to model an administratively
skipping to change at page 11, line 46 skipping to change at page 11, line 46
interface sub-layer in the managed system. It is interface sub-layer in the managed system. It is
recommended that values are assigned contiguously starting recommended that values are assigned contiguously starting
from 1. The value for each interface sub-layer must remain from 1. The value for each interface sub-layer must remain
constant at least from one re-initialization of the entity's constant at least from one re-initialization of the entity's
network management system to the next re-initialization."; network management system to the next re-initialization.";
smiv2:display-hint "d"; smiv2:display-hint "d";
} }
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 description
"IfDirection specifies a direction of data travel on an "IfDirection specifies a direction of data travel on an
interface. 'inbound' traffic is operated on during reception from interface. 'inbound' traffic is operated on during reception from
skipping to change at page 14, line 34 skipping to change at page 14, line 34
accessible-for-notify are translated to YANG leaf statements if that accessible-for-notify are translated to YANG leaf statements if that
columnar object is part of the INDEX clause of the table containing columnar object is part of the INDEX clause of the table containing
that columnar object. The name of the leaf is the name associated that columnar object. The name of the leaf is the name associated
with the SMIv2 OBJECT-TYPE macro invocation. SMIv2 OBJECT-TYPE macro with the SMIv2 OBJECT-TYPE macro invocation. SMIv2 OBJECT-TYPE macro
invocations with a MAX-ACCESS of "accessible-for-notify" are not invocations with a MAX-ACCESS of "accessible-for-notify" are not
translated to YANG data tree leafs but instead into YANG notification translated to YANG data tree leafs but instead into YANG notification
leafs. leafs.
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 is named after the scalar's parent node in the OID tree container is named after the scalar's parent node in the OID tree and
and placed in the top-level container representing the SMIv2 module, placed in the top-level container representing the SMIv2 module, see
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 and
the name clash needs to be investigated and fixed manually. The leaf the name clash needs to be investigated and fixed manually. In case
a previous revision of the SMIv2 module did not have an ambiguity,
then the name used by the previous revision MUST be used. The leaf
statements representing columnar objects are created in the list statements representing columnar objects are created in the list
representing a conceptual row, see Section 7.3. representing a conceptual row, see Section 7.3.
o The SMIv2 SYNTAX clause is mapped to the YANG type statement. o The SMIv2 SYNTAX clause is mapped to the YANG type statement.
SMIv2 range restrictions are mapped to YANG range statements while SMIv2 range restrictions are mapped to YANG range statements while
SMIv2 length restrictions are mapped to YANG length statements. SMIv2 length restrictions are mapped to YANG length statements.
SMIv2 INTEGER enumerations are mapped to YANG enum/value SMIv2 INTEGER enumerations are mapped to YANG enum/value
statements. SMIv2 BITS are mapped to YANG bit/position statements. SMIv2 BITS are mapped to YANG bit/position
statements. statements.
skipping to change at page 20, line 33 skipping to change at page 20, line 33
seen as the source or destination address in all packets with seen as the source or destination address in all packets with
no MAC errors and will increment octet and packet counts in no MAC errors and will increment octet and packet counts in
the table for all packets with no MAC errors. Further, the table for all packets with no MAC errors. Further,
entries will only be added to this table if their address entries will only be added to this table if their address
exists in the nlHostTable and will be deleted from this table exists in the nlHostTable and will be deleted from this table
if their address is deleted from the nlHostTable."; if their address is deleted from the nlHostTable.";
smiv2:oid "1.3.6.1.2.1.16.16.1"; smiv2:oid "1.3.6.1.2.1.16.16.1";
list alHostEntry { list alHostEntry {
key "hlHostControlIndex alHostTimeMark protocolDirLocalIndex " key "hlHostControlIndex alHostTimeMark protocolDirLocalIndex "
"nlHostAddress protocolDirLocalIndex_2"; + "nlHostAddress protocolDirLocalIndex_2";
description description
"A conceptual row in the alHostTable. "A conceptual row in the alHostTable.
The hlHostControlIndex value in the index identifies the The hlHostControlIndex value in the index identifies the
hlHostControlEntry on whose behalf this entry was created. hlHostControlEntry on whose behalf this entry was created.
The first protocolDirLocalIndex value in the index identifies The first protocolDirLocalIndex value in the index identifies
the network-layer protocol of the address. the network-layer protocol of the address.
The nlHostAddress value in the index identifies the network- The nlHostAddress value in the index identifies the network-
layer address of this entry. layer address of this entry.
The second protocolDirLocalIndex value in the index identifies The second protocolDirLocalIndex value in the index identifies
skipping to change at page 21, line 12 skipping to change at page 21, line 12
the maximum for the SNMP protocol. Implementations should take the maximum for the SNMP protocol. Implementations should take
care to avoid such combinations."; care to avoid such combinations.";
smiv2:oid "1.3.6.1.2.1.16.16.1.1"; smiv2:oid "1.3.6.1.2.1.16.16.1.1";
// ... // ...
leaf protocolDirLocalIndex { leaf protocolDirLocalIndex {
type leafref { type leafref {
path "/rmon2-mib:RMON2-MIB/" path "/rmon2-mib:RMON2-MIB/"
"rmon2-mib:protocolDirTable/" + "rmon2-mib:protocolDirTable/"
"rmon2-mib:"protocolDirEntryf/" + "rmon2-mib:protocolDirEntryf/"
"rmon2-mib:protocolDirLocalIndex"; + "rmon2-mib:protocolDirLocalIndex";
} }
} }
// ... // ...
leaf protocolDirLocalIndex_2 { leaf protocolDirLocalIndex_2 {
type leafref { type leafref {
path "/rmon2-mib:RMON2-MIB/" path "/rmon2-mib:RMON2-MIB/"
"rmon2-mib:protocolDirTable/" + "rmon2-mib:protocolDirTable/"
"rmon2-mib:protocolDirEntry/" + "rmon2-mib:protocolDirEntry/"
"rmon2-mib:protocolDirLocalIndex"; + "rmon2-mib:protocolDirLocalIndex";
} }
} }
// ... // ...
} }
} }
7.7. Augmenting Conceptual Tables Translation Rules 7.7. Augmenting Conceptual Tables Translation Rules
An OBJECT-TYPE macro invocation defining an augmenting conceptual An OBJECT-TYPE macro invocation defining an augmenting conceptual
skipping to change at page 37, line 9 skipping to change at page 37, line 9
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.
Appendix A. Mapping of Well Known Types (normative) Appendix A. Mapping of Well Known Types (normative)
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 Module: SNMPv2-SMI
SMIv2 Type: INTEGER (used as a numeric type) SMIv2 Type: INTEGER (used as a numeric type)
Yang Type: int32 YANG Type: int32
SMIv2 Module: SNMPv2-SMI SMIv2 Module: SNMPv2-SMI
SMIv2 Type: Integer32 SMIv2 Type: Integer32
Yang Type: int32 YANG Type: int32
SMIv2 Module: SNMPv2-SMI SMIv2 Module: SNMPv2-SMI
SMIv2 Type: OCTET STRING (used as a binary string) SMIv2 Type: OCTET STRING (used as a binary string)
Yang Type: binary YANG Type: binary
SMIv2 Module: SNMPv2-SMI SMIv2 Module: SNMPv2-SMI
SMIv2 Type: OCTET STRING (used to hold UTF8/ASCII characters) SMIv2 Type: OCTET STRING (used to hold UTF8/ASCII characters)
Yang Type: string YANG Type: string
SMIv2 Module: SNMPv2-SMI SMIv2 Module: SNMPv2-SMI
SMIv2 Type: OBJECT IDENTIFIER SMIv2 Type: OBJECT IDENTIFIER
YANG Module: ietf-yang-types YANG Module: ietf-yang-types
Yang Type: object-identifier-128 YANG Type: object-identifier-128
SMIv2 Module: SNMPv2-SMI SMIv2 Module: SNMPv2-SMI
SMIv2 Type: BITS SMIv2 Type: BITS
Yang Type: bits YANG Type: bits
SMIv2 Module: SNMPv2-SMI SMIv2 Module: SNMPv2-SMI
SMIv2 Type: IpAddress SMIv2 Type: IpAddress
YANG Module: ietf-inet-types YANG Module: ietf-inet-types
Yang Type: ipv4-address YANG Type: ipv4-address
SMIv2 Module: SNMPv2-SMI SMIv2 Module: SNMPv2-SMI
SMIv2 Type: Counter32 SMIv2 Type: Counter32
YANG Module: ietf-yang-types YANG Module: ietf-yang-types
Yang Type: counter32 YANG Type: counter32
SMIv2 Module: SNMPv2-SMI SMIv2 Module: SNMPv2-SMI
SMIv2 Type: Gauge32 SMIv2 Type: Gauge32
YANG Module: ietf-yang-types YANG Module: ietf-yang-types
Yang Type: gauge32 YANG Type: gauge32
SMIv2 Module: SNMPv2-SMI SMIv2 Module: SNMPv2-SMI
SMIv2 Type: TimeTicks SMIv2 Type: TimeTicks
YANG Module: ietf-yang-types YANG Module: ietf-yang-types
Yang Type: timeticks YANG Type: timeticks
SMIv2 Module: SNMPv2-SMI SMIv2 Module: SNMPv2-SMI
SMIv2 Type: Counter64 SMIv2 Type: Counter64
YANG Module: ietf-yang-types YANG Module: ietf-yang-types
Yang Type: counter64 YANG Type: counter64
SMIv2 Module: SNMPv2-SMI SMIv2 Module: SNMPv2-SMI
SMIv2 Type: Unsigned32 SMIv2 Type: Unsigned32
Yang Type: uint32 YANG Type: uint32
SMIv2 Module: SNMPv2-SMI SMIv2 Module: SNMPv2-SMI
SMIv2 Type: Opaque SMIv2 Type: Opaque
YANG Module: ietf-yang-smiv2 YANG Module: ietf-yang-smiv2
Yang Type: opaque YANG Type: opaque
SMIv2 Module: SNMPv2-TC SMIv2 Module: SNMPv2-TC
SMIv2 Type: PhysAddress SMIv2 Type: PhysAddress
YANG Module: ietf-yang-types YANG Module: ietf-yang-types
Yang Type: phys-address YANG Type: phys-address
SMIv2 Module: SNMPv2-TC SMIv2 Module: SNMPv2-TC
SMIv2 Type: MacAddress SMIv2 Type: MacAddress
YANG Module: ietf-yang-types YANG Module: ietf-yang-types
Yang Type: mac-address YANG Type: mac-address
SMIv2 Module: SNMPv2-TC SMIv2 Module: SNMPv2-TC
SMIv2 Type: TruthValue SMIv2 Type: TruthValue
Yang Type: boolean YANG Type: boolean
SMIv2 Module: SNMPv2-TC SMIv2 Module: SNMPv2-TC
SMIv2 Type: TimeStamp SMIv2 Type: TimeStamp
YANG Module: ietf-yang-types YANG Module: ietf-yang-types
Yang Type: timestamp YANG Type: timestamp
SMIv2 Module: RMON2-MIB SMIv2 Module: RMON2-MIB
SMIv2 Type: ZeroBasedCounter32 SMIv2 Type: ZeroBasedCounter32
YANG Module: ietf-yang-types YANG Module: ietf-yang-types
Yang Type: zero-based-counter32 YANG Type: zero-based-counter32
SMIv2 Module: HCNUM-TC SMIv2 Module: HCNUM-TC
SMIv2 Type: ZeroBasedCounter64 SMIv2 Type: ZeroBasedCounter64
YANG Module: ietf-yang-types YANG Module: ietf-yang-types
Yang Type: zero-based-counter64 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 used in the import statements. The input of the prefix generation be 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.
 End of changes. 45 change blocks. 
59 lines changed or deleted 65 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/