draft-ietf-netmod-smi-yang-03.txt   draft-ietf-netmod-smi-yang-04.txt 
Network Working Group J. Schoenwaelder Network Working Group J. Schoenwaelder
Internet-Draft Jacobs University Internet-Draft Jacobs University
Intended status: Standards Track December 8, 2011 Intended status: Standards Track January 19, 2012
Expires: June 10, 2012 Expires: July 22, 2012
Translation of SMIv2 MIB Modules to YANG Modules Translation of SMIv2 MIB Modules to YANG Modules
draft-ietf-netmod-smi-yang-03 draft-ietf-netmod-smi-yang-04
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 June 10, 2012. This Internet-Draft will expire on July 22, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . 10
6. Translation of OBJECT IDENTIFIER Assignments . . . . . . . . . 13 6. Translation of OBJECT IDENTIFIER Assignments . . . . . . . . . 12
7. Translation of the OBJECT-TYPE Macro . . . . . . . . . . . . . 14 7. Translation of the OBJECT-TYPE Macro . . . . . . . . . . . . . 13
7.1. Scalar and Columnar Object Translation Rules . . . . . . . 14 7.1. Scalar and Columnar Object Translation Rules . . . . . . . 13
7.2. Example: ifNumber and ifIndex of the IF-MIB . . . . . . . 15 7.2. Example: ifNumber and ifIndex of the IF-MIB . . . . . . . 14
7.3. Non-Augmenting Conceptual Table Translation Rules . . . . 16 7.3. Non-Augmenting Conceptual Table Translation Rules . . . . 15
7.4. Example: ifTable of the IF-MIB . . . . . . . . . . . . . . 18 7.4. Example: ifTable of the IF-MIB . . . . . . . . . . . . . . 17
7.5. Example: ifRcvAddressTable of the IF-MIB . . . . . . . . . 18 7.5. Example: ifRcvAddressTable of the IF-MIB . . . . . . . . . 17
7.6. Example: alHostTable of the RMON2-MIB . . . . . . . . . . 20 7.6. Example: alHostTable of the RMON2-MIB . . . . . . . . . . 19
7.7. Augmenting Conceptual Tables Translation Rules . . . . . . 21 7.7. Augmenting Conceptual Tables Translation Rules . . . . . . 20
7.8. Example: ifXTable of the IF-MIB . . . . . . . . . . . . . 22 7.8. Example: ifXTable of the IF-MIB . . . . . . . . . . . . . 21
8. Translation of the OBJECT-IDENTITY Macro . . . . . . . . . . . 24 8. Translation of the OBJECT-IDENTITY Macro . . . . . . . . . . . 23
8.1. OBJECT-IDENTITY Translation Rules . . . . . . . . . . . . 24 8.1. OBJECT-IDENTITY Translation Rules . . . . . . . . . . . . 23
8.2. Example: diffServTBParamSimpleTokenBucket of the 8.2. Example: diffServTBParamSimpleTokenBucket of the
DIFFSERV-MIB . . . . . . . . . . . . . . . . . . . . . . . 24 DIFFSERV-MIB . . . . . . . . . . . . . . . . . . . . . . . 23
9. Translation of the NOTIFICATION-TYPE Macro . . . . . . . . . . 25 9. Translation of the NOTIFICATION-TYPE Macro . . . . . . . . . . 24
9.1. NOTIFICATION-TYPE Translation Rules . . . . . . . . . . . 25 9.1. NOTIFICATION-TYPE Translation Rules . . . . . . . . . . . 24
9.2. Example: linkDown NOTIFICATION-TYPE of IF-MIB . . . . . . 25 9.2. Example: linkDown NOTIFICATION-TYPE of IF-MIB . . . . . . 24
10. YANG Language Extension Definition . . . . . . . . . . . . . . 28 10. YANG Language Extension Definition . . . . . . . . . . . . . . 27
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 11. Implementing Configuration Data Nodes . . . . . . . . . . . . 31
12. Security Considerations . . . . . . . . . . . . . . . . . . . 33 11.1. Example: addressMapControlTable of RMON2-MIB . . . . . . . 31
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 13. Security Considerations . . . . . . . . . . . . . . . . . . . 35
14.1. Normative References . . . . . . . . . . . . . . . . . . . 35 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36
14.2. Informative References . . . . . . . . . . . . . . . . . . 35 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Appendix A. Mapping of Well Known Types (normative) . . . . . . . 37 15.1. Normative References . . . . . . . . . . . . . . . . . . . 37
Appendix B. Module Prefix Generation (informative) . . . . . . . 40 15.2. Informative References . . . . . . . . . . . . . . . . . . 37
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 41 Appendix A. Mapping of Well Known Types (normative) . . . . . . . 39
Appendix B. Module Prefix Generation (informative) . . . . . . . 42
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 43
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 parts mapping is illustrated by examples showing the translation of parts
of the IF-MIB [RFC2863], the DIFFSERV-MIB [RFC3289], and the RMON2- of the IF-MIB [RFC2863], the DIFFSERV-MIB [RFC3289], and the RMON2-
MIB [RFC4502] SMIv2 module. MIB [RFC4502] SMIv2 module.
skipping to change at page 6, line 15 skipping to change at page 5, line 15
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
namespace is unique. The registered prefix is namespace is unique. The registered prefix is
urn:ietf:params:xml:ns:yang:smiv2:, see the IANA considerations in urn:ietf:params:xml:ns:yang:smiv2:, see the IANA considerations in
Section 11. 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 32, line 5 skipping to change at page 31, line 5
be used only as a substatement to a node having a parent node be used only as a substatement to a node having a parent node
defined with either a smiv2:oid or smiv2:subid substatement."; defined with either a smiv2:oid or smiv2:subid substatement.";
reference reference
"RFC2578: Structure of Management Information Version 2 (SMIv2)"; "RFC2578: Structure of Management Information Version 2 (SMIv2)";
} }
} }
<CODE ENDS> <CODE ENDS>
11. IANA Considerations 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 <edit-config>
and <copy-config> 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
the data node do not affect the compliance with the YANG module
generated from an SMIv2 module.
11.1. Example: addressMapControlTable of RMON2-MIB
The following example demonstrates how certain columnar objects of
the addressMapControlTable of the RMON2-MIB [RFC4502] can be turned
into YANG configuration data nodes. Note that YANG deviations affect
the property of the target node only and are not inherited downwards.
module acme-RMON2-MIB-deviations {
namespace "http://acme.example.com/RMON2-MIB-deviations";
prefix "acme-rmon2-devs";
import RMON2-MIB {
prefix "rmon2-mib";
revision-date 2006-05-02;
}
revision 2012-01-11 {
description
"First version.";
}
deviation "/rmon2-mib:RMON2-MIB" {
deviate replace {
config true;
}
}
deviation "/rmon2-mib:RMON2-MIB/"
+ "rmon2-mib:addressMapControlTable" {
deviate replace {
config true;
}
}
deviation "/rmon2-mib:RMON2-MIB/"
+ "rmon2-mib:addressMapControlTable/"
+ "rmon2-mib:addressMapControlEntry" {
deviate replace {
config true;
}
}
deviation "/rmon2-mib:RMON2-MIB/"
+ "rmon2-mib:addressMapControlTable/"
+ "rmon2-mib:addressMapControlEntry/"
+ "rmon2-mib:addressMapControlIndex" {
deviate replace {
config true;
}
}
deviation "/rmon2-mib:RMON2-MIB/"
+ "rmon2-mib:addressMapControlTable/"
+ "rmon2-mib:addressMapControlEntry/"
+ "rmon2-mib:addressMapControlDataSource" {
deviate replace {
config true;
}
}
deviation "/rmon2-mib:RMON2-MIB/"
+ "rmon2-mib:addressMapControlTable/"
+ "rmon2-mib:addressMapControlEntry/"
+ "rmon2-mib:addressMapControlOwner" {
deviate replace {
config true;
}
}
}
A NETCONF server that implements the RMON2-MIB module with these
deviations would advertise the following capabilities in its <hello>
message (where whitespace has been added for readability):
<capability>
urn:ietf:params:xml:ns:yang:smiv2:RMON2-MIB?
module=RMON2-MIB&amp;
revision=2006-05-02&amp;
deviations=acme-RMON2-MIB-deviations
</capability>
<capability>
http://acme.example.com/RMON2-MIB-deviations?
module=acme-RMON2-MIB-deviations&amp;
revision=2012-01-11
</capability>
12. IANA Considerations
This document registers two URIs in the IETF XML registry [RFC3688]. This document registers two URIs in the IETF XML registry [RFC3688].
Following the format in RFC 3688, the following registrations have Following the format in RFC 3688, the following registrations have
been made. been made.
URI: urn:ietf:params:xml:ns:yang:ietf-yang-smiv2 URI: urn:ietf:params:xml:ns:yang:ietf-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.
skipping to change at page 33, line 5 skipping to change at page 35, line 5
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 XXXX
12. 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 access to data objects defined in SMIv2
MIB modules via NETCONF. The translation itself has no security MIB modules via NETCONF. The translation itself has no security
impact on the Internet. impact on the Internet.
Users of translated SMIv2 models that have been published as RFCs Users of translated SMIv2 models that have been published as RFCs
should consult the security considerations of the respective RFCs. should consult the security considerations of the respective RFCs.
In addition, the security considerations for the NETCONF protocol In addition, the security considerations for the NETCONF protocol
[RFC6241] should be consulted to understand how NETCONF protects [RFC6241] should be consulted to understand how NETCONF protects
potentially sensitive information. potentially sensitive information.
13. 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. Martin Bjorklund, David Reid, and David Spakes.
14. References 15. References
14.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
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Textual Conventions for SMIv2", Schoenwaelder, Ed., "Textual Conventions for SMIv2",
skipping to change at page 35, line 31 skipping to change at page 37, line 31
"Conformance Statements for SMIv2", STD 58, RFC 2580, "Conformance Statements for SMIv2", STD 58, RFC 2580,
April 1999. April 1999.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010. October 2010.
[RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021, [RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021,
October 2010. October 2010.
14.2. Informative References 15.2. Informative References
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, June 2000. MIB", RFC 2863, June 2000.
[RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information [RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information
Base for the Differentiated Services Architecture", Base for the Differentiated Services Architecture",
RFC 3289, May 2002. RFC 3289, May 2002.
[RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen, [RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen,
"Coexistence between Version 1, Version 2, and Version 3 "Coexistence between Version 1, Version 2, and Version 3
 End of changes. 14 change blocks. 
61 lines changed or deleted 168 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/