draft-ietf-netmod-smi-yang-04.txt   draft-ietf-netmod-smi-yang-05.txt 
Network Working Group J. Schoenwaelder Network Working Group J. Schoenwaelder
Internet-Draft Jacobs University Internet-Draft Jacobs University
Intended status: Standards Track January 19, 2012 Intended status: Standards Track April 20, 2012
Expires: July 22, 2012 Expires: October 22, 2012
Translation of SMIv2 MIB Modules to YANG Modules Translation of SMIv2 MIB Modules to YANG Modules
draft-ietf-netmod-smi-yang-04 draft-ietf-netmod-smi-yang-05
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 (config
data objects defined in SMIv2 MIB modules via NETCONF. false) access to data objects defined in SMIv2 MIB modules via
NETCONF.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 July 22, 2012. This Internet-Draft will expire on October 22, 2012.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. 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 Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Mapping of Well Known Types . . . . . . . . . . . . . . . . . 4 2. Mapping of Well Known Types . . . . . . . . . . . . . . . . . 5
3. Translation of SMIv2 Modules and SMIv2 IMPORT Clauses . . . . 5 3. Translation of SMIv2 Modules and SMIv2 IMPORT Clauses . . . . 6
3.1. Example: IMPORTS of IF-MIB . . . . . . . . . . . . . . . . 6 3.1. Example: IMPORTS of IF-MIB . . . . . . . . . . . . . . . . 7
4. Translation of the MODULE-IDENTITY Macro . . . . . . . . . . . 7 4. Translation of the MODULE-IDENTITY Macro . . . . . . . . . . . 8
4.1. MODULE-IDENTITY Translation Rules . . . . . . . . . . . . 7 4.1. MODULE-IDENTITY Translation Rules . . . . . . . . . . . . 8
4.2. Example: MODULE-IDENTITY of IF-MIB . . . . . . . . . . . . 8 4.2. Example: MODULE-IDENTITY of IF-MIB . . . . . . . . . . . . 9
5. Translation of the TEXTUAL-CONVENTION Macro . . . . . . . . . 9 5. Translation of the TEXTUAL-CONVENTION Macro . . . . . . . . . 10
5.1. TEXTUAL-CONVENTION Translation Rules . . . . . . . . . . . 9 5.1. TEXTUAL-CONVENTION Translation Rules . . . . . . . . . . . 10
5.2. Example: OwnerString and InterfaceIndex of IF-MIB . . . . 10 5.2. Example: OwnerString and InterfaceIndex of IF-MIB . . . . 11
5.3. Example: IfDirection of the DIFFSERV-MIB . . . . . . . . . 10 5.3. Example: IfDirection of the DIFFSERV-MIB . . . . . . . . . 11
6. Translation of OBJECT IDENTIFIER Assignments . . . . . . . . . 12 6. Translation of OBJECT IDENTIFIER Assignments . . . . . . . . . 13
7. Translation of the OBJECT-TYPE Macro . . . . . . . . . . . . . 13 7. Translation of the OBJECT-TYPE Macro . . . . . . . . . . . . . 14
7.1. Scalar and Columnar Object Translation Rules . . . . . . . 13 7.1. Scalar and Columnar Object Translation Rules . . . . . . . 14
7.2. Example: ifNumber and ifIndex of the IF-MIB . . . . . . . 14 7.2. Example: ifNumber and ifIndex of the IF-MIB . . . . . . . 15
7.3. Non-Augmenting Conceptual Table Translation Rules . . . . 15 7.3. Non-Augmenting Conceptual Table Translation Rules . . . . 16
7.4. Example: ifTable of the IF-MIB . . . . . . . . . . . . . . 17 7.4. Example: ifTable of the IF-MIB . . . . . . . . . . . . . . 18
7.5. Example: ifRcvAddressTable of the IF-MIB . . . . . . . . . 17 7.5. Example: ifRcvAddressTable of the IF-MIB . . . . . . . . . 18
7.6. Example: alHostTable of the RMON2-MIB . . . . . . . . . . 19 7.6. Example: alHostTable of the RMON2-MIB . . . . . . . . . . 20
7.7. Augmenting Conceptual Tables Translation Rules . . . . . . 20 7.7. Augmenting Conceptual Tables Translation Rules . . . . . . 21
7.8. Example: ifXTable of the IF-MIB . . . . . . . . . . . . . 21 7.8. Example: ifXTable of the IF-MIB . . . . . . . . . . . . . 22
8. Translation of the OBJECT-IDENTITY Macro . . . . . . . . . . . 23 8. Translation of the OBJECT-IDENTITY Macro . . . . . . . . . . . 24
8.1. OBJECT-IDENTITY Translation Rules . . . . . . . . . . . . 23 8.1. OBJECT-IDENTITY Translation Rules . . . . . . . . . . . . 24
8.2. Example: diffServTBParamSimpleTokenBucket of the 8.2. Example: diffServTBParamSimpleTokenBucket of the
DIFFSERV-MIB . . . . . . . . . . . . . . . . . . . . . . . 23 DIFFSERV-MIB . . . . . . . . . . . . . . . . . . . . . . . 24
9. Translation of the NOTIFICATION-TYPE Macro . . . . . . . . . . 24 9. Translation of the NOTIFICATION-TYPE Macro . . . . . . . . . . 25
9.1. NOTIFICATION-TYPE Translation Rules . . . . . . . . . . . 24 9.1. NOTIFICATION-TYPE Translation Rules . . . . . . . . . . . 25
9.2. Example: linkDown NOTIFICATION-TYPE of IF-MIB . . . . . . 24 9.2. Example: linkDown NOTIFICATION-TYPE of IF-MIB . . . . . . 25
10. YANG Language Extension Definition . . . . . . . . . . . . . . 27 10. YANG Language Extension Definition . . . . . . . . . . . . . . 28
11. Implementing Configuration Data Nodes . . . . . . . . . . . . 31 11. Implementing Configuration Data Nodes . . . . . . . . . . . . 32
11.1. Example: addressMapControlTable of RMON2-MIB . . . . . . . 31 11.1. Example: addressMapControlTable of RMON2-MIB . . . . . . . 32
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
13. Security Considerations . . . . . . . . . . . . . . . . . . . 35 13. Security Considerations . . . . . . . . . . . . . . . . . . . 36
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
15.1. Normative References . . . . . . . . . . . . . . . . . . . 37 15.1. Normative References . . . . . . . . . . . . . . . . . . . 38
15.2. Informative References . . . . . . . . . . . . . . . . . . 37 15.2. Informative References . . . . . . . . . . . . . . . . . . 38
Appendix A. Mapping of Well Known Types (normative) . . . . . . . 39 Appendix A. Mapping of Well Known Types (normative) . . . . . . . 40
Appendix B. Module Prefix Generation (informative) . . . . . . . 42 Appendix B. Module Prefix Generation (informative) . . . . . . . 43
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 43 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
access to data objects defined in SMIv2 MIB modules via NETCONF. The (config false) access to SMIv2 objects defined in SMIv2 MIB modules
mapping is illustrated by examples showing the translation of parts via NETCONF [RFC6241]. For a discussion why SMIv2 read-write or
of the IF-MIB [RFC2863], the DIFFSERV-MIB [RFC3289], and the RMON2- read-create objects are translated to read-only (config false) YANG
MIB [RFC4502] SMIv2 module. objects, see Section 11.
SMIv1 modules may be converted to YANG by first following the rules YANG modules generated from SMIv2 modules should not be modified.
in [RFC3584] to convert the SMIv1 module to SMIv2, then following the Any necessary changes should be made by modifying the original SMIv2
rules in this document to convert to YANG. 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", 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 should provide
options to handle situations where DISPLAY-HINTs are added during a implementation specific options to handle situations where DISPLAY-
revision of a module and backwards compatibility must be preserved. 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 The mappings shown in Appendix A may require to import the ietf-yang-
generated YANG module since some SMIv2 types and textual conventions types, ietf-inet-types, or ietf-yang-smiv2 YANG modules since some
map to YANG types defined in the ietf-yang-types and ietf-inet-types SMIv2 types and textual conventions map to YANG types defined in the
YANG modules defined in [RFC6021] and the ietf-yang-smiv2 YANG module ietf-yang-types and ietf-inet-types YANG modules defined in [RFC6021]
defined in this document. Implementations MUST add any additional and the ietf-yang-smiv2 YANG module defined in this document.
imports required by the type mapping. Implementations MUST add any additional 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
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 a constant prefix The YANG namespace MUST be constructed out of the IANA registered
followed by the SMIv2 module name. Since SMIv2 module names can be prefix urn:ietf:params:xml:ns:yang:smiv2: (see Section 12) followed
assumed to be unique (see Section 3 in [RFC2578]), the resulting YANG by the SMIv2 module name. Since SMIv2 module names can be assumed to
namespace is unique. The registered prefix is be unique (see Section 3 in [RFC2578]), the resulting YANG namespace
urn:ietf:params:xml:ns:yang:smiv2:, see the IANA considerations in is unique.
Section 12.
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
skipping to change at page 9, line 43 skipping to change at page 10, line 43
statement. statement.
o The SMIv2 REFERENCE clause is mapped to the YANG reference o The SMIv2 REFERENCE clause is mapped to the YANG reference
statement. statement.
o The SMIv2 SYNTAX clause is mapped to the YANG type statement. o The SMIv2 SYNTAX clause is mapped to the YANG type statement.
SMIv2 range restrictions are mapped to YANG range statements while SMIv2 range restrictions are mapped to YANG range statements while
SMIv2 length restrictions are mapped to YANG length statements. SMIv2 length restrictions are mapped to YANG length statements.
SMIv2 INTEGER enumerations 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. 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 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 translations 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 13, line 49 skipping to change at page 14, line 49
a previous revision of the SMIv2 module did not have an ambiguity, 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 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. 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 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 20, line 13 skipping to change at page 21, line 13
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:protocolDirEntry/"
+ "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/"
skipping to change at page 27, line 12 skipping to change at page 28, line 12
} }
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].
<CODE BEGINS> 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.
<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
skipping to change at page 27, line 39 skipping to change at page 28, line 42
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) 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. 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 XXXX; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
// RFC Ed.: replace XXXX with actual RFC number and remove this note // RFC Ed.: replace XXXX with actual RFC number and remove this note
// RFC Ed.: please update the date to the date of publication // RFC Ed.: please update the date to the date of publication
revision 2011-11-25 { revision 2012-04-20 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: Translation of SMIv2 MIB Modules to YANG Modules"; "RFC XXXX: Translation of SMIv2 MIB Modules to YANG Modules";
// RFC Ed.: replace XXXX with actual RFC number and remove this note // RFC Ed.: replace XXXX with actual RFC number and remove this note
} }
identity object-identity { identity object-identity {
description description
"Base identity for all SMIv2 OBJECT-IDENTITYs."; "Base identity for all SMIv2 OBJECT-IDENTITYs.";
skipping to change at page 28, line 48 skipping to change at page 29, line 50
"The display-hint statement takes as an argument the DISPLAY-HINT "The display-hint statement takes as an argument the DISPLAY-HINT
assigned to an SMIv2 textual convention."; assigned to an SMIv2 textual convention.";
reference reference
"RFC2579: Textual Conventions for SMIv2"; "RFC2579: Textual Conventions for SMIv2";
} }
extension max-access { extension max-access {
argument "access"; argument "access";
description description
"The max-access statement takes as an argument the MAX-ACCESS "The max-access statement takes as an argument the MAX-ACCESS
assigned to an SMIv2 object definition"; assigned to an SMIv2 object definition.
The MAX-ACCESS value is SMIv2 specific and has no impact on
the access provided to YANG objects through protocols such
as NETCONF.";
reference reference
"RFC2578: Structure of Management Information Version 2 (SMIv2)"; "RFC2578: Structure of Management Information Version 2 (SMIv2)";
} }
extension defval { extension defval {
argument "value"; argument "value";
description description
"The defval statement takes as an argument a default value "The defval statement takes as an argument a default value
defined by an SMIv2 DEFVAL clause. Note that the value is in defined by an SMIv2 DEFVAL clause. Note that the value is in
the SMIv2 value space defined by the SMIv2 syntax of the the SMIv2 value space defined by the SMIv2 syntax of the
corresponding object and not in the YANG value space corresponding object and not in the YANG value space
defined by the corresponding YANG data type."; defined by the corresponding YANG data type.";
reference reference
"RFC2578: Structure of Management Information Version 2 (SMIv2)"; "RFC2578: Structure of Management Information Version 2 (SMIv2)";
skipping to change at page 31, line 7 skipping to change at page 32, line 7
reference reference
"RFC2578: Structure of Management Information Version 2 (SMIv2)"; "RFC2578: Structure of Management Information Version 2 (SMIv2)";
} }
} }
<CODE ENDS> <CODE ENDS>
11. Implementing Configuration Data Nodes 11. Implementing Configuration Data Nodes
The translation of SMIv2 MIB modules into YANG modules defined above The result of the translation of SMIv2 MIB modules into YANG modules,
is read-only. One reason is that the persistency models of the even if SMIv2 objects are read-write or read-create, consists of
underlying protocols, SNMP and NETCONF, are quite different. With read-only (config false) YANG objects. One reason is that the
SNMP, the persistency of a writable object depends either on the persistency models of the underlying protocols, SNMP and NETCONF, are
object definition itself (i.e., the text in the DESCRIPTION clause) quite different. With SNMP, the persistency of a writable object
or the persistency properties of the conceptual row it is part of, depends either on the object definition itself (i.e., the text in the
sometimes controlled via a columnar object using the StorageType DESCRIPTION clause) or the persistency properties of the conceptual
textual convention. With NETCONF, the persistency of configuration row it is part of, sometimes controlled via a columnar object using
objects is determined by the properties of the underlying datastore. the StorageType textual convention. With NETCONF, the persistency of
Furthermore, NETCONF as defined in [RFC6241] does not provide a configuration objects is determined by the properties of the
standard operation to modify operational state. The <edit-config> underlying datastore. Furthermore, NETCONF as defined in [RFC6241]
and <copy-config> operations only manipulate configuration data. As does not provide a standard operation to modify operational state.
a consequence of these considerations, it is not possible to generate The <edit-config> and <copy-config> operations only manipulate
YANG configuration data nodes from SMIv2 definitions in an automated configuration data. As a consequence of these considerations, it is
way. 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 However, for selected SMIv2 objects where the SNMP and NETCONF
persistency semantics are consistent, implementations may choose to persistency semantics are consistent, implementations may choose to
implement some YANG data nodes generated from SMIv2 definitions as implement some YANG data nodes generated from SMIv2 definitions as
configuration data nodes. Such a deviation from the generated read- configuration data nodes. Such a deviation from the generated read-
only YANG module should be formally documented in the form of a only YANG module should be formally documented in the form of a
separate YANG module that uses YANG deviation statements to change separate YANG module that uses YANG deviation statements to change
the config property of the data nodes implemented as configuration the config property of the data nodes implemented as configuration
data nodes from false to true. Deviations that change the config data nodes from false to true. Deviations that change the config
false property to true without any other changes to the semantics of false property to true without any other changes to the semantics of
skipping to change at page 35, line 8 skipping to change at page 36, line 8
registry [RFC6020]. registry [RFC6020].
name: ietf-yang-smiv2 name: ietf-yang-smiv2
namespace: urn:ietf:params:xml:ns:yang:ietf-yang-smiv2 namespace: urn:ietf:params:xml:ns:yang:ietf-yang-smiv2
prefix: smiv2 prefix: smiv2
reference: RFC XXXX reference: RFC XXXX
13. Security Considerations 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 access to data objects defined in SMIv2 modules, enabling read-only (config false) access to data objects
MIB modules via NETCONF. The translation itself has no security defined in SMIv2 MIB modules via NETCONF. The translation itself has
impact on the Internet. no security impact on the Internet.
Users of translated SMIv2 models that have been published as RFCs Users of YANG data models generated from SMIv2 data models that have
should consult the security considerations of the respective RFCs. been published in the RFC series are advised to consult the security
In addition, the security considerations for the NETCONF protocol considerations of the respective RFCs. The security considerations
[RFC6241] should be consulted to understand how NETCONF protects of RFCs containing SMIv2 data models explain which objects are
potentially sensitive information. 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 14. Acknowledgements
The editor wishes to thank the following individuals for providing The editor wishes to thank the following individuals for providing
helpful comments on various versions of this document: Andy Bierman, 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. 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 39, line 5 skipping to change at page 39, line 9
[RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB
Documents", BCP 111, RFC 4181, September 2005. Documents", BCP 111, RFC 4181, September 2005.
[RFC4502] Waldbusser, S., "Remote Network Monitoring Management [RFC4502] Waldbusser, S., "Remote Network Monitoring Management
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
Configuration Protocol (NETCONF) Access Control Model",
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
types. The mapping is fully consistent with Table 1 and Table 2 of
[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 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
 End of changes. 28 change blocks. 
101 lines changed or deleted 162 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/