idnits 2.17.1 draft-ietf-netmod-smi-yang-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 25, 2011) is 4536 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 6021 (Obsoleted by RFC 6991) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Schoenwaelder 3 Internet-Draft Jacobs University 4 Intended status: Standards Track November 25, 2011 5 Expires: May 28, 2012 7 Translation of SMIv2 MIB Modules to YANG Modules 8 draft-ietf-netmod-smi-yang-02 10 Abstract 12 YANG is a data modeling language used to model configuration and 13 state data manipulated by the NETCONF protocol, NETCONF remote 14 procedure calls, and NETCONF notifications. The Structure of 15 Management Information (SMIv2) defines fundamental data types, an 16 object model, and the rules for writing and revising MIB modules for 17 use with the SNMP protocol. This document defines a translation of 18 SMIv2 MIB modules into YANG modules, enabling read-only access to 19 data objects defined in SMIv2 MIB modules via NETCONF. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on May 28, 2012. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Mapping of Well Known Types . . . . . . . . . . . . . . . . . 5 69 3. Translation of SMIv2 Modules and SMIv2 IMPORT Clauses . . . . 6 70 3.1. Example: IMPORTS of IF-MIB . . . . . . . . . . . . . . . . 7 71 4. Translation of the MODULE-IDENTITY Macro . . . . . . . . . . . 8 72 4.1. MODULE-IDENTITY Translation Rules . . . . . . . . . . . . 8 73 4.2. Example: MODULE-IDENTITY of IF-MIB . . . . . . . . . . . . 9 74 5. Translation of the TEXTUAL-CONVENTION Macro . . . . . . . . . 10 75 5.1. TEXTUAL-CONVENTION Translation Rules . . . . . . . . . . . 10 76 5.2. Example: OwnerString and InterfaceIndex of IF-MIB . . . . 11 77 5.3. Example: IfDirection of the DIFFSERV-MIB . . . . . . . . . 11 78 6. Translation of OBJECT IDENTIFIER Assignments . . . . . . . . . 13 79 7. Translation of the OBJECT-TYPE Macro . . . . . . . . . . . . . 14 80 7.1. Scalar and Columnar Object Translation Rules . . . . . . . 14 81 7.2. Example: ifNumber and ifIndex of the IF-MIB . . . . . . . 15 82 7.3. Non-Augmenting Conceptual Table Translation Rules . . . . 16 83 7.4. Example: ifTable of the IF-MIB . . . . . . . . . . . . . . 18 84 7.5. Example: ifRcvAddressTable of the IF-MIB . . . . . . . . . 18 85 7.6. Example: alHostTable of the RMON2-MIB . . . . . . . . . . 20 86 7.7. Augmenting Conceptual Tables Translation Rules . . . . . . 21 87 7.8. Example: ifXTable of the IF-MIB . . . . . . . . . . . . . 22 88 8. Translation of the OBJECT-IDENTITY Macro . . . . . . . . . . . 24 89 8.1. OBJECT-IDENTITY Translation Rules . . . . . . . . . . . . 24 90 8.2. Example: diffServTBParamSimpleTokenBucket of the 91 DIFFSERV-MIB . . . . . . . . . . . . . . . . . . . . . . . 24 92 9. Translation of the NOTIFICATION-TYPE Macro . . . . . . . . . . 25 93 9.1. NOTIFICATION-TYPE Translation Rules . . . . . . . . . . . 25 94 9.2. Example: linkDown NOTIFICATION-TYPE of IF-MIB . . . . . . 25 95 10. YANG Language Extension Definition . . . . . . . . . . . . . . 28 96 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 97 12. Security Considerations . . . . . . . . . . . . . . . . . . . 33 98 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 99 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 100 14.1. Normative References . . . . . . . . . . . . . . . . . . . 35 101 14.2. Informative References . . . . . . . . . . . . . . . . . . 35 102 Appendix A. Mapping of Well Known Types (normative) . . . . . . . 37 103 Appendix B. Module Prefix Generation (informative) . . . . . . . 40 104 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 41 106 1. Introduction 108 This document describes a translation of SMIv2 [RFC2578], [RFC2579], 109 [RFC2580] MIB modules into YANG [RFC6020] modules, enabling read-only 110 access to data objects defined in SMIv2 MIB modules via NETCONF. The 111 mapping is illustrated by examples showing the translation of part of 112 the IF-MIB [RFC2863] SMIv2 module and the DIFFSERV-MIB [RFC3289] 113 SMIv2 module. 115 SMIv1 modules may be converted to YANG by first following the rules 116 in [RFC3584] to convert the SMIv1 module to SMIv2, then following the 117 rules in this document to convert to YANG. 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 121 "OPTIONAL" in this document are to be interpreted as described in BCP 122 14, [RFC2119]. 124 2. Mapping of Well Known Types 126 The SMIv2 base types and some well known derived textual-conventions 127 are mapped to YANG types according to Appendix A. The mapping of the 128 OCTET STRING depends on the context. If an OCTET STRING type has an 129 associated DISPLAY-HINT, then the corresponding YANG base type is the 130 string type. Otherwise, the binary type is used. Similarly, the 131 mapping of the INTEGER type depends on its usage as an enumeration or 132 a 32-bit integral type. Implementations are encouraged to provide 133 options to handle situations where DISPLAY-HINTs are added during a 134 revision of a module and backwards compatibility must be preserved. 136 The mappings shown in Appendix A may impact the imports of the 137 generated YANG module since some SMIv2 types and textual-conventions 138 map to YANG types defined in the ietf-yang-types and ietf-inet-types 139 YANG modules [RFC6021]. Implementations MUST add any additional 140 imports required by the type mapping. 142 3. Translation of SMIv2 Modules and SMIv2 IMPORT Clauses 144 SMIv2 modules are mapped to corresponding YANG modules. The YANG 145 module name MUST be the same as the SMIv2 module name. 147 The YANG namespace MUST be constructed out of a constant prefix 148 followed by the SMIv2 module name. Since SMIv2 module names can be 149 assumed to be unique (see Section 3 in [RFC2578]), the resulting YANG 150 namespace is unique. The registered prefix is 151 urn:ietf:params:xml:ns:yang:smiv2:, see the IANA considerations in 152 Section 11. 154 The YANG prefix MAY be derived from the SMIv2 module name using the 155 module prefix generation algorithm described in Appendix B. The YANG 156 prefix is supposed to be short and it must be unique within the set 157 of all prefixes used by a YANG module. The algorithm described in 158 Appendix B generates such prefixes. 160 SMIv2 IMPORT clauses are translated to YANG import statements. One 161 major difference between the SMIv2 import mechanism and the YANG 162 import mechanism is that SMIv2 IMPORT clauses import specific symbols 163 from an SMIv2 module while the YANG import statement imports all 164 symbols of the referenced YANG module. 166 In order to produce correct and complete YANG import statements, the 167 following rules MUST be used: 169 o Process each item in each SMIv2 IMPORT clause as follows: 171 1. If an import statement for this SMIv2 module has already been 172 generated, then ignore this item. 174 2. Otherwise, if the SMIv2 module name is SNMPv2-SMI or SNMPv2- 175 CONF, then ignore this item. Note that these two modules can 176 be completely ignored since all definitions in these modules 177 are translated by translation rules. 179 3. Otherwise, if this item is a textual convention matching one 180 of the textual conventions in the SMIv2 types column of 181 Appendix A (e.g., MacAddress, PhysAddress, or TimeStamp) then 182 ignore this item. 184 4. Otherwise, if the item is used in a SYNTAX clause of an 185 OBJECT-TYPE whose MAX-ACCESS is not accessible-for-notify, 186 then generate an import statement as described below. 188 5. Otherwise, if the item is used in an OBJECTS clause of a 189 NOTIFICATION-TYPE, then generate an import statement as 190 described below. 192 6. Otherwise, if the item is used in an INDEX or AUGMENTS clause, 193 then generate an import statement as described below. 195 7. Otherwise, ignore this item. Some examples of this case are 196 OBJECT IDENTIFIER assignments and objects that are only 197 referenced in MODULE-COMPLIANCE, OBJECT-GROUP, or 198 NOTIFICATION-GROUP clauses. 200 o Generate any additional import statements as required by the type 201 translations according to the type mapping table Appendix A. This 202 requires the translator to consider all the types used in the 203 SMIv2 module in order to produce the imports. 205 o Generate an import statement for the yang module ietf-yang-smiv2 206 with the prefix smiv2 if extensions from ietf-yang-smiv2 will be 207 used in the translated yang module. 209 The generated import statements use the untranslated SMIv2 module 210 names or the names of well-known YANG modules as their argument. The 211 import statement must contain a prefix statement. The prefixes MAY 212 be generated by applying the module prefix generation algorithm 213 described in Appendix B. 215 3.1. Example: IMPORTS of IF-MIB 217 The translation of the IF-MIB [RFC2863] leads to the YANG module and 218 namespace/prefix statement and the import statements shown below. 219 The prefix is the translation of the SMIv2 module name IF-MIB to 220 lowercase (consisting of two tokens and thus no further 221 abbreviation). 223 module IF-MIB { 225 namespace "urn:ietf:params:xml:ns:yang:smiv2:IF-MIB"; 226 prefix "if-mib"; 228 import IANAifType-MIB { prefix "ianaiftype-mib"; } 229 import SNMPv2-TC { prefix "smiv2-tc"; } 230 import ietf-yang-types { prefix "yang"; } 231 import ietf-yang-smiv2 { prefix "smiv2"; } 232 } 234 4. Translation of the MODULE-IDENTITY Macro 236 The SMIv2 requires an invocation of the MODULE-IDENTITY macro to 237 provide contact and revision history for a MIB module. The clauses 238 of the SMIv2 MODULE-IDENTITY macro MUST be translated into YANG 239 statements as detailed below. 241 4.1. MODULE-IDENTITY Translation Rules 243 o The SMIv2 ORGANIZATION clause is mapped to the YANG organization 244 statement. 246 o The SMIv2 CONTACT-INFO clause is mapped to the YANG contact 247 statement. 249 o The SMIv2 DESCRIPTION clause is mapped to the YANG description 250 statement. 252 o Each SMIv2 REVISION clause is mapped to a YANG revision statement. 253 The revision is identified by the date argument of the SMIv2 254 REVISION clause. DESCRIPTION sub-clauses of REVISION clauses are 255 mapped to corresponding description statement nested in revision 256 clauses. 258 o The SMIv2 LAST-UPDATED clause is ignored if the associated date 259 matches a REVISION clause. Otherwise, an additional revision 260 statement is generated. 262 o The name of the SMIv2 module is used to generate a top-level 263 container statement. This container MUST be config false. 265 o The object identifier value of the invocation of the SMIv2 MODULE- 266 IDENTITY is translated into an smiv2:oid statement contained in 267 the container representing the MODULE-IDENTITY macro invocation. 268 Refer to the YANG extension defined in Section 10. 270 While all proper SMIv2 modules must have exactly one MODULE-IDENTITY 271 macro invocation, there are a few notable exceptions. The modules 272 defining the SMIv2 language (i.e., the SNMPv2-SMI, SNMPv2-TC, and 273 SNMPv2-CONF modules) do not invoke the MODULE-IDENTITY macro. 274 Furthermore, SMIv2 modules generated from SMIv1 modules may miss an 275 invocation of the MODULE-IDENTITY macro as well. In such cases, it 276 is preferable to not generate organization, contact, description, and 277 revision statements. 279 4.2. Example: MODULE-IDENTITY of IF-MIB 281 The translation of the MODULE-IDENTITY of the IF-MIB [RFC2863] leads 282 to the following YANG statements: 284 organization 285 "IETF Interfaces MIB Working Group"; 287 contact 288 "Keith McCloghrie 289 Cisco Systems, Inc. 290 170 West Tasman Drive 291 San Jose, CA 95134-1706 292 US 294 408-526-5260 295 kzm@cisco.com"; 297 description 298 "The MIB module to describe generic objects for network 299 interface sub-layers. This MIB is an updated version of 300 MIB-II's ifTable, and incorporates the extensions defined in 301 RFC 1229."; 303 revision "2000-06-14" { 304 description 305 "Clarifications agreed upon by the Interfaces MIB WG, and 306 published as RFC 2863."; 307 } 308 revision "1996-02-28" { 309 description 310 "Revisions made by the Interfaces MIB WG, and published in 311 RFC 2233."; 312 } 313 revision "1993-11-08" { 314 description 315 "Initial revision, published as part of RFC 1573."; 316 } 318 container IF-MIB { 319 config false; 320 } 322 5. Translation of the TEXTUAL-CONVENTION Macro 324 The SMIv2 uses invocations of the TEXTUAL-CONVENTION macro to define 325 new types derived from the SMIv2 base types. Invocations of the 326 TEXTUAL-CONVENTION macro MUST be translated into YANG typedef 327 statements as detailed below. 329 5.1. TEXTUAL-CONVENTION Translation Rules 331 The name of the TEXTUAL-CONVENTION macro invocation is used as the 332 name of the generated typedef statement. The clauses of the SMIv2 333 TEXTUAL-CONVENTION macro are mapped to YANG statements embedded in 334 the typedef statement as follows: 336 o The SMIv2 DISPLAY-HINT clause is used to determine the type 337 mapping of types derived form the OCTET STRING type as explained 338 in Section 2. Furthermore, the DISPLAY-HINT value MAY be used to 339 generate a regular expression for the YANG pattern statement 340 within the type statement. 342 o The SMIv2 DISPLAY-HINT is translated into an smiv2:display-hint 343 statement. Refer to the YANG extension defined in Section 10. 345 o The SMIv2 STATUS clause is mapped to the YANG status statement. 346 The generation of the YANG status statement is skipped if the 347 value of the STATUS clause is current. 349 o The SMIv2 DESCRIPTION clause is mapped to the YANG description 350 statement. 352 o The SMIv2 REFERENCE clause is mapped to the YANG reference 353 statement. 355 o The SMIv2 SYNTAX clause is mapped to the YANG type statement. 356 SMIv2 range restrictions are mapped to YANG range statements while 357 SMIv2 length restrictions are mapped to YANG length statements. 358 SMIv2 INTEGER enumerations are mapped to YANG enum/value 359 statements. SMIv2 BITS are mapped to YANG bit/position 360 statements. 362 This translation assumes that labels of named numbers and named bits 363 do not change when an SMIv2 module is revised. This is consistent 364 with the clarification of the SMIv2 module revision rules in Section 365 4.9 of [RFC4181]. 367 5.2. Example: OwnerString and InterfaceIndex of IF-MIB 369 The translation of the OwnerString and InterfaceIndex textual- 370 conventions of the IF-MIB [RFC2863] are shown below. 372 typedef OwnerString { 373 type string { 374 length "0..255"; 375 pattern '\p{IsBasicLatin}{0,255}'; 376 } 377 status deprecated; 378 description 379 "This data type is used to model an administratively 380 assigned name of the owner of a resource. This information 381 is taken from the NVT ASCII character set. It is suggested 382 that this name contain one or more of the following: ASCII 383 form of the manager station's transport address, management 384 station name (e.g., domain name), network management 385 personnel's name, location, or phone number. In some cases 386 the agent itself will be the owner of an entry. In these 387 cases, this string shall be set to a string starting with 388 'agent'."; 389 smiv2:display-hint "255a"; 390 } 392 typedef InterfaceIndex { 393 type int32 { 394 range "1..2147483647"; 395 } 396 description 397 "A unique value, greater than zero, for each interface or 398 interface sub-layer in the managed system. It is 399 recommended that values are assigned contiguously starting 400 from 1. The value for each interface sub-layer must remain 401 constant at least from one re-initialization of the entity's 402 network management system to the next re-initialization."; 403 smiv2:display-hint "d"; 404 } 406 5.3. Example: IfDirection of the DIFFSERV-MIB 408 The translation of the IfDirection textual-convention of the 409 DIFFSERV-MIB [RFC3289] is shown below. 411 typedef IfDirection { 412 type enumeration { 413 enum inbound { value 1; } 414 enum outbound { value 2; } 415 } 416 description 417 "IfDirection specifies a direction of data travel on an 418 interface. 'inbound' traffic is operated on during reception from 419 the interface, while 'outbound' traffic is operated on prior to 420 transmission on the interface."; 421 } 423 6. Translation of OBJECT IDENTIFIER Assignments 425 The SMIv2 uses OBJECT IDENTIFIER assignments to introduce names for 426 intermediate nodes in the OBJECT IDENTIFIER tree. OBJECT IDENTIFIER 427 assignments are translated into smiv2:alias statements. Refer to the 428 YANG extension defined in Section 10. 430 7. Translation of the OBJECT-TYPE Macro 432 The SMIv2 uses the OBJECT-TYPE macro to define objects and the 433 structure of conceptual tables. Objects exist either as scalars 434 (exactly one instance within an SNMP context) or columnar objects 435 within conceptual tables (zero or multiple instances within an SNMP 436 context). A number of auxiliary objects define the index (key) of a 437 conceptual table. Furthermore, conceptual tables can be augmented by 438 other conceptual tables. All these differences must be taken into 439 account when translating SMIv2 OBJECT-TYPE macro invocations to YANG. 440 Invocations of the OBJECT-TYPE macro MUST be translated into YANG 441 statements as detailed below. 443 7.1. Scalar and Columnar Object Translation Rules 445 SMIv2 OBJECT-TYPE macro invocations defining scalars or columnar 446 objects with a MAX-ACCESS of "not-accessible", "read-only", 447 "read-write" and "read-create" are translated to YANG leaf 448 statements. Additionally, columnar objects with a MAX-ACCESS of 449 accessible-for-notify are translated to YANG leaf statements if that 450 columnar object is part of the INDEX clause of the table containing 451 that columnar object. The name of the leaf is the name associated 452 with the SMIv2 OBJECT-TYPE macro invocation. SMIv2 OBJECT-TYPE macro 453 invocations with a MAX-ACCESS of "accessible-for-notify" are not 454 translated to YANG data tree leafs but instead into YANG notification 455 leafs. 457 Leaf statements for scalar objects are created in a container 458 representing the scalar's parent node in the OID tree. This 459 container is is named after the scalar's parent node in the OID tree 460 and placed in the top-level container representing the SMIv2 module, 461 see Section 4.1. In the rare case that the scalar's parent node has 462 multiple names, the automatic translation MUST fail with an error and 463 the name clash needs to be investigated and fixed manually. The leaf 464 statements representing columnar objects are created in the list 465 representing a conceptual row, see Section 7.3. 467 o The SMIv2 SYNTAX clause is mapped to the YANG type statement. 468 SMIv2 range restrictions are mapped to YANG range statements while 469 SMIv2 length restrictions are mapped to YANG length statements. 470 SMIv2 INTEGER enumerations are mapped to YANG enum/value 471 statements. SMIv2 BITS are mapped to YANG bit/position 472 statements. 474 o The SMIv2 UNITS clause is mapped to the YANG units statement. 476 o The SMIv2 MAX-ACCESS is translated into an smiv2:max-access 477 statement. Refer to the YANG extension defined in Section 10. 479 o The SMIv2 STATUS clause is mapped to the YANG status statement. 480 The generation of the YANG status statement is skipped if the 481 value of the STATUS clause is current. 483 o The SMIv2 DESCRIPTION clause is mapped to the YANG description 484 statement. 486 o The SMIv2 REFERENCE clause is mapped to the YANG reference 487 statement. 489 o The SMIv2 DEFVAL clause is mapped to an smiv2:defval statement. 490 Refer to the YANG extension defined in Section 10. 492 o The value of the SMIv2 OBJECT-TYPE macro invocation is translated 493 into an smiv2:oid statement. Refer to the YANG extension defined 494 in Section 10. 496 This translation assumes that labels of named numbers and named bits 497 do not change when an SMIv2 module is revised. This is consistent 498 with the clarification of the SMIv2 module revision rules in Section 499 4.9 of [RFC4181]. 501 7.2. Example: ifNumber and ifIndex of the IF-MIB 503 The translations of the ifNumber scalar object and the ifIndex 504 columnar object of the IF-MIB [RFC2863] are shown below. Since 505 ifNumber is a scalar object in the interfaces branch of the IF-MIB, 506 the YANG leaf ifNumber will be placed in a YANG container called 507 interfaces, which is registered in the top-level container IF-MIB. 509 leaf ifNumber { 510 type int32; 511 description 512 "The number of network interfaces (regardless of their 513 current state) present on this system."; 514 smiv2:max-access "read-only"; 515 smiv2:oid "1.3.6.1.2.1.2.1"; 516 } 518 leaf ifIndex { 519 type if-mib:InterfaceIndex; 520 description 521 "A unique value, greater than zero, for each interface. It 522 is recommended that values are assigned contiguously 523 starting from 1. The value for each interface sub-layer 524 must remain constant at least from one re-initialization of 525 the entity's network management system to the next re- 526 initialization."; 527 smiv2:max-access "read-only"; 528 smiv2:oid "1.3.6.1.2.1.2.2.1.1"; 529 } 531 7.3. Non-Augmenting Conceptual Table Translation Rules 533 An OBJECT-TYPE macro invocation defining a non-augmenting conceptual 534 table is translated to a YANG container statement using the name of 535 the OBJECT-TYPE macro invocation. This container is created in the 536 top-level container representing the SMIv2 module. The clauses of 537 the macro are translated as follows: 539 o The SMIv2 SYNTAX clause is ignored 541 o The SMIv2 UNITS clause is ignored. 543 o The SMIv2 MAX-ACCESS clause is ignored. 545 o The SMIv2 STATUS clause is mapped to the YANG status statement. 546 The generation of the YANG status statement is skipped if the 547 value of the STATUS clause is current. 549 o The SMIv2 DESCRIPTION clause is mapped to the YANG description 550 statement. 552 o The SMIv2 REFERENCE clause is mapped to the YANG reference 553 statement. 555 o The value of the SMIv2 OBJECT-TYPE macro invocation is translated 556 into an smiv2:oid statement. Refer to the YANG extension defined 557 in Section 10. 559 An OBJECT-TYPE macro invocation defining a conceptual row is 560 translated to a YANG list statement. It is contained in the YANG 561 container representing the conceptual table. The generated list uses 562 the name of the row OBJECT-TYPE macro invocation. The clauses of the 563 OBJECT-TYPE macro are translated as follows: 565 o The SMIv2 SYNTAX clause is ignored. 567 o The SMIv2 UNITS clause is ignored. 569 o The SMIv2 MAX-ACCESS clause is ignored. 571 o The SMIv2 STATUS clause is mapped to the YANG status statement. 572 The generation of the YANG status statement is skipped if the 573 value of the STATUS clause is current. 575 o The SMIv2 DESCRIPTION clause is mapped to the YANG description 576 statement. 578 o The SMIv2 REFERENCE clause is mapped to the YANG reference 579 statement. 581 o The SMIv2 INDEX clause is mapped to the YANG key clause listing 582 the columnar objects forming the key of the YANG list. If the 583 same object appears more than once in the INDEX clause, append 584 '_' to the duplicate object name(s) where '' counts the 585 occurances of the object in the INDEX clause, starting from 2. 586 Additional leaf statements must be created to define the leafs 587 introduced. 589 o If the SMIv2 INDEX clause contains the IMPLIED keyword, then an 590 smiv2:implied statement is generated to record the name of the 591 object preceded by the IMPLIED keyword. Refer to the YANG 592 extension defined in Section 10. 594 o The value of the SMIv2 OBJECT-TYPE macro invocation is translated 595 into an smiv2:oid statement. Refer to the YANG extension defined 596 in Section 10. 598 Within the list statement, YANG leaf statements are created for 599 columnar objects as described in Section 7.1. For objects listed in 600 the SMIv2 INDEX clause that are not part of the conceptual table 601 itself, YANG leaf statements of type leafref pointing to the 602 referenced definition are created. 604 7.4. Example: ifTable of the IF-MIB 606 The translation of the definition of the ifTable of the IF-MIB 607 [RFC2863] is shown below. 609 container ifTable { 610 description 611 "A list of interface entries. The number of entries is 612 given by the value of ifNumber."; 613 smiv2:oid "1.3.6.1.2.1.2.2"; 615 list ifEntry { 616 key "ifIndex"; 617 description 618 "An entry containing management information applicable to a 619 particular interface."; 620 smiv2:oid "1.3.6.1.2.1.2.2.1"; 622 leaf ifIndex { 623 type if-mib:InterfaceIndex; 624 description 625 "A unique value, greater than zero, for each interface. It 626 is recommended that values are assigned contiguously 627 starting from 1. The value for each interface sub-layer 628 must remain constant at least from one re-initialization of 629 the entity's network management system to the next re- 630 initialization."; 631 smiv2:max-access "read-only"; 632 smiv2:oid "1.3.6.1.2.1.2.2.1.1"; 633 } 635 // ... 636 } 637 } 639 7.5. Example: ifRcvAddressTable of the IF-MIB 641 The translation of the definition of the ifRcvAddressTable of the IF- 642 MIB [RFC2863] is shown below. 644 container ifRcvAddressTable { 645 description 646 "This table contains an entry for each address (broadcast, 647 multicast, or uni-cast) for which the system will receive 648 packets/frames on a particular interface, except as follows: 650 - for an interface operating in promiscuous mode, entries 651 are only required for those addresses for which the system 652 would receive frames were it not operating in promiscuous 653 mode. 655 - for 802.5 functional addresses, only one entry is 656 required, for the address which has the functional address 657 bit ANDed with the bit mask of all functional addresses for 658 which the interface will accept frames. 660 A system is normally able to use any unicast address which 661 corresponds to an entry in this table as a source address."; 662 smiv2:oid "1.3.6.1.2.1.31.1.4"; 664 list ifRcvAddressEntry { 665 key "ifIndex ifRcvAddressAddress"; 666 description 667 "A list of objects identifying an address for which the 668 system will accept packets/frames on the particular 669 interface identified by the index value ifIndex."; 670 smiv2:oid "1.3.6.1.2.1.31.1.4.1"; 672 leaf ifIndex { 673 type leafref { 674 path "/if-mib:IF-MIB/if-mib:ifTable" + 675 "/if-mib:ifEntry/if-mib:ifIndex"; 676 } 677 } 679 leaf ifRcvAddressAddress { 680 type yang:phys-address; 681 description 682 "An address for which the system will accept packets/frames 683 on this entry's interface."; 684 smiv2:max-access "not-accessible"; 685 smiv2:oid "1.3.6.1.2.1.31.1.4.1.1"; 686 } 688 // ... 689 } 690 } 692 7.6. Example: alHostTable of the RMON2-MIB 694 The translation of the definition of the alHostTable of the RMON2-MIB 695 [RFC4502] is shown below. 697 container alHostTable { 698 description 699 "A collection of statistics for a particular protocol from a 700 particular network address that has been discovered on an 701 interface of this device. 703 The probe will populate this table for all protocols in the 704 protocol directory table whose value of 705 protocolDirHostConfig is equal to supportedOn(3), and 706 will delete any entries whose protocolDirEntry is deleted or 707 has a protocolDirHostConfig value of supportedOff(2). 709 The probe will add to this table all addresses 710 seen as the source or destination address in all packets with 711 no MAC errors and will increment octet and packet counts in 712 the table for all packets with no MAC errors. Further, 713 entries will only be added to this table if their address 714 exists in the nlHostTable and will be deleted from this table 715 if their address is deleted from the nlHostTable."; 716 smiv2:oid "1.3.6.1.2.1.16.16.1"; 718 list alHostEntry { 719 key "hlHostControlIndex alHostTimeMark protocolDirLocalIndex " 720 "nlHostAddress protocolDirLocalIndex_2"; 721 description 722 "A conceptual row in the alHostTable. 724 The hlHostControlIndex value in the index identifies the 725 hlHostControlEntry on whose behalf this entry was created. 726 The first protocolDirLocalIndex value in the index identifies 727 the network-layer protocol of the address. 728 The nlHostAddress value in the index identifies the network- 729 layer address of this entry. 730 The second protocolDirLocalIndex value in the index identifies 731 the protocol that is counted by this entry. 733 An example of the indexing in this entry is 734 alHostOutPkts.1.783495.18.4.128.2.6.6.34. 736 Note that some combinations of index values may result in an 737 index that exceeds 128 sub-identifiers in length, which exceeds 738 the maximum for the SNMP protocol. Implementations should take 739 care to avoid such combinations."; 741 smiv2:oid "1.3.6.1.2.1.16.16.1.1"; 743 // ... 745 leaf protocolDirLocalIndex { 746 type leafref { 747 path "/rmon2-mib:RMON2-MIB/" 748 "rmon2-mib:protocolDirTable/" 749 "rmon2-mib:"protocolDirEntryf/" 750 "rmon2-mib:protocolDirLocalIndex"; 751 } 752 } 754 // ... 756 leaf protocolDirLocalIndex_2 { 757 type leafref { 758 path "/rmon2-mib:RMON2-MIB/" 759 "rmon2-mib:protocolDirTable/" 760 "rmon2-mib:protocolDirEntry/" 761 "rmon2-mib:protocolDirLocalIndex"; 762 } 763 } 765 // ... 766 } 767 } 769 7.7. Augmenting Conceptual Tables Translation Rules 771 An OBJECT-TYPE macro invocation defining an augmenting conceptual 772 table is translated to a YANG smiv2:alias statement. Refer to the 773 YANG extension defined in Section 10. The clauses of the macro are 774 translated as follows: 776 o The SMIv2 SYNTAX clause is ignored. 778 o The SMIv2 UNITS clause is ignored. 780 o The SMIv2 MAX-ACCESS clause is ignored. 782 o The SMIv2 STATUS clause is mapped to the YANG status statement. 783 The generation of the YANG status statement is skipped if the 784 value of the STATUS clause is current. 786 o The SMIv2 DESCRIPTION clause is mapped to the YANG description 787 statement. 789 o The SMIv2 REFERENCE clause is mapped to the YANG reference 790 statement. 792 o The value of the SMIv2 OBJECT-TYPE macro invocation is translated 793 into an smiv2:oid statement. Refer to the YANG extension defined 794 in Section 10. 796 An OBJECT-TYPE macro invocation defining a conceptual row 797 augmentation is translated to a YANG smiv2:alias statement and a YANG 798 augment statement using the path to the augmented table as its 799 argument. The clauses of the OBJECT-TYPE macro are translated as 800 follows: 802 o The SMIv2 SYNTAX clause is ignored. 804 o The SMIv2 UNITS clause is ignored. 806 o The SMIv2 MAX-ACCESS clause is ignored. 808 o The SMIv2 STATUS clause is mapped to the YANG status statement. 809 The generation of the YANG status statement is skipped if the 810 value of the STATUS clause is current. 812 o The SMIv2 DESCRIPTION clause is mapped to the YANG description 813 statement. 815 o The SMIv2 REFERENCE clause is mapped to the YANG reference 816 statement. 818 o The value of the SMIv2 OBJECT-TYPE macro invocation is translated 819 into an smiv2:oid statement. Refer to the YANG extension defined 820 in Section 10. 822 Within the augment statement, YANG leaf statements are created as 823 described in Section 7.1. 825 7.8. Example: ifXTable of the IF-MIB 827 The translation of the definition of the ifXTable of the IF-MIB 828 [RFC2863] is shown below. 830 smiv2:alias "ifXTable" { 831 description 832 "A list of interface entries. The number of entries is 833 given by the value of ifNumber. This table contains 834 additional objects for the interface table."; 835 smiv2:oid "1.3.6.1.2.1.31.1.1"; 836 } 838 smiv2:alias "ifXEntry" { 839 description 840 "An entry containing additional management information 841 applicable to a particular interface."; 842 smiv2:oid "1.3.6.1.2.1.31.1.1.1"; 843 } 845 augment "/if-mib:IF-MIB/if-mib:ifTable/if-mib:ifEntry" { 846 description 847 "An entry containing additional management information 848 applicable to a particular interface."; 849 smiv2:oid "1.3.6.1.2.1.31.1.1.1"; 851 leaf ifName { 852 type snmpv2-tc:DisplayString; 853 description 854 "The textual name of the interface. The value of this 855 object should be the name of the interface as assigned by 856 the local device and should be suitable for use in commands 857 entered at the device's `console'. This might be a text 858 name, such as `le0' or a simple port number, such as `1', 859 depending on the interface naming syntax of the device. If 860 several entries in the ifTable together represent a single 861 interface as named by the device, then each will have the 862 same value of ifName. Note that for an agent which responds 863 to SNMP queries concerning an interface on some other 864 (proxied) device, then the value of ifName for such an 865 interface is the proxied device's local name for it. 867 If there is no local name, or this object is otherwise not 868 applicable, then this object contains a zero-length string."; 869 smiv2:max-access "read-only"; 870 smiv2:oid "1.3.6.1.2.1.31.1.1.1.1"; 871 } 873 // ... 874 } 876 8. Translation of the OBJECT-IDENTITY Macro 878 The SMIv2 uses invocations of the OBJECT-IDENTITY macro to define 879 information about an OBJECT IDENTIFIER assignment. Invocations of 880 the OBJECT-IDENTITY macro MUST be translated into YANG identity 881 statements as detailed below. 883 8.1. OBJECT-IDENTITY Translation Rules 885 The name of the OBJECT-IDENTITY macro invocation is used as the name 886 of the generated identity statement. The generated identity 887 statement uses the smiv2:object-identity defined in Section 10 as its 888 base. The clauses of the SMIv2 OBJECT-IDENTITY macro are mapped to 889 YANG statements as follows: 891 o The SMIv2 STATUS clause is mapped to the YANG status statement. 892 The generation of the YANG status statement is skipped if the 893 value of the STATUS clause is current. 895 o The SMIv2 DESCRIPTION clause is mapped to the YANG description 896 statement. 898 o The SMIv2 REFERENCE clause is mapped to the YANG reference 899 statement. 901 o The value of the SMIv2 OBJECT-IDENTITY macro invocation is 902 translated into an smiv2:oid statement. Refer to the YANG 903 extension defined in Section 10. 905 8.2. Example: diffServTBParamSimpleTokenBucket of the DIFFSERV-MIB 907 The translation of the diffServTBParamSimpleTokenBucket of the 908 DIFFSERV-MIB [RFC3289] is shown below. 910 identity diffServTBParamSimpleTokenBucket { 911 base "smiv2:object-identity"; 912 description 913 "Two Parameter Token Bucket Meter as described in the Informal 914 Differentiated Services Model section 5.2.3."; 915 smiv2:oid "1.3.6.1.2.1.97.3.1.1"; 916 } 918 9. Translation of the NOTIFICATION-TYPE Macro 920 The SMIv2 provides the NOTIFICATION-TYPE macro to define event 921 notifications. YANG provides the notification statement for the same 922 purpose. Invocations of the NOTIFICATION-TYPE macro MUST be 923 translated into YANG notification statements as detailed below. 925 9.1. NOTIFICATION-TYPE Translation Rules 927 The name of the NOTIFICATION-TYPE macro invocation is used as the 928 name of the generated notification statement. The clauses of the 929 NOTIFICATION-TYPE macro are mapped to YANG statements embedded in the 930 notification statement as follows. 932 o The SMIv2 OBJECTS clause is mapped to a sequence of YANG 933 containers. For each object listed in the OBJECTS clause value, a 934 YANG container statement is generated. The name of this container 935 is the string "object-", where is the position of the 936 object in the value of the OBJECTS clause (first element has 937 position 1). If the current object belongs to a conceptual table, 938 then a sequence of leaf statements is generated for each INDEX 939 object of the conceptual table. These leafs are named after the 940 INDEX objects and of type leafref. Finally, a leaf statement is 941 generated named after the current object. If the current object 942 has a MAX-ACCESS of "read-only", "read-write" or "read-create", 943 then the generated leaf is of type leafref. Otherwise, if the 944 current object has a MAX-ACCESS of "accessible-for-notify", then a 945 leaf is generated, following the itemized steps in Section 7.1. 947 o The SMIv2 STATUS clause is mapped to the YANG status statement. 948 The generation of the YANG status statement is skipped if the 949 value of the STATUS clause is current. 951 o The SMIv2 DESCRIPTION clause is mapped to the YANG description 952 statement. 954 o The SMIv2 REFERENCE clause is mapped to the YANG reference 955 statement. 957 o The value of the SMIv2 NOTIFICATION-TYPE macro invocation is 958 translated into an smiv2:oid statement. Refer to the YANG 959 extension defined in Section 10. 961 9.2. Example: linkDown NOTIFICATION-TYPE of IF-MIB 963 The translation of the linkDown notification of the IF-MIB [RFC2863] 964 is shown below. 966 notification linkDown { 967 description 968 "A linkDown trap signifies that the SNMP entity, acting in 969 an agent role, has detected that the ifOperStatus object for 970 one of its communication links is about to enter the down 971 state from some other state (but not from the notPresent 972 state). This other state is indicated by the included value 973 of ifOperStatus."; 974 smiv2:oid "1.3.6.1.6.3.1.1.5.3"; 976 container object-1 { 977 leaf ifIndex { 978 type leafref { 979 path "/if-mib:IF-MIB/if-mib:ifTable" + 980 "/if-mib:ifEntry/if-mib:ifIndex"; 981 } 982 } 983 } 985 container object-2 { 986 leaf ifIndex { 987 type leafref { 988 path "/if-mib:IF-MIB/if-mib:ifTable" + 989 "/if-mib:ifEntry/if-mib:ifIndex"; 990 } 991 } 992 leaf ifAdminStatus { 993 type leafref { 994 path "/if-mib:IF-MIB/if-mib:ifTable" + 995 "/if-mib:ifEntry/if-mib:ifAdminStatus"; 996 } 997 } 998 } 1000 container object-3 { 1001 leaf ifIndex { 1002 type leafref { 1003 path "/if-mib:IF-MIB/if-mib:ifTable" + 1004 "/if-mib:ifEntry/if-mib:ifIndex"; 1005 } 1006 } 1007 leaf ifOperStatus { 1008 type leafref { 1009 path "/if-mib:IF-MIB/if-mib:ifTable" + 1010 "/if-mib:ifEntry/if-mib:ifOperStatus"; 1011 } 1012 } 1013 } 1015 } 1017 10. YANG Language Extension Definition 1019 This section defines some YANG extension statements that can be used 1020 to capture some information present in SMIv2 modules that is not 1021 translated into core YANG statements. The YANG module references 1022 [RFC2578] and [RFC2579]. 1024 file "ietf-yang-smiv2@2011-11-25.yang" 1026 module ietf-yang-smiv2 { 1028 namespace "urn:ietf:params:xml:ns:yang:ietf-yang-smiv2"; 1029 prefix "smiv2"; 1031 organization 1032 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 1034 contact 1035 "WG Web: 1036 WG List: 1038 WG Chair: David Kessens 1039 1041 WG Chair: Juergen Schoenwaelder 1042 1044 Editor: Juergen Schoenwaelder 1045 "; 1047 description 1048 "This module defines YANG extensions that are used to translate 1049 SMIv2 concepts into YANG. 1051 Copyright (c) 2011 IETF Trust and the persons identified as 1052 authors of the code. All rights reserved. 1054 Redistribution and use in source and binary forms, with or 1055 without modification, is permitted pursuant to, and subject 1056 to the license terms contained in, the Simplified BSD License 1057 set forth in Section 4.c of the IETF Trust's Legal Provisions 1058 Relating to IETF Documents 1059 (http://trustee.ietf.org/license-info). 1061 This version of this YANG module is part of RFC XXXX; see 1062 the RFC itself for full legal notices."; 1063 // RFC Ed.: replace XXXX with actual RFC number and remove this note 1065 // RFC Ed.: please update the date to the date of publication 1066 revision 2011-11-25 { 1067 description 1068 "Initial revision."; 1069 reference 1070 "RFC XXXX: Translation of SMIv2 MIB Modules to YANG Modules"; 1071 // RFC Ed.: replace XXXX with actual RFC number and remove this note 1072 } 1074 identity object-identity { 1075 description 1076 "Base identity for all SMIv2 OBJECT-IDENTITYs."; 1077 } 1079 typedef opaque { 1080 type binary; 1081 description 1082 "The Opaque type supports the capability to pass arbitrary ASN.1 1083 syntax. A value is encoded using the ASN.1 Basic Encoding Rules 1084 into a string of octets. This, in turn, is encoded as an OCTET 1085 STRING, in effect 'double-wrapping' the original ASN.1 value. 1087 In the value set and its semantics, this type is equivalent to 1088 the Opaque type of the SMIv2. This type exists in the SMIv2 1089 solely for backward-compatibility reasons and this is also 1090 true for this YANG data type."; 1091 reference 1092 "RFC 2578: Structure of Management Information Version 2 (SMIv2)"; 1093 } 1095 extension display-hint { 1096 argument "format"; 1097 description 1098 "The display-hint statement takes as an argument the DISPLAY-HINT 1099 assigned to an SMIv2 textual convention."; 1100 reference 1101 "RFC2579: Textual Conventions for SMIv2"; 1102 } 1104 extension max-access { 1105 argument "access"; 1106 description 1107 "The max-access statement takes as an argument the MAX-ACCESS 1108 assigned to an SMIv2 object definition"; 1109 reference 1110 "RFC2578: Structure of Management Information Version 2 (SMIv2)"; 1111 } 1112 extension defval { 1113 argument "value"; 1114 description 1115 "The defval statement takes as an argument a default value 1116 defined by an SMIv2 DEFVAL clause. Note that the value is in 1117 the SMIv2 value space defined by the SMIv2 syntax of the 1118 corresponding object and not in the YANG value space 1119 defined by the corresponding YANG data type."; 1120 reference 1121 "RFC2578: Structure of Management Information Version 2 (SMIv2)"; 1122 } 1124 extension implied { 1125 argument "index"; 1126 description 1127 "If an SMIv2 INDEX object is preceded by the IMPLIED keyword, then 1128 the implied statement is present in the yang module and takes as 1129 an argument the name of the IMPLIED index object."; 1130 reference 1131 "RFC2578: Structure of Management Information Version 2 (SMIv2)"; 1132 } 1134 extension alias { 1135 argument "descriptor"; 1136 description 1137 "The alias statement introduces an SMIv2 descriptor. The body of 1138 the alias statement is expected to contain an oid statement that 1139 provides the numeric OID associated with the descriptor."; 1140 reference 1141 "RFC2578: Structure of Management Information Version 2 (SMIv2)"; 1142 } 1144 extension oid { 1145 argument "value"; 1146 description 1147 "The oid statement takes as an argument the object identifier 1148 assigned to an SMIv2 definition. The object identifier value 1149 is written in decimal dotted notation."; 1150 reference 1151 "RFC2578: Structure of Management Information Version 2 (SMIv2)"; 1152 } 1154 extension subid { 1155 argument "value"; 1156 description 1157 "The subid statement takes as an argument the last sub-identifier 1158 of the object identifier assigned to an SMIv2 definition. The 1159 sub-identifier value is a single positive decimal natural number. 1161 The subid statement may not be used as a substatement to any 1162 top-level node in a YANG document. The subid substatement may 1163 be used only as a substatement to a node having a parent node 1164 defined with either a smiv2:oid or smiv2:subid substatement."; 1165 reference 1166 "RFC2578: Structure of Management Information Version 2 (SMIv2)"; 1167 } 1169 } 1171 1173 11. IANA Considerations 1175 This document registers two URIs in the IETF XML registry [RFC3688]. 1176 Following the format in RFC 3688, the following registrations have 1177 been made. 1179 URI: urn:ietf:params:xml:ns:yang:ietf-yang-smiv2 1181 Registrant Contact: The NETMOD WG of the IETF. 1183 XML: N/A, the requested URI is an XML namespace. 1185 URI: urn:ietf:params:xml:ns:yang:smiv2 1187 Registrant Contact: The NETMOD WG of the IETF. 1189 XML: N/A, the requested URI is an XML namespace. 1191 This document registers a YANG module in the YANG Module Names 1192 registry [RFC6020]. 1194 name: ietf-yang-smiv2 1195 namespace: urn:ietf:params:xml:ns:yang:ietf-yang-smiv2 1196 prefix: smiv2 1197 reference: RFC XXXX 1199 12. Security Considerations 1201 This document defines a translation of SMIv2 MIB modules into YANG 1202 modules, enabling read-only access to data objects defined in SMIv2 1203 MIB modules via NETCONF. The translation itself has no security 1204 impact on the Internet. 1206 Users of translated SMIv2 models that have been published as RFCs 1207 should consult the security considerations of the respective RFCs. 1208 In addition, the security considerations for the NETCONF protocol 1209 [RFC6241] should be consulted to understand how NETCONF protects 1210 potentially sensitive information. 1212 13. Acknowledgements 1214 The editor wishes to thank the following individuals for providing 1215 helpful comments on various versions of this document: Andy Bierman, 1216 Martin Bjorklund, David Reid, and David Spakes. 1218 14. References 1220 14.1. Normative References 1222 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1223 Requirement Levels", BCP 14, RFC 2119, March 1997. 1225 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1226 Schoenwaelder, Ed., "Structure of Management Information 1227 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 1229 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1230 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 1231 STD 58, RFC 2579, April 1999. 1233 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 1234 "Conformance Statements for SMIv2", STD 58, RFC 2580, 1235 April 1999. 1237 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1238 the Network Configuration Protocol (NETCONF)", RFC 6020, 1239 October 2010. 1241 [RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021, 1242 October 2010. 1244 14.2. Informative References 1246 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 1247 MIB", RFC 2863, June 2000. 1249 [RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information 1250 Base for the Differentiated Services Architecture", 1251 RFC 3289, May 2002. 1253 [RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen, 1254 "Coexistence between Version 1, Version 2, and Version 3 1255 of the Internet-standard Network Management Framework", 1256 RFC 3584, August 2003. 1258 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1259 January 2004. 1261 [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB 1262 Documents", BCP 111, RFC 4181, September 2005. 1264 [RFC4502] Waldbusser, S., "Remote Network Monitoring Management 1265 Information Base Version 2", RFC 4502, May 2006. 1267 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1268 and A. Bierman, Ed., "Network Configuration Protocol 1269 (NETCONF)", RFC 6241, June 2011. 1271 Appendix A. Mapping of Well Known Types (normative) 1273 SMIv2 Module: SNMPv2-SMI 1274 SMIv2 Type: INTEGER (used as an enumeration) 1275 Yang Type: enumeration 1277 SMIv2 Module: SNMPv2-SMI 1278 SMIv2 Type: INTEGER (used as a numeric type) 1279 Yang Type: int32 1281 SMIv2 Module: SNMPv2-SMI 1282 SMIv2 Type: Integer32 1283 Yang Type: int32 1285 SMIv2 Module: SNMPv2-SMI 1286 SMIv2 Type: OCTET STRING (used as a binary string) 1287 Yang Type: binary 1289 SMIv2 Module: SNMPv2-SMI 1290 SMIv2 Type: OCTET STRING (used to hold UTF8/ASCII characters) 1291 Yang Type: string 1293 SMIv2 Module: SNMPv2-SMI 1294 SMIv2 Type: OBJECT IDENTIFIER 1295 YANG Module: ietf-yang-types 1296 Yang Type: object-identifier-128 1298 SMIv2 Module: SNMPv2-SMI 1299 SMIv2 Type: BITS 1300 Yang Type: bits 1302 SMIv2 Module: SNMPv2-SMI 1303 SMIv2 Type: IpAddress 1304 YANG Module: ietf-inet-types 1305 Yang Type: ipv4-address 1307 SMIv2 Module: SNMPv2-SMI 1308 SMIv2 Type: Counter32 1309 YANG Module: ietf-yang-types 1310 Yang Type: counter32 1312 SMIv2 Module: SNMPv2-SMI 1313 SMIv2 Type: Gauge32 1314 YANG Module: ietf-yang-types 1315 Yang Type: gauge32 1317 SMIv2 Module: SNMPv2-SMI 1318 SMIv2 Type: TimeTicks 1319 YANG Module: ietf-yang-types 1320 Yang Type: timeticks 1322 SMIv2 Module: SNMPv2-SMI 1323 SMIv2 Type: Counter64 1324 YANG Module: ietf-yang-types 1325 Yang Type: counter64 1327 SMIv2 Module: SNMPv2-SMI 1328 SMIv2 Type: Unsigned32 1329 Yang Type: uint32 1331 SMIv2 Module: SNMPv2-SMI 1332 SMIv2 Type: Opaque 1333 YANG Module: ietf-yang-smiv2 1334 Yang Type: opaque 1336 SMIv2 Module: SNMPv2-TC 1337 SMIv2 Type: PhysAddress 1338 YANG Module: ietf-yang-types 1339 Yang Type: phys-address 1341 SMIv2 Module: SNMPv2-TC 1342 SMIv2 Type: MacAddress 1343 YANG Module: ietf-yang-types 1344 Yang Type: mac-address 1346 SMIv2 Module: SNMPv2-TC 1347 SMIv2 Type: TruthValue 1348 Yang Type: boolean 1350 SMIv2 Module: SNMPv2-TC 1351 SMIv2 Type: TimeStamp 1352 YANG Module: ietf-yang-types 1353 Yang Type: timestamp 1355 SMIv2 Module: RMON2-MIB 1356 SMIv2 Type: ZeroBasedCounter32 1357 YANG Module: ietf-yang-types 1358 Yang Type: zero-based-counter32 1360 SMIv2 Module: HCNUM-TC 1361 SMIv2 Type: ZeroBasedCounter64 1362 YANG Module: ietf-yang-types 1363 Yang Type: zero-based-counter64 1365 SMIv2 Module: HCNUM-TC 1366 SMIv2 Type: CounterBasedGauge64 1367 YANG Module: ietf-yang-types 1368 Yang Type: gauge64 1370 SMIv2 Module: INET-ADDRESS-MIB 1371 SMIv2 Type: InetAutonomousSystemNumber 1372 YANG Module: ietf-inet-types 1373 Yang Type: as-number 1375 SMIv2 Module: INET-ADDRESS-MIB 1376 SMIv2 Type: InetVersion 1377 YANG Module: ietf-inet-types 1378 Yang Type: ip-version 1380 SMIv2 Module: INET-ADDRESS-MIB 1381 SMIv2 Type: InetPortNumber 1382 YANG Module: ietf-inet-types 1383 Yang Type: port-number 1385 SMIv2 Module: DIFFSERV-DSCP-TC 1386 SMIv2 Type: Dscp 1387 YANG Module: ietf-inet-types 1388 Yang Type: dscp 1390 SMIv2 Module: IPV6-FLOW-LABEL-MIB 1391 SMIv2 Type: IPv6FlowLabel 1392 YANG Module: ietf-inet-types 1393 Yang Type: ipv6-flow-label 1395 SMIv2 Module: URI-TC-MIB 1396 SMIv2 Type: Uri 1397 YANG Module: ietf-inet-types 1398 Yang Type: uri 1400 Appendix B. Module Prefix Generation (informative) 1402 This section describes an algorithm to generate module prefixes, to 1403 be used in the import statements. The input of the prefix generation 1404 algorithm is a set of prefixes (usually derived from imported module 1405 names) and a specific module name to be converted into a prefix. The 1406 algorithm described below produces a prefix for the given module name 1407 that is unique within the set of prefixes. 1409 +-----------------+--------+ 1410 | YANG Module | Prefix | 1411 +-----------------+--------+ 1412 | ietf-yang-types | yang | 1413 | ietf-inet-types | inet | 1414 | ietf-yang-smiv2 | smiv2 | 1415 +-----------------+--------+ 1417 Table 1: Special prefixes for well known YANG modules 1419 o First, some predefined translations mapping well known YANG 1420 modules to short prefixes are tried (see Table 1). If a fixed 1421 translation rule exists and leads to a conflict free prefix, then 1422 the fixed translation is used. 1424 o Otherwise, prefixes are generated by tokenizing a YANG module 1425 name, using hyphens as token separators. The tokens derived from 1426 the module name are converted to lowercase characters. The prefix 1427 then becomes the shortest sequence of tokens concatenated using 1428 hyphens as separators, which includes at least two tokens and 1429 which is unique among all prefixes used in the YANG module. 1431 In the worst case, the prefix derived from an SMIv2 module name 1432 becomes the SMIv2 module name translated to lower-case. But on 1433 average, much shorter prefixes are generated. 1435 Author's Address 1437 Juergen Schoenwaelder 1438 Jacobs University 1440 Email: j.schoenwaelder@jacobs-university.de