--- 1/draft-ietf-netmod-smi-yang-04.txt 2012-04-20 17:14:14.886754818 +0200 +++ 2/draft-ietf-netmod-smi-yang-05.txt 2012-04-20 17:14:14.942805390 +0200 @@ -1,153 +1,183 @@ Network Working Group J. Schoenwaelder Internet-Draft Jacobs University -Intended status: Standards Track January 19, 2012 -Expires: July 22, 2012 +Intended status: Standards Track April 20, 2012 +Expires: October 22, 2012 Translation of SMIv2 MIB Modules to YANG Modules - draft-ietf-netmod-smi-yang-04 + draft-ietf-netmod-smi-yang-05 Abstract YANG is a data modeling language used to model configuration and state data manipulated by the NETCONF protocol, NETCONF remote procedure calls, and NETCONF notifications. The Structure of Management Information (SMIv2) defines fundamental data types, an object model, and the rules for writing and revising MIB modules for use with the SNMP protocol. This document defines a translation of - SMIv2 MIB modules into YANG modules, enabling read-only access to - data objects defined in SMIv2 MIB modules via NETCONF. + SMIv2 MIB modules into YANG modules, enabling read-only (config + false) access to data objects defined in SMIv2 MIB modules via + NETCONF. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on July 22, 2012. + This Internet-Draft will expire on October 22, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Mapping of Well Known Types . . . . . . . . . . . . . . . . . 4 - 3. Translation of SMIv2 Modules and SMIv2 IMPORT Clauses . . . . 5 - 3.1. Example: IMPORTS of IF-MIB . . . . . . . . . . . . . . . . 6 - 4. Translation of the MODULE-IDENTITY Macro . . . . . . . . . . . 7 - 4.1. MODULE-IDENTITY Translation Rules . . . . . . . . . . . . 7 - 4.2. Example: MODULE-IDENTITY of IF-MIB . . . . . . . . . . . . 8 - 5. Translation of the TEXTUAL-CONVENTION Macro . . . . . . . . . 9 - 5.1. TEXTUAL-CONVENTION Translation Rules . . . . . . . . . . . 9 - 5.2. Example: OwnerString and InterfaceIndex of IF-MIB . . . . 10 - 5.3. Example: IfDirection of the DIFFSERV-MIB . . . . . . . . . 10 - 6. Translation of OBJECT IDENTIFIER Assignments . . . . . . . . . 12 - 7. Translation of the OBJECT-TYPE Macro . . . . . . . . . . . . . 13 - 7.1. Scalar and Columnar Object Translation Rules . . . . . . . 13 - 7.2. Example: ifNumber and ifIndex of the IF-MIB . . . . . . . 14 - 7.3. Non-Augmenting Conceptual Table Translation Rules . . . . 15 - 7.4. Example: ifTable of the IF-MIB . . . . . . . . . . . . . . 17 - 7.5. Example: ifRcvAddressTable of the IF-MIB . . . . . . . . . 17 - 7.6. Example: alHostTable of the RMON2-MIB . . . . . . . . . . 19 - 7.7. Augmenting Conceptual Tables Translation Rules . . . . . . 20 - 7.8. Example: ifXTable of the IF-MIB . . . . . . . . . . . . . 21 - 8. Translation of the OBJECT-IDENTITY Macro . . . . . . . . . . . 23 - 8.1. OBJECT-IDENTITY Translation Rules . . . . . . . . . . . . 23 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Mapping of Well Known Types . . . . . . . . . . . . . . . . . 5 + 3. Translation of SMIv2 Modules and SMIv2 IMPORT Clauses . . . . 6 + 3.1. Example: IMPORTS of IF-MIB . . . . . . . . . . . . . . . . 7 + 4. Translation of the MODULE-IDENTITY Macro . . . . . . . . . . . 8 + 4.1. MODULE-IDENTITY Translation Rules . . . . . . . . . . . . 8 + 4.2. Example: MODULE-IDENTITY of IF-MIB . . . . . . . . . . . . 9 + 5. Translation of the TEXTUAL-CONVENTION Macro . . . . . . . . . 10 + 5.1. TEXTUAL-CONVENTION Translation Rules . . . . . . . . . . . 10 + 5.2. Example: OwnerString and InterfaceIndex of IF-MIB . . . . 11 + 5.3. Example: IfDirection of the DIFFSERV-MIB . . . . . . . . . 11 + 6. Translation of OBJECT IDENTIFIER Assignments . . . . . . . . . 13 + 7. Translation of the OBJECT-TYPE Macro . . . . . . . . . . . . . 14 + 7.1. Scalar and Columnar Object Translation Rules . . . . . . . 14 + 7.2. Example: ifNumber and ifIndex of the IF-MIB . . . . . . . 15 + 7.3. Non-Augmenting Conceptual Table Translation Rules . . . . 16 + 7.4. Example: ifTable of the IF-MIB . . . . . . . . . . . . . . 18 + 7.5. Example: ifRcvAddressTable of the IF-MIB . . . . . . . . . 18 + 7.6. Example: alHostTable of the RMON2-MIB . . . . . . . . . . 20 + 7.7. Augmenting Conceptual Tables Translation Rules . . . . . . 21 + 7.8. Example: ifXTable of the IF-MIB . . . . . . . . . . . . . 22 + 8. Translation of the OBJECT-IDENTITY Macro . . . . . . . . . . . 24 + 8.1. OBJECT-IDENTITY Translation Rules . . . . . . . . . . . . 24 8.2. Example: diffServTBParamSimpleTokenBucket of the - DIFFSERV-MIB . . . . . . . . . . . . . . . . . . . . . . . 23 - 9. Translation of the NOTIFICATION-TYPE Macro . . . . . . . . . . 24 - 9.1. NOTIFICATION-TYPE Translation Rules . . . . . . . . . . . 24 - 9.2. Example: linkDown NOTIFICATION-TYPE of IF-MIB . . . . . . 24 - 10. YANG Language Extension Definition . . . . . . . . . . . . . . 27 - 11. Implementing Configuration Data Nodes . . . . . . . . . . . . 31 - 11.1. Example: addressMapControlTable of RMON2-MIB . . . . . . . 31 - 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 - 13. Security Considerations . . . . . . . . . . . . . . . . . . . 35 - 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36 - 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 - 15.1. Normative References . . . . . . . . . . . . . . . . . . . 37 - 15.2. Informative References . . . . . . . . . . . . . . . . . . 37 - Appendix A. Mapping of Well Known Types (normative) . . . . . . . 39 - Appendix B. Module Prefix Generation (informative) . . . . . . . 42 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 43 + DIFFSERV-MIB . . . . . . . . . . . . . . . . . . . . . . . 24 + 9. Translation of the NOTIFICATION-TYPE Macro . . . . . . . . . . 25 + 9.1. NOTIFICATION-TYPE Translation Rules . . . . . . . . . . . 25 + 9.2. Example: linkDown NOTIFICATION-TYPE of IF-MIB . . . . . . 25 + 10. YANG Language Extension Definition . . . . . . . . . . . . . . 28 + 11. Implementing Configuration Data Nodes . . . . . . . . . . . . 32 + 11.1. Example: addressMapControlTable of RMON2-MIB . . . . . . . 32 + 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 + 13. Security Considerations . . . . . . . . . . . . . . . . . . . 36 + 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37 + 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 + 15.1. Normative References . . . . . . . . . . . . . . . . . . . 38 + 15.2. Informative References . . . . . . . . . . . . . . . . . . 38 + Appendix A. Mapping of Well Known Types (normative) . . . . . . . 40 + Appendix B. Module Prefix Generation (informative) . . . . . . . 43 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 44 1. Introduction This document describes a translation of SMIv2 [RFC2578], [RFC2579], [RFC2580] MIB modules into YANG [RFC6020] modules, enabling read-only - access to data objects defined in SMIv2 MIB modules via NETCONF. The - mapping is illustrated by examples showing the translation of parts - of the IF-MIB [RFC2863], the DIFFSERV-MIB [RFC3289], and the RMON2- - MIB [RFC4502] SMIv2 module. + (config false) access to SMIv2 objects defined in SMIv2 MIB modules + via NETCONF [RFC6241]. For a discussion why SMIv2 read-write or + read-create objects are translated to read-only (config false) YANG + objects, see Section 11. - SMIv1 modules may be converted to YANG by first following the rules - in [RFC3584] to convert the SMIv1 module to SMIv2, then following the - rules in this document to convert to YANG. + YANG modules generated from SMIv2 modules should not be modified. + Any necessary changes should be made by modifying the original SMIv2 + modules (with proper updates of the SMIv2 LAST-UPDATED and REVISION + 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 + deviations: YANG modules generated from SMIv2 modules can be + augmented and like any other YANG module and YANG deviations can be + used to document how an implementation deviates from the generated + YANG module. + + SMIv1 modules can be converted to YANG by first following the rules + in [RFC3584] to convert the SMIv1 module to SMIv2 and then following + the rules in this document to convert the obtained SMIv2 module to + YANG. + + The SMIv2 to YANG mapping is illustrated by examples showing the + translation of parts of the IF-MIB [RFC2863], the DIFFSERV-MIB + [RFC3289], and the RMON2-MIB [RFC4502] SMIv2 module. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119]. 2. Mapping of Well Known Types The SMIv2 base types and some well known derived textual conventions 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 associated DISPLAY-HINT, then the corresponding YANG base type is the string type. Otherwise, the binary type is used. Similarly, the mapping of the INTEGER type depends on its usage as an enumeration or - a 32-bit integral type. Implementations are encouraged to provide - options to handle situations where DISPLAY-HINTs are added during a - revision of a module and backwards compatibility must be preserved. + a 32-bit integral type. Implementations should provide + implementation specific options to 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 impact the imports of the - generated YANG module since some SMIv2 types and textual conventions - map to YANG types defined in the ietf-yang-types and ietf-inet-types - YANG modules 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. + 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 + SMIv2 types and textual conventions map to YANG types defined in the + ietf-yang-types and ietf-inet-types 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. 3. Translation of SMIv2 Modules and SMIv2 IMPORT Clauses - SMIv2 modules are mapped to corresponding YANG modules. The YANG - module name MUST be the same as the SMIv2 module name. + SMIv2 modules are mapped to corresponding YANG modules. The + generated YANG module name MUST be the same as the SMIv2 module name. - The YANG namespace MUST be constructed out of a constant prefix - followed by the SMIv2 module name. Since SMIv2 module names can be - assumed to be unique (see Section 3 in [RFC2578]), the resulting YANG - namespace is unique. The registered prefix is - urn:ietf:params:xml:ns:yang:smiv2:, see the IANA considerations in - Section 12. + The YANG namespace MUST be constructed out of the IANA registered + 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 + be unique (see Section 3 in [RFC2578]), the resulting YANG namespace + is unique. The YANG prefix MAY be derived from the SMIv2 module name using the module prefix generation algorithm described in Appendix B. The YANG prefix is supposed to be short and it must be unique within the set of all prefixes used by a YANG module. The algorithm described in Appendix B generates such prefixes. SMIv2 IMPORT clauses are translated to YANG import statements. One major difference between the SMIv2 import mechanism and the YANG import mechanism is that SMIv2 IMPORT clauses import specific symbols @@ -344,30 +374,35 @@ statement. o The SMIv2 REFERENCE clause is mapped to the YANG reference statement. o The SMIv2 SYNTAX clause is mapped to the YANG type statement. SMIv2 range restrictions are mapped to YANG range statements while SMIv2 length restrictions are mapped to YANG length statements. SMIv2 INTEGER enumerations are mapped to YANG enum/value statements. SMIv2 BITS are mapped to YANG bit/position - statements. + statements. For OCTET STRING types that are mapped to a YANG + string base type (see Section 2), the length specified in the YANG + length statement must be consistent with the stringified + representation of values. If an implementation is unable to + derive a proper length restrictions, then the YANG length + statement MUST be omitted. This translation assumes that labels of named numbers and named bits do not change when an SMIv2 module is revised. This is consistent with the clarification of the SMIv2 module revision rules in Section 4.9 of [RFC4181]. 5.2. Example: OwnerString and InterfaceIndex of IF-MIB - The translation of the OwnerString and InterfaceIndex textual + The translations of the OwnerString and InterfaceIndex textual conventions of the IF-MIB [RFC2863] are shown below. typedef OwnerString { type string { length "0..255"; pattern '\p{IsBasicLatin}{0,255}'; } status deprecated; description "This data type is used to model an administratively @@ -458,21 +493,26 @@ 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 representing a conceptual row, see Section 7.3. o The SMIv2 SYNTAX clause is mapped to the YANG type statement. SMIv2 range restrictions are mapped to YANG range statements while SMIv2 length restrictions are mapped to YANG length statements. SMIv2 INTEGER enumerations are mapped to YANG enum/value statements. SMIv2 BITS are mapped to YANG bit/position - statements. + statements. For OCTET STRING types that are mapped to a YANG + string base type (see Section 2), the length specified in the YANG + length statement must be consistent with the stringified + representation of values. If an implementation is unable to + derive a proper length restrictions, then the YANG length + statement MUST be omitted. o The SMIv2 UNITS clause is mapped to the YANG units statement. o The SMIv2 MAX-ACCESS is translated into an smiv2:max-access statement. Refer to the YANG extension defined in Section 10. o The SMIv2 STATUS clause is mapped to the YANG status statement. The generation of the YANG status statement is skipped if the value of the STATUS clause is current. @@ -735,21 +775,21 @@ care to avoid such combinations."; smiv2:oid "1.3.6.1.2.1.16.16.1.1"; // ... leaf protocolDirLocalIndex { type leafref { path "/rmon2-mib:RMON2-MIB/" + "rmon2-mib:protocolDirTable/" - + "rmon2-mib:protocolDirEntryf/" + + "rmon2-mib:protocolDirEntry/" + "rmon2-mib:protocolDirLocalIndex"; } } // ... leaf protocolDirLocalIndex_2 { type leafref { path "/rmon2-mib:RMON2-MIB/" + "rmon2-mib:protocolDirTable/" @@ -1010,21 +1050,24 @@ } 10. YANG Language Extension Definition This section defines some YANG extension statements that can be used to capture some information present in SMIv2 modules that is not translated into core YANG statements. The YANG module references [RFC2578] and [RFC2579]. - file "ietf-yang-smiv2@2011-11-25.yang" + RFC Ed.: update the date below with the revision date of the YANG + module and remove this note. + + file "ietf-yang-smiv2@2012-04-20.yang" module ietf-yang-smiv2 { namespace "urn:ietf:params:xml:ns:yang:ietf-yang-smiv2"; prefix "smiv2"; organization "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; contact @@ -1037,36 +1080,36 @@ WG Chair: Juergen Schoenwaelder Editor: Juergen Schoenwaelder "; description "This module defines YANG extensions that are used to translate SMIv2 concepts into YANG. - Copyright (c) 2011 IETF Trust and the persons identified as + Copyright (c) 2012 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see 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 2011-11-25 { + revision 2012-04-20 { description "Initial revision."; reference "RFC XXXX: Translation of SMIv2 MIB Modules to YANG Modules"; // RFC Ed.: replace XXXX with actual RFC number and remove this note } identity object-identity { description "Base identity for all SMIv2 OBJECT-IDENTITYs."; @@ -1094,24 +1137,29 @@ "The display-hint statement takes as an argument the DISPLAY-HINT assigned to an SMIv2 textual convention."; reference "RFC2579: 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"; + assigned to an SMIv2 object definition. + + The MAX-ACCESS value is SMIv2 specific and has no impact on + the access provided to YANG objects through protocols such + as NETCONF."; reference "RFC2578: Structure of Management Information Version 2 (SMIv2)"; } + extension defval { argument "value"; description "The defval statement takes as an argument a default value defined by an SMIv2 DEFVAL clause. Note that the value is in the SMIv2 value space defined by the SMIv2 syntax of the corresponding object and not in the YANG value space defined by the corresponding YANG data type."; reference "RFC2578: Structure of Management Information Version 2 (SMIv2)"; @@ -1161,35 +1207,36 @@ reference "RFC2578: Structure of Management Information Version 2 (SMIv2)"; } } 11. Implementing Configuration Data Nodes - The translation of SMIv2 MIB modules into YANG modules defined above - is read-only. One reason is that the persistency models of the - underlying protocols, SNMP and NETCONF, are quite different. With - SNMP, the persistency of a writable object depends either on the - object definition itself (i.e., the text in the DESCRIPTION clause) - or the persistency properties of the conceptual row it is part of, - sometimes controlled via a columnar object using the StorageType - textual convention. With NETCONF, the persistency of configuration - objects is determined by the properties of the underlying datastore. - Furthermore, NETCONF as defined in [RFC6241] does not provide a - standard operation to modify operational state. The - and operations only manipulate configuration data. As - a consequence of these considerations, it is not possible to generate - YANG configuration data nodes from SMIv2 definitions in an automated - way. + The result of the translation of SMIv2 MIB modules into YANG modules, + even if SMIv2 objects are read-write or read-create, consists of + read-only (config false) YANG objects. One reason is that the + persistency models of the underlying protocols, SNMP and NETCONF, are + quite different. With SNMP, the persistency of a writable object + depends either on the object definition itself (i.e., the text in the + DESCRIPTION clause) or the persistency properties of the conceptual + row it is part of, sometimes controlled via a columnar object using + the StorageType textual convention. With NETCONF, the persistency of + configuration objects is determined by the properties of the + underlying datastore. Furthermore, NETCONF as defined in [RFC6241] + does not provide a standard operation to modify operational state. + The and operations only manipulate + configuration data. As a consequence of these considerations, it is + not possible to generate YANG configuration data nodes from SMIv2 + definitions in an automated way. However, for selected SMIv2 objects where the SNMP and NETCONF persistency semantics are consistent, implementations may choose to implement some YANG data nodes generated from SMIv2 definitions as configuration data nodes. Such a deviation from the generated read- only YANG module should be formally documented in the form of a separate YANG module that uses YANG deviation statements to change the config property of the data nodes implemented as configuration data nodes from false to true. Deviations that change the config false property to true without any other changes to the semantics of @@ -1305,35 +1352,39 @@ registry [RFC6020]. name: ietf-yang-smiv2 namespace: urn:ietf:params:xml:ns:yang:ietf-yang-smiv2 prefix: smiv2 reference: RFC XXXX 13. Security Considerations This document defines a translation of SMIv2 MIB modules into YANG - modules, enabling read-only access to data objects defined in SMIv2 - MIB modules via NETCONF. The translation itself has no security - impact on the Internet. + modules, enabling read-only (config false) access to data objects + defined in SMIv2 MIB modules via NETCONF. The translation itself has + no security impact on the Internet. - Users of translated SMIv2 models that have been published as RFCs - should consult the security considerations of the respective RFCs. - In addition, the security considerations for the NETCONF protocol - [RFC6241] should be consulted to understand how NETCONF protects - potentially sensitive information. + Users of YANG data models generated from SMIv2 data models that have + been published in the RFC series are advised to consult the security + considerations of the respective RFCs. The security considerations + of RFCs containing SMIv2 data models explain which objects are + sensitive and important to protect. NETCONF users are encouraged to + make use of the NETCONF access control model [RFC6536], which allows + to specify access control rules to protect potentially sensitive + information. 14. Acknowledgements The editor wishes to thank the following individuals for providing helpful comments on various versions of this document: Andy Bierman, - Martin Bjorklund, David Reid, and David Spakes. + Benoit Claise, Martin Bjorklund, Leif Johansson, David Reid, Dan + Romascanu, and David Spakes. 15. References 15.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information @@ -1374,22 +1425,30 @@ [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB Documents", BCP 111, RFC 4181, September 2005. [RFC4502] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2", RFC 4502, May 2006. [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. + [RFC6536] Bierman, A., Ed. and M. Bjorklund, Ed., "Network + Configuration Protocol (NETCONF) Access Control Model", + RFC 6536, March 2012. + Appendix A. Mapping of Well Known Types (normative) + This normative appendix describes the mapping of SMIv2 types to YANG + types. The mapping is fully consistent with Table 1 and Table 2 of + [RFC6021]. + SMIv2 Module: SNMPv2-SMI SMIv2 Type: INTEGER (used as an enumeration) YANG Type: enumeration SMIv2 Module: SNMPv2-SMI SMIv2 Type: INTEGER (used as a numeric type) YANG Type: int32 SMIv2 Module: SNMPv2-SMI SMIv2 Type: Integer32