idnits 2.17.1 draft-ietf-netmod-smi-yang-04.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 date (January 19, 2012) is 4479 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 (~~), 1 warning (==), 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 January 19, 2012 5 Expires: July 22, 2012 7 Translation of SMIv2 MIB Modules to YANG Modules 8 draft-ietf-netmod-smi-yang-04 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 July 22, 2012. 38 Copyright Notice 40 Copyright (c) 2012 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 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Mapping of Well Known Types . . . . . . . . . . . . . . . . . 4 57 3. Translation of SMIv2 Modules and SMIv2 IMPORT Clauses . . . . 5 58 3.1. Example: IMPORTS of IF-MIB . . . . . . . . . . . . . . . . 6 59 4. Translation of the MODULE-IDENTITY Macro . . . . . . . . . . . 7 60 4.1. MODULE-IDENTITY Translation Rules . . . . . . . . . . . . 7 61 4.2. Example: MODULE-IDENTITY of IF-MIB . . . . . . . . . . . . 8 62 5. Translation of the TEXTUAL-CONVENTION Macro . . . . . . . . . 9 63 5.1. TEXTUAL-CONVENTION Translation Rules . . . . . . . . . . . 9 64 5.2. Example: OwnerString and InterfaceIndex of IF-MIB . . . . 10 65 5.3. Example: IfDirection of the DIFFSERV-MIB . . . . . . . . . 10 66 6. Translation of OBJECT IDENTIFIER Assignments . . . . . . . . . 12 67 7. Translation of the OBJECT-TYPE Macro . . . . . . . . . . . . . 13 68 7.1. Scalar and Columnar Object Translation Rules . . . . . . . 13 69 7.2. Example: ifNumber and ifIndex of the IF-MIB . . . . . . . 14 70 7.3. Non-Augmenting Conceptual Table Translation Rules . . . . 15 71 7.4. Example: ifTable of the IF-MIB . . . . . . . . . . . . . . 17 72 7.5. Example: ifRcvAddressTable of the IF-MIB . . . . . . . . . 17 73 7.6. Example: alHostTable of the RMON2-MIB . . . . . . . . . . 19 74 7.7. Augmenting Conceptual Tables Translation Rules . . . . . . 20 75 7.8. Example: ifXTable of the IF-MIB . . . . . . . . . . . . . 21 76 8. Translation of the OBJECT-IDENTITY Macro . . . . . . . . . . . 23 77 8.1. OBJECT-IDENTITY Translation Rules . . . . . . . . . . . . 23 78 8.2. Example: diffServTBParamSimpleTokenBucket of the 79 DIFFSERV-MIB . . . . . . . . . . . . . . . . . . . . . . . 23 80 9. Translation of the NOTIFICATION-TYPE Macro . . . . . . . . . . 24 81 9.1. NOTIFICATION-TYPE Translation Rules . . . . . . . . . . . 24 82 9.2. Example: linkDown NOTIFICATION-TYPE of IF-MIB . . . . . . 24 83 10. YANG Language Extension Definition . . . . . . . . . . . . . . 27 84 11. Implementing Configuration Data Nodes . . . . . . . . . . . . 31 85 11.1. Example: addressMapControlTable of RMON2-MIB . . . . . . . 31 86 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 87 13. Security Considerations . . . . . . . . . . . . . . . . . . . 35 88 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36 89 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 90 15.1. Normative References . . . . . . . . . . . . . . . . . . . 37 91 15.2. Informative References . . . . . . . . . . . . . . . . . . 37 92 Appendix A. Mapping of Well Known Types (normative) . . . . . . . 39 93 Appendix B. Module Prefix Generation (informative) . . . . . . . 42 94 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 43 96 1. Introduction 98 This document describes a translation of SMIv2 [RFC2578], [RFC2579], 99 [RFC2580] MIB modules into YANG [RFC6020] modules, enabling read-only 100 access to data objects defined in SMIv2 MIB modules via NETCONF. The 101 mapping is illustrated by examples showing the translation of parts 102 of the IF-MIB [RFC2863], the DIFFSERV-MIB [RFC3289], and the RMON2- 103 MIB [RFC4502] SMIv2 module. 105 SMIv1 modules may be converted to YANG by first following the rules 106 in [RFC3584] to convert the SMIv1 module to SMIv2, then following the 107 rules in this document to convert to YANG. 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 111 "OPTIONAL" in this document are to be interpreted as described in BCP 112 14, [RFC2119]. 114 2. Mapping of Well Known Types 116 The SMIv2 base types and some well known derived textual conventions 117 are mapped to YANG types according to Appendix A. The mapping of the 118 OCTET STRING depends on the context. If an OCTET STRING type has an 119 associated DISPLAY-HINT, then the corresponding YANG base type is the 120 string type. Otherwise, the binary type is used. Similarly, the 121 mapping of the INTEGER type depends on its usage as an enumeration or 122 a 32-bit integral type. Implementations are encouraged to provide 123 options to handle situations where DISPLAY-HINTs are added during a 124 revision of a module and backwards compatibility must be preserved. 126 The mappings shown in Appendix A may impact the imports of the 127 generated YANG module since some SMIv2 types and textual conventions 128 map to YANG types defined in the ietf-yang-types and ietf-inet-types 129 YANG modules defined in [RFC6021] and the ietf-yang-smiv2 YANG module 130 defined in this document. Implementations MUST add any additional 131 imports required by the type mapping. 133 3. Translation of SMIv2 Modules and SMIv2 IMPORT Clauses 135 SMIv2 modules are mapped to corresponding YANG modules. The YANG 136 module name MUST be the same as the SMIv2 module name. 138 The YANG namespace MUST be constructed out of a constant prefix 139 followed by the SMIv2 module name. Since SMIv2 module names can be 140 assumed to be unique (see Section 3 in [RFC2578]), the resulting YANG 141 namespace is unique. The registered prefix is 142 urn:ietf:params:xml:ns:yang:smiv2:, see the IANA considerations in 143 Section 12. 145 The YANG prefix MAY be derived from the SMIv2 module name using the 146 module prefix generation algorithm described in Appendix B. The YANG 147 prefix is supposed to be short and it must be unique within the set 148 of all prefixes used by a YANG module. The algorithm described in 149 Appendix B generates such prefixes. 151 SMIv2 IMPORT clauses are translated to YANG import statements. One 152 major difference between the SMIv2 import mechanism and the YANG 153 import mechanism is that SMIv2 IMPORT clauses import specific symbols 154 from an SMIv2 module while the YANG import statement imports all 155 symbols of the referenced YANG module. 157 In order to produce correct and complete YANG import statements, the 158 following rules MUST be used: 160 o Process each item in each SMIv2 IMPORT clause as follows: 162 1. If an import statement for this SMIv2 module has already been 163 generated, then ignore this item. 165 2. Otherwise, if the SMIv2 module name is SNMPv2-SMI or SNMPv2- 166 CONF, then ignore this item. Note that these two modules can 167 be completely ignored since all definitions in these modules 168 are translated by translation rules. 170 3. Otherwise, if this item is a textual convention matching one 171 of the textual conventions in the SMIv2 types column of 172 Appendix A (e.g., MacAddress, PhysAddress, or TimeStamp) then 173 ignore this item. 175 4. Otherwise, if the item is used in a SYNTAX clause of an 176 OBJECT-TYPE whose MAX-ACCESS is not accessible-for-notify, 177 then generate an import statement as described below. 179 5. Otherwise, if the item is used in an OBJECTS clause of a 180 NOTIFICATION-TYPE, then generate an import statement as 181 described below. 183 6. Otherwise, if the item is used in an INDEX or AUGMENTS clause, 184 then generate an import statement as described below. 186 7. Otherwise, ignore this item. Some examples of this case are 187 OBJECT IDENTIFIER assignments and objects that are only 188 referenced in MODULE-COMPLIANCE, OBJECT-GROUP, or 189 NOTIFICATION-GROUP clauses. 191 o Generate any additional import statements as required by the type 192 translations according to the type mapping table Appendix A. This 193 requires the translator to consider all the types used in the 194 SMIv2 module in order to produce the imports. 196 o Generate an import statement for the YANG module ietf-yang-smiv2 197 with the prefix smiv2. 199 The generated import statements use the untranslated SMIv2 module 200 names or the names of well-known YANG modules as their argument. The 201 import statement must contain a prefix statement. The prefixes MAY 202 be generated by applying the module prefix generation algorithm 203 described in Appendix B. 205 3.1. Example: IMPORTS of IF-MIB 207 The translation of the IF-MIB [RFC2863] leads to the YANG module and 208 namespace/prefix statement and the import statements shown below. 209 The prefix is the translation of the SMIv2 module name IF-MIB to 210 lowercase (consisting of two tokens and thus no further 211 abbreviation). 213 module IF-MIB { 215 namespace "urn:ietf:params:xml:ns:yang:smiv2:IF-MIB"; 216 prefix "if-mib"; 218 import IANAifType-MIB { prefix "ianaiftype-mib"; } 219 import SNMPv2-TC { prefix "snmpv2-tc"; } 220 import ietf-yang-types { prefix "yang"; } 221 import ietf-yang-smiv2 { prefix "smiv2"; } 222 } 224 4. Translation of the MODULE-IDENTITY Macro 226 The SMIv2 requires an invocation of the MODULE-IDENTITY macro to 227 provide contact and revision history for a MIB module. The clauses 228 of the SMIv2 MODULE-IDENTITY macro MUST be translated into YANG 229 statements as detailed below. 231 4.1. MODULE-IDENTITY Translation Rules 233 o The SMIv2 ORGANIZATION clause is mapped to the YANG organization 234 statement. 236 o The SMIv2 CONTACT-INFO clause is mapped to the YANG contact 237 statement. 239 o The SMIv2 DESCRIPTION clause is mapped to the YANG description 240 statement. 242 o Each SMIv2 REVISION clause is mapped to a YANG revision statement. 243 The revision is identified by the date argument of the SMIv2 244 REVISION clause. DESCRIPTION sub-clauses of REVISION clauses are 245 mapped to corresponding description statement nested in revision 246 clauses. 248 o The SMIv2 LAST-UPDATED clause is ignored if the associated date 249 matches a REVISION clause. Otherwise, an additional revision 250 statement is generated. 252 o A top-level YANG container is generated. The container's name is 253 the SMIv2 module name and the container MUST be config false. The 254 generation of the top-level container MAY be skipped if the SMIv2 255 module does not define any objects that go into the top-level 256 container (e.g., an SMIv2 module only defining textual 257 conventions). 259 o The object identifier value of the invocation of the SMIv2 MODULE- 260 IDENTITY is translated into an smiv2:oid statement contained in an 261 smiv2:alias statement representing the MODULE-IDENTITY macro 262 invocation. Refer to the YANG extension defined in Section 10. 264 While all proper SMIv2 modules must have exactly one MODULE-IDENTITY 265 macro invocation, there are a few notable exceptions. The modules 266 defining the SMIv2 language (i.e., the SNMPv2-SMI, SNMPv2-TC, and 267 SNMPv2-CONF modules) do not invoke the MODULE-IDENTITY macro. 268 Furthermore, SMIv2 modules generated from SMIv1 modules may miss an 269 invocation of the MODULE-IDENTITY macro as well. In such cases, it 270 is preferable to not generate organization, contact, description, and 271 revision statements. 273 4.2. Example: MODULE-IDENTITY of IF-MIB 275 The translation of the MODULE-IDENTITY of the IF-MIB [RFC2863] leads 276 to the following YANG statements: 278 organization 279 "IETF Interfaces MIB Working Group"; 281 contact 282 "Keith McCloghrie 283 Cisco Systems, Inc. 284 170 West Tasman Drive 285 San Jose, CA 95134-1706 286 US 288 408-526-5260 289 kzm@cisco.com"; 291 description 292 "The MIB module to describe generic objects for network 293 interface sub-layers. This MIB is an updated version of 294 MIB-II's ifTable, and incorporates the extensions defined in 295 RFC 1229."; 297 revision "2000-06-14" { 298 description 299 "Clarifications agreed upon by the Interfaces MIB WG, and 300 published as RFC 2863."; 301 } 302 revision "1996-02-28" { 303 description 304 "Revisions made by the Interfaces MIB WG, and published in 305 RFC 2233."; 306 } 307 revision "1993-11-08" { 308 description 309 "Initial revision, published as part of RFC 1573."; 310 } 312 container IF-MIB { 313 config false; 314 } 316 5. Translation of the TEXTUAL-CONVENTION Macro 318 The SMIv2 uses invocations of the TEXTUAL-CONVENTION macro to define 319 new types derived from the SMIv2 base types. Invocations of the 320 TEXTUAL-CONVENTION macro MUST be translated into YANG typedef 321 statements as detailed below. 323 5.1. TEXTUAL-CONVENTION Translation Rules 325 The name of the TEXTUAL-CONVENTION macro invocation is used as the 326 name of the generated typedef statement. The clauses of the SMIv2 327 TEXTUAL-CONVENTION macro are mapped to YANG statements embedded in 328 the typedef statement as follows: 330 o The SMIv2 DISPLAY-HINT clause is used to determine the type 331 mapping of types derived form the OCTET STRING type as explained 332 in Section 2. Furthermore, the DISPLAY-HINT value MAY be used to 333 generate a regular expression for the YANG pattern statement 334 within the type statement. 336 o The SMIv2 DISPLAY-HINT is translated into an smiv2:display-hint 337 statement. Refer to the YANG extension defined in Section 10. 339 o The SMIv2 STATUS clause is mapped to the YANG status statement. 340 The generation of the YANG status statement is skipped if the 341 value of the STATUS clause is current. 343 o The SMIv2 DESCRIPTION clause is mapped to the YANG description 344 statement. 346 o The SMIv2 REFERENCE clause is mapped to the YANG reference 347 statement. 349 o The SMIv2 SYNTAX clause is mapped to the YANG type statement. 350 SMIv2 range restrictions are mapped to YANG range statements while 351 SMIv2 length restrictions are mapped to YANG length statements. 352 SMIv2 INTEGER enumerations are mapped to YANG enum/value 353 statements. SMIv2 BITS are mapped to YANG bit/position 354 statements. 356 This translation assumes that labels of named numbers and named bits 357 do not change when an SMIv2 module is revised. This is consistent 358 with the clarification of the SMIv2 module revision rules in Section 359 4.9 of [RFC4181]. 361 5.2. Example: OwnerString and InterfaceIndex of IF-MIB 363 The translation of the OwnerString and InterfaceIndex textual 364 conventions of the IF-MIB [RFC2863] are shown below. 366 typedef OwnerString { 367 type string { 368 length "0..255"; 369 pattern '\p{IsBasicLatin}{0,255}'; 370 } 371 status deprecated; 372 description 373 "This data type is used to model an administratively 374 assigned name of the owner of a resource. This information 375 is taken from the NVT ASCII character set. It is suggested 376 that this name contain one or more of the following: ASCII 377 form of the manager station's transport address, management 378 station name (e.g., domain name), network management 379 personnel's name, location, or phone number. In some cases 380 the agent itself will be the owner of an entry. In these 381 cases, this string shall be set to a string starting with 382 'agent'."; 383 smiv2:display-hint "255a"; 384 } 386 typedef InterfaceIndex { 387 type int32 { 388 range "1..2147483647"; 389 } 390 description 391 "A unique value, greater than zero, for each interface or 392 interface sub-layer in the managed system. It is 393 recommended that values are assigned contiguously starting 394 from 1. The value for each interface sub-layer must remain 395 constant at least from one re-initialization of the entity's 396 network management system to the next re-initialization."; 397 smiv2:display-hint "d"; 398 } 400 5.3. Example: IfDirection of the DIFFSERV-MIB 402 The translation of the IfDirection textual convention of the 403 DIFFSERV-MIB [RFC3289] is shown below. 405 typedef IfDirection { 406 type enumeration { 407 enum inbound { value 1; } 408 enum outbound { value 2; } 409 } 410 description 411 "IfDirection specifies a direction of data travel on an 412 interface. 'inbound' traffic is operated on during reception from 413 the interface, while 'outbound' traffic is operated on prior to 414 transmission on the interface."; 415 } 417 6. Translation of OBJECT IDENTIFIER Assignments 419 The SMIv2 uses OBJECT IDENTIFIER assignments to introduce names for 420 intermediate nodes in the OBJECT IDENTIFIER tree. OBJECT IDENTIFIER 421 assignments are translated into smiv2:alias statements. Refer to the 422 YANG extension defined in Section 10. 424 7. Translation of the OBJECT-TYPE Macro 426 The SMIv2 uses the OBJECT-TYPE macro to define objects and the 427 structure of conceptual tables. Objects exist either as scalars 428 (exactly one instance within an SNMP context) or columnar objects 429 within conceptual tables (zero or multiple instances within an SNMP 430 context). A number of auxiliary objects define the index (key) of a 431 conceptual table. Furthermore, conceptual tables can be augmented by 432 other conceptual tables. All these differences must be taken into 433 account when translating SMIv2 OBJECT-TYPE macro invocations to YANG. 434 Invocations of the OBJECT-TYPE macro MUST be translated into YANG 435 statements as detailed below. 437 7.1. Scalar and Columnar Object Translation Rules 439 SMIv2 OBJECT-TYPE macro invocations defining scalars or columnar 440 objects with a MAX-ACCESS of "not-accessible", "read-only", 441 "read-write" and "read-create" are translated to YANG leaf 442 statements. Additionally, columnar objects with a MAX-ACCESS of 443 accessible-for-notify are translated to YANG leaf statements if that 444 columnar object is part of the INDEX clause of the table containing 445 that columnar object. The name of the leaf is the name associated 446 with the SMIv2 OBJECT-TYPE macro invocation. SMIv2 OBJECT-TYPE macro 447 invocations with a MAX-ACCESS of "accessible-for-notify" are not 448 translated to YANG data tree leafs but instead into YANG notification 449 leafs. 451 Leaf statements for scalar objects are created in a container 452 representing the scalar's parent node in the OID tree. This 453 container is named after the scalar's parent node in the OID tree and 454 placed in the top-level container representing the SMIv2 module, see 455 Section 4.1. In the rare case that the scalar's parent node has 456 multiple names, the automatic translation MUST fail with an error and 457 the name clash needs to be investigated and fixed manually. In case 458 a previous revision of the SMIv2 module did not have an ambiguity, 459 then the name used by the previous revision MUST be used. The leaf 460 statements representing columnar objects are created in the list 461 representing a conceptual row, see Section 7.3. 463 o The SMIv2 SYNTAX clause is mapped to the YANG type statement. 464 SMIv2 range restrictions are mapped to YANG range statements while 465 SMIv2 length restrictions are mapped to YANG length statements. 466 SMIv2 INTEGER enumerations are mapped to YANG enum/value 467 statements. SMIv2 BITS are mapped to YANG bit/position 468 statements. 470 o The SMIv2 UNITS clause is mapped to the YANG units statement. 472 o The SMIv2 MAX-ACCESS is translated into an smiv2:max-access 473 statement. Refer to the YANG extension defined in Section 10. 475 o The SMIv2 STATUS clause is mapped to the YANG status statement. 476 The generation of the YANG status statement is skipped if the 477 value of the STATUS clause is current. 479 o The SMIv2 DESCRIPTION clause is mapped to the YANG description 480 statement. 482 o The SMIv2 REFERENCE clause is mapped to the YANG reference 483 statement. 485 o The SMIv2 DEFVAL clause is mapped to an smiv2:defval statement. 486 Refer to the YANG extension defined in Section 10. 488 o The value of the SMIv2 OBJECT-TYPE macro invocation is translated 489 into an smiv2:oid statement. Refer to the YANG extension defined 490 in Section 10. 492 This translation assumes that labels of named numbers and named bits 493 do not change when an SMIv2 module is revised. This is consistent 494 with the clarification of the SMIv2 module revision rules in Section 495 4.9 of [RFC4181]. 497 7.2. Example: ifNumber and ifIndex of the IF-MIB 499 The translations of the ifNumber scalar object and the ifIndex 500 columnar object of the IF-MIB [RFC2863] are shown below. Since 501 ifNumber is a scalar object in the interfaces branch of the IF-MIB, 502 the YANG leaf ifNumber will be placed in a YANG container called 503 interfaces, which is registered in the top-level container IF-MIB. 505 leaf ifNumber { 506 type int32; 507 description 508 "The number of network interfaces (regardless of their 509 current state) present on this system."; 510 smiv2:max-access "read-only"; 511 smiv2:oid "1.3.6.1.2.1.2.1"; 512 } 514 leaf ifIndex { 515 type if-mib:InterfaceIndex; 516 description 517 "A unique value, greater than zero, for each interface. It 518 is recommended that values are assigned contiguously 519 starting from 1. The value for each interface sub-layer 520 must remain constant at least from one re-initialization of 521 the entity's network management system to the next re- 522 initialization."; 523 smiv2:max-access "read-only"; 524 smiv2:oid "1.3.6.1.2.1.2.2.1.1"; 525 } 527 7.3. Non-Augmenting Conceptual Table Translation Rules 529 An OBJECT-TYPE macro invocation defining a non-augmenting conceptual 530 table is translated to a YANG container statement using the name of 531 the OBJECT-TYPE macro invocation. This container is created in the 532 top-level container representing the SMIv2 module. The clauses of 533 the macro are translated as follows: 535 o The SMIv2 SYNTAX clause is ignored 537 o The SMIv2 UNITS clause is ignored. 539 o The SMIv2 MAX-ACCESS clause is ignored. 541 o The SMIv2 STATUS clause is mapped to the YANG status statement. 542 The generation of the YANG status statement is skipped if the 543 value of the STATUS clause is current. 545 o The SMIv2 DESCRIPTION clause is mapped to the YANG description 546 statement. 548 o The SMIv2 REFERENCE clause is mapped to the YANG reference 549 statement. 551 o The value of the SMIv2 OBJECT-TYPE macro invocation is translated 552 into an smiv2:oid statement. Refer to the YANG extension defined 553 in Section 10. 555 An OBJECT-TYPE macro invocation defining a conceptual row is 556 translated to a YANG list statement. It is contained in the YANG 557 container representing the conceptual table. The generated list uses 558 the name of the row OBJECT-TYPE macro invocation. The clauses of the 559 OBJECT-TYPE macro are translated as follows: 561 o The SMIv2 SYNTAX clause is ignored. 563 o The SMIv2 UNITS clause is ignored. 565 o The SMIv2 MAX-ACCESS clause is ignored. 567 o The SMIv2 STATUS clause is mapped to the YANG status statement. 568 The generation of the YANG status statement is skipped if the 569 value of the STATUS clause is current. 571 o The SMIv2 DESCRIPTION clause is mapped to the YANG description 572 statement. 574 o The SMIv2 REFERENCE clause is mapped to the YANG reference 575 statement. 577 o The SMIv2 INDEX clause is mapped to the YANG key clause listing 578 the columnar objects forming the key of the YANG list. If the 579 same object appears more than once in the INDEX clause, append 580 '_' to the duplicate object name(s) where '' counts the 581 occurances of the object in the INDEX clause, starting from 2. 582 Additional leaf statements must be created to define the leafs 583 introduced. 585 o If the SMIv2 INDEX clause contains the IMPLIED keyword, then an 586 smiv2:implied statement is generated to record the name of the 587 object preceded by the IMPLIED keyword. Refer to the YANG 588 extension defined in Section 10. 590 o The value of the SMIv2 OBJECT-TYPE macro invocation is translated 591 into an smiv2:oid statement. Refer to the YANG extension defined 592 in Section 10. 594 Within the list statement, YANG leaf statements are created for 595 columnar objects as described in Section 7.1. For objects listed in 596 the SMIv2 INDEX clause that are not part of the conceptual table 597 itself, YANG leaf statements of type leafref pointing to the 598 referenced definition are created. 600 7.4. Example: ifTable of the IF-MIB 602 The translation of the definition of the ifTable of the IF-MIB 603 [RFC2863] is shown below. 605 container ifTable { 606 description 607 "A list of interface entries. The number of entries is 608 given by the value of ifNumber."; 609 smiv2:oid "1.3.6.1.2.1.2.2"; 611 list ifEntry { 612 key "ifIndex"; 613 description 614 "An entry containing management information applicable to a 615 particular interface."; 616 smiv2:oid "1.3.6.1.2.1.2.2.1"; 618 leaf ifIndex { 619 type if-mib:InterfaceIndex; 620 description 621 "A unique value, greater than zero, for each interface. It 622 is recommended that values are assigned contiguously 623 starting from 1. The value for each interface sub-layer 624 must remain constant at least from one re-initialization of 625 the entity's network management system to the next re- 626 initialization."; 627 smiv2:max-access "read-only"; 628 smiv2:oid "1.3.6.1.2.1.2.2.1.1"; 629 } 631 // ... 632 } 633 } 635 7.5. Example: ifRcvAddressTable of the IF-MIB 637 The translation of the definition of the ifRcvAddressTable of the IF- 638 MIB [RFC2863] is shown below. 640 container ifRcvAddressTable { 641 description 642 "This table contains an entry for each address (broadcast, 643 multicast, or uni-cast) for which the system will receive 644 packets/frames on a particular interface, except as follows: 646 - for an interface operating in promiscuous mode, entries 647 are only required for those addresses for which the system 648 would receive frames were it not operating in promiscuous 649 mode. 651 - for 802.5 functional addresses, only one entry is 652 required, for the address which has the functional address 653 bit ANDed with the bit mask of all functional addresses for 654 which the interface will accept frames. 656 A system is normally able to use any unicast address which 657 corresponds to an entry in this table as a source address."; 658 smiv2:oid "1.3.6.1.2.1.31.1.4"; 660 list ifRcvAddressEntry { 661 key "ifIndex ifRcvAddressAddress"; 662 description 663 "A list of objects identifying an address for which the 664 system will accept packets/frames on the particular 665 interface identified by the index value ifIndex."; 666 smiv2:oid "1.3.6.1.2.1.31.1.4.1"; 668 leaf ifIndex { 669 type leafref { 670 path "/if-mib:IF-MIB/if-mib:ifTable" + 671 "/if-mib:ifEntry/if-mib:ifIndex"; 672 } 673 } 675 leaf ifRcvAddressAddress { 676 type yang:phys-address; 677 description 678 "An address for which the system will accept packets/frames 679 on this entry's interface."; 680 smiv2:max-access "not-accessible"; 681 smiv2:oid "1.3.6.1.2.1.31.1.4.1.1"; 682 } 684 // ... 685 } 686 } 688 7.6. Example: alHostTable of the RMON2-MIB 690 The translation of the definition of the alHostTable of the RMON2-MIB 691 [RFC4502] is shown below. 693 container alHostTable { 694 description 695 "A collection of statistics for a particular protocol from a 696 particular network address that has been discovered on an 697 interface of this device. 699 The probe will populate this table for all protocols in the 700 protocol directory table whose value of 701 protocolDirHostConfig is equal to supportedOn(3), and 702 will delete any entries whose protocolDirEntry is deleted or 703 has a protocolDirHostConfig value of supportedOff(2). 705 The probe will add to this table all addresses 706 seen as the source or destination address in all packets with 707 no MAC errors and will increment octet and packet counts in 708 the table for all packets with no MAC errors. Further, 709 entries will only be added to this table if their address 710 exists in the nlHostTable and will be deleted from this table 711 if their address is deleted from the nlHostTable."; 712 smiv2:oid "1.3.6.1.2.1.16.16.1"; 714 list alHostEntry { 715 key "hlHostControlIndex alHostTimeMark protocolDirLocalIndex " 716 + "nlHostAddress protocolDirLocalIndex_2"; 717 description 718 "A conceptual row in the alHostTable. 720 The hlHostControlIndex value in the index identifies the 721 hlHostControlEntry on whose behalf this entry was created. 722 The first protocolDirLocalIndex value in the index identifies 723 the network-layer protocol of the address. 724 The nlHostAddress value in the index identifies the network- 725 layer address of this entry. 726 The second protocolDirLocalIndex value in the index identifies 727 the protocol that is counted by this entry. 729 An example of the indexing in this entry is 730 alHostOutPkts.1.783495.18.4.128.2.6.6.34. 732 Note that some combinations of index values may result in an 733 index that exceeds 128 sub-identifiers in length, which exceeds 734 the maximum for the SNMP protocol. Implementations should take 735 care to avoid such combinations."; 737 smiv2:oid "1.3.6.1.2.1.16.16.1.1"; 739 // ... 741 leaf protocolDirLocalIndex { 742 type leafref { 743 path "/rmon2-mib:RMON2-MIB/" 744 + "rmon2-mib:protocolDirTable/" 745 + "rmon2-mib:protocolDirEntryf/" 746 + "rmon2-mib:protocolDirLocalIndex"; 747 } 748 } 750 // ... 752 leaf protocolDirLocalIndex_2 { 753 type leafref { 754 path "/rmon2-mib:RMON2-MIB/" 755 + "rmon2-mib:protocolDirTable/" 756 + "rmon2-mib:protocolDirEntry/" 757 + "rmon2-mib:protocolDirLocalIndex"; 758 } 759 } 761 // ... 762 } 763 } 765 7.7. Augmenting Conceptual Tables Translation Rules 767 An OBJECT-TYPE macro invocation defining an augmenting conceptual 768 table is translated to a YANG smiv2:alias statement. Refer to the 769 YANG extension defined in Section 10. The clauses of the macro are 770 translated as follows: 772 o The SMIv2 SYNTAX clause is ignored. 774 o The SMIv2 UNITS clause is ignored. 776 o The SMIv2 MAX-ACCESS clause is ignored. 778 o The SMIv2 STATUS clause is mapped to the YANG status statement. 779 The generation of the YANG status statement is skipped if the 780 value of the STATUS clause is current. 782 o The SMIv2 DESCRIPTION clause is mapped to the YANG description 783 statement. 785 o The SMIv2 REFERENCE clause is mapped to the YANG reference 786 statement. 788 o The value of the SMIv2 OBJECT-TYPE macro invocation is translated 789 into an smiv2:oid statement. Refer to the YANG extension defined 790 in Section 10. 792 An OBJECT-TYPE macro invocation defining a conceptual row 793 augmentation is translated to a YANG smiv2:alias statement and a YANG 794 augment statement using the path to the augmented table as its 795 argument. The clauses of the OBJECT-TYPE macro are translated as 796 follows: 798 o The SMIv2 SYNTAX clause is ignored. 800 o The SMIv2 UNITS clause is ignored. 802 o The SMIv2 MAX-ACCESS clause is ignored. 804 o The SMIv2 STATUS clause is mapped to the YANG status statement. 805 The generation of the YANG status statement is skipped if the 806 value of the STATUS clause is current. 808 o The SMIv2 DESCRIPTION clause is mapped to the YANG description 809 statement. 811 o The SMIv2 REFERENCE clause is mapped to the YANG reference 812 statement. 814 o The value of the SMIv2 OBJECT-TYPE macro invocation is translated 815 into an smiv2:oid statement. Refer to the YANG extension defined 816 in Section 10. 818 Within the augment statement, YANG leaf statements are created as 819 described in Section 7.1. 821 7.8. Example: ifXTable of the IF-MIB 823 The translation of the definition of the ifXTable of the IF-MIB 824 [RFC2863] is shown below. 826 smiv2:alias "ifXTable" { 827 description 828 "A list of interface entries. The number of entries is 829 given by the value of ifNumber. This table contains 830 additional objects for the interface table."; 831 smiv2:oid "1.3.6.1.2.1.31.1.1"; 832 } 834 smiv2:alias "ifXEntry" { 835 description 836 "An entry containing additional management information 837 applicable to a particular interface."; 838 smiv2:oid "1.3.6.1.2.1.31.1.1.1"; 839 } 841 augment "/if-mib:IF-MIB/if-mib:ifTable/if-mib:ifEntry" { 842 description 843 "An entry containing additional management information 844 applicable to a particular interface."; 845 smiv2:oid "1.3.6.1.2.1.31.1.1.1"; 847 leaf ifName { 848 type snmpv2-tc:DisplayString; 849 description 850 "The textual name of the interface. The value of this 851 object should be the name of the interface as assigned by 852 the local device and should be suitable for use in commands 853 entered at the device's `console'. This might be a text 854 name, such as `le0' or a simple port number, such as `1', 855 depending on the interface naming syntax of the device. If 856 several entries in the ifTable together represent a single 857 interface as named by the device, then each will have the 858 same value of ifName. Note that for an agent which responds 859 to SNMP queries concerning an interface on some other 860 (proxied) device, then the value of ifName for such an 861 interface is the proxied device's local name for it. 863 If there is no local name, or this object is otherwise not 864 applicable, then this object contains a zero-length string."; 865 smiv2:max-access "read-only"; 866 smiv2:oid "1.3.6.1.2.1.31.1.1.1.1"; 867 } 869 // ... 870 } 872 8. Translation of the OBJECT-IDENTITY Macro 874 The SMIv2 uses invocations of the OBJECT-IDENTITY macro to define 875 information about an OBJECT IDENTIFIER assignment. Invocations of 876 the OBJECT-IDENTITY macro MUST be translated into YANG identity 877 statements as detailed below. 879 8.1. OBJECT-IDENTITY Translation Rules 881 The name of the OBJECT-IDENTITY macro invocation is used as the name 882 of the generated identity statement. The generated identity 883 statement uses the smiv2:object-identity defined in Section 10 as its 884 base. The clauses of the SMIv2 OBJECT-IDENTITY macro are mapped to 885 YANG statements as follows: 887 o The SMIv2 STATUS clause is mapped to the YANG status statement. 888 The generation of the YANG status statement is skipped if the 889 value of the STATUS clause is current. 891 o The SMIv2 DESCRIPTION clause is mapped to the YANG description 892 statement. 894 o The SMIv2 REFERENCE clause is mapped to the YANG reference 895 statement. 897 o The value of the SMIv2 OBJECT-IDENTITY macro invocation is 898 translated into an smiv2:oid statement. Refer to the YANG 899 extension defined in Section 10. 901 8.2. Example: diffServTBParamSimpleTokenBucket of the DIFFSERV-MIB 903 The translation of the diffServTBParamSimpleTokenBucket of the 904 DIFFSERV-MIB [RFC3289] is shown below. 906 identity diffServTBParamSimpleTokenBucket { 907 base "smiv2:object-identity"; 908 description 909 "Two Parameter Token Bucket Meter as described in the Informal 910 Differentiated Services Model section 5.2.3."; 911 smiv2:oid "1.3.6.1.2.1.97.3.1.1"; 912 } 914 9. Translation of the NOTIFICATION-TYPE Macro 916 The SMIv2 provides the NOTIFICATION-TYPE macro to define event 917 notifications. YANG provides the notification statement for the same 918 purpose. Invocations of the NOTIFICATION-TYPE macro MUST be 919 translated into YANG notification statements as detailed below. 921 9.1. NOTIFICATION-TYPE Translation Rules 923 The name of the NOTIFICATION-TYPE macro invocation is used as the 924 name of the generated notification statement. The clauses of the 925 NOTIFICATION-TYPE macro are mapped to YANG statements embedded in the 926 notification statement as follows. 928 o The SMIv2 OBJECTS clause is mapped to a sequence of YANG 929 containers. For each object listed in the OBJECTS clause value, a 930 YANG container statement is generated. The name of this container 931 is the string "object-", where is the position of the 932 object in the value of the OBJECTS clause (first element has 933 position 1). If the current object belongs to a conceptual table, 934 then a sequence of leaf statements is generated for each INDEX 935 object of the conceptual table. These leafs are named after the 936 INDEX objects and of type leafref. Finally, a leaf statement is 937 generated named after the current object. If the current object 938 has a MAX-ACCESS of "read-only", "read-write" or "read-create", 939 then the generated leaf is of type leafref. Otherwise, if the 940 current object has a MAX-ACCESS of "accessible-for-notify", then a 941 leaf is generated, following the itemized steps in Section 7.1. 943 o The SMIv2 STATUS clause is mapped to the YANG status statement. 944 The generation of the YANG status statement is skipped if the 945 value of the STATUS clause is current. 947 o The SMIv2 DESCRIPTION clause is mapped to the YANG description 948 statement. 950 o The SMIv2 REFERENCE clause is mapped to the YANG reference 951 statement. 953 o The value of the SMIv2 NOTIFICATION-TYPE macro invocation is 954 translated into an smiv2:oid statement. Refer to the YANG 955 extension defined in Section 10. 957 9.2. Example: linkDown NOTIFICATION-TYPE of IF-MIB 959 The translation of the linkDown notification of the IF-MIB [RFC2863] 960 is shown below. 962 notification linkDown { 963 description 964 "A linkDown trap signifies that the SNMP entity, acting in 965 an agent role, has detected that the ifOperStatus object for 966 one of its communication links is about to enter the down 967 state from some other state (but not from the notPresent 968 state). This other state is indicated by the included value 969 of ifOperStatus."; 970 smiv2:oid "1.3.6.1.6.3.1.1.5.3"; 972 container object-1 { 973 leaf ifIndex { 974 type leafref { 975 path "/if-mib:IF-MIB/if-mib:ifTable" + 976 "/if-mib:ifEntry/if-mib:ifIndex"; 977 } 978 } 979 } 981 container object-2 { 982 leaf ifIndex { 983 type leafref { 984 path "/if-mib:IF-MIB/if-mib:ifTable" + 985 "/if-mib:ifEntry/if-mib:ifIndex"; 986 } 987 } 988 leaf ifAdminStatus { 989 type leafref { 990 path "/if-mib:IF-MIB/if-mib:ifTable" + 991 "/if-mib:ifEntry/if-mib:ifAdminStatus"; 992 } 993 } 994 } 996 container object-3 { 997 leaf ifIndex { 998 type leafref { 999 path "/if-mib:IF-MIB/if-mib:ifTable" + 1000 "/if-mib:ifEntry/if-mib:ifIndex"; 1001 } 1002 } 1003 leaf ifOperStatus { 1004 type leafref { 1005 path "/if-mib:IF-MIB/if-mib:ifTable" + 1006 "/if-mib:ifEntry/if-mib:ifOperStatus"; 1007 } 1008 } 1009 } 1011 } 1013 10. YANG Language Extension Definition 1015 This section defines some YANG extension statements that can be used 1016 to capture some information present in SMIv2 modules that is not 1017 translated into core YANG statements. The YANG module references 1018 [RFC2578] and [RFC2579]. 1020 file "ietf-yang-smiv2@2011-11-25.yang" 1022 module ietf-yang-smiv2 { 1024 namespace "urn:ietf:params:xml:ns:yang:ietf-yang-smiv2"; 1025 prefix "smiv2"; 1027 organization 1028 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 1030 contact 1031 "WG Web: 1032 WG List: 1034 WG Chair: David Kessens 1035 1037 WG Chair: Juergen Schoenwaelder 1038 1040 Editor: Juergen Schoenwaelder 1041 "; 1043 description 1044 "This module defines YANG extensions that are used to translate 1045 SMIv2 concepts into YANG. 1047 Copyright (c) 2011 IETF Trust and the persons identified as 1048 authors of the code. All rights reserved. 1050 Redistribution and use in source and binary forms, with or 1051 without modification, is permitted pursuant to, and subject 1052 to the license terms contained in, the Simplified BSD License 1053 set forth in Section 4.c of the IETF Trust's Legal Provisions 1054 Relating to IETF Documents 1055 (http://trustee.ietf.org/license-info). 1057 This version of this YANG module is part of RFC XXXX; see 1058 the RFC itself for full legal notices."; 1059 // RFC Ed.: replace XXXX with actual RFC number and remove this note 1061 // RFC Ed.: please update the date to the date of publication 1062 revision 2011-11-25 { 1063 description 1064 "Initial revision."; 1065 reference 1066 "RFC XXXX: Translation of SMIv2 MIB Modules to YANG Modules"; 1067 // RFC Ed.: replace XXXX with actual RFC number and remove this note 1068 } 1070 identity object-identity { 1071 description 1072 "Base identity for all SMIv2 OBJECT-IDENTITYs."; 1073 } 1075 typedef opaque { 1076 type binary; 1077 description 1078 "The Opaque type supports the capability to pass arbitrary ASN.1 1079 syntax. A value is encoded using the ASN.1 Basic Encoding Rules 1080 into a string of octets. This, in turn, is encoded as an OCTET 1081 STRING, in effect 'double-wrapping' the original ASN.1 value. 1083 In the value set and its semantics, this type is equivalent to 1084 the Opaque type of the SMIv2. This type exists in the SMIv2 1085 solely for backward-compatibility reasons and this is also 1086 true for this YANG data type."; 1087 reference 1088 "RFC 2578: Structure of Management Information Version 2 (SMIv2)"; 1089 } 1091 extension display-hint { 1092 argument "format"; 1093 description 1094 "The display-hint statement takes as an argument the DISPLAY-HINT 1095 assigned to an SMIv2 textual convention."; 1096 reference 1097 "RFC2579: Textual Conventions for SMIv2"; 1098 } 1100 extension max-access { 1101 argument "access"; 1102 description 1103 "The max-access statement takes as an argument the MAX-ACCESS 1104 assigned to an SMIv2 object definition"; 1105 reference 1106 "RFC2578: Structure of Management Information Version 2 (SMIv2)"; 1107 } 1108 extension defval { 1109 argument "value"; 1110 description 1111 "The defval statement takes as an argument a default value 1112 defined by an SMIv2 DEFVAL clause. Note that the value is in 1113 the SMIv2 value space defined by the SMIv2 syntax of the 1114 corresponding object and not in the YANG value space 1115 defined by the corresponding YANG data type."; 1116 reference 1117 "RFC2578: Structure of Management Information Version 2 (SMIv2)"; 1118 } 1120 extension implied { 1121 argument "index"; 1122 description 1123 "If an SMIv2 INDEX object is preceded by the IMPLIED keyword, then 1124 the implied statement is present in the yang module and takes as 1125 an argument the name of the IMPLIED index object."; 1126 reference 1127 "RFC2578: Structure of Management Information Version 2 (SMIv2)"; 1128 } 1130 extension alias { 1131 argument "descriptor"; 1132 description 1133 "The alias statement introduces an SMIv2 descriptor. The body of 1134 the alias statement is expected to contain an oid statement that 1135 provides the numeric OID associated with the descriptor."; 1136 reference 1137 "RFC2578: Structure of Management Information Version 2 (SMIv2)"; 1138 } 1140 extension oid { 1141 argument "value"; 1142 description 1143 "The oid statement takes as an argument the object identifier 1144 assigned to an SMIv2 definition. The object identifier value 1145 is written in decimal dotted notation."; 1146 reference 1147 "RFC2578: Structure of Management Information Version 2 (SMIv2)"; 1148 } 1150 extension subid { 1151 argument "value"; 1152 description 1153 "The subid statement takes as an argument the last sub-identifier 1154 of the object identifier assigned to an SMIv2 definition. The 1155 sub-identifier value is a single positive decimal natural number. 1157 The subid statement may not be used as a substatement to any 1158 top-level node in a YANG document. The subid substatement may 1159 be used only as a substatement to a node having a parent node 1160 defined with either a smiv2:oid or smiv2:subid substatement."; 1161 reference 1162 "RFC2578: Structure of Management Information Version 2 (SMIv2)"; 1163 } 1165 } 1167 1169 11. Implementing Configuration Data Nodes 1171 The translation of SMIv2 MIB modules into YANG modules defined above 1172 is read-only. One reason is that the persistency models of the 1173 underlying protocols, SNMP and NETCONF, are quite different. With 1174 SNMP, the persistency of a writable object depends either on the 1175 object definition itself (i.e., the text in the DESCRIPTION clause) 1176 or the persistency properties of the conceptual row it is part of, 1177 sometimes controlled via a columnar object using the StorageType 1178 textual convention. With NETCONF, the persistency of configuration 1179 objects is determined by the properties of the underlying datastore. 1180 Furthermore, NETCONF as defined in [RFC6241] does not provide a 1181 standard operation to modify operational state. The 1182 and operations only manipulate configuration data. As 1183 a consequence of these considerations, it is not possible to generate 1184 YANG configuration data nodes from SMIv2 definitions in an automated 1185 way. 1187 However, for selected SMIv2 objects where the SNMP and NETCONF 1188 persistency semantics are consistent, implementations may choose to 1189 implement some YANG data nodes generated from SMIv2 definitions as 1190 configuration data nodes. Such a deviation from the generated read- 1191 only YANG module should be formally documented in the form of a 1192 separate YANG module that uses YANG deviation statements to change 1193 the config property of the data nodes implemented as configuration 1194 data nodes from false to true. Deviations that change the config 1195 false property to true without any other changes to the semantics of 1196 the data node do not affect the compliance with the YANG module 1197 generated from an SMIv2 module. 1199 11.1. Example: addressMapControlTable of RMON2-MIB 1201 The following example demonstrates how certain columnar objects of 1202 the addressMapControlTable of the RMON2-MIB [RFC4502] can be turned 1203 into YANG configuration data nodes. Note that YANG deviations affect 1204 the property of the target node only and are not inherited downwards. 1206 module acme-RMON2-MIB-deviations { 1208 namespace "http://acme.example.com/RMON2-MIB-deviations"; 1209 prefix "acme-rmon2-devs"; 1211 import RMON2-MIB { 1212 prefix "rmon2-mib"; 1213 revision-date 2006-05-02; 1214 } 1216 revision 2012-01-11 { 1217 description 1218 "First version."; 1219 } 1221 deviation "/rmon2-mib:RMON2-MIB" { 1222 deviate replace { 1223 config true; 1224 } 1225 } 1227 deviation "/rmon2-mib:RMON2-MIB/" 1228 + "rmon2-mib:addressMapControlTable" { 1229 deviate replace { 1230 config true; 1231 } 1232 } 1234 deviation "/rmon2-mib:RMON2-MIB/" 1235 + "rmon2-mib:addressMapControlTable/" 1236 + "rmon2-mib:addressMapControlEntry" { 1237 deviate replace { 1238 config true; 1239 } 1240 } 1242 deviation "/rmon2-mib:RMON2-MIB/" 1243 + "rmon2-mib:addressMapControlTable/" 1244 + "rmon2-mib:addressMapControlEntry/" 1245 + "rmon2-mib:addressMapControlIndex" { 1246 deviate replace { 1247 config true; 1248 } 1249 } 1251 deviation "/rmon2-mib:RMON2-MIB/" 1252 + "rmon2-mib:addressMapControlTable/" 1253 + "rmon2-mib:addressMapControlEntry/" 1254 + "rmon2-mib:addressMapControlDataSource" { 1255 deviate replace { 1256 config true; 1257 } 1258 } 1260 deviation "/rmon2-mib:RMON2-MIB/" 1261 + "rmon2-mib:addressMapControlTable/" 1262 + "rmon2-mib:addressMapControlEntry/" 1263 + "rmon2-mib:addressMapControlOwner" { 1264 deviate replace { 1265 config true; 1266 } 1267 } 1268 } 1270 A NETCONF server that implements the RMON2-MIB module with these 1271 deviations would advertise the following capabilities in its 1272 message (where whitespace has been added for readability): 1274 1275 urn:ietf:params:xml:ns:yang:smiv2:RMON2-MIB? 1276 module=RMON2-MIB& 1277 revision=2006-05-02& 1278 deviations=acme-RMON2-MIB-deviations 1279 1280 1281 http://acme.example.com/RMON2-MIB-deviations? 1282 module=acme-RMON2-MIB-deviations& 1283 revision=2012-01-11 1284 1286 12. IANA Considerations 1288 This document registers two URIs in the IETF XML registry [RFC3688]. 1289 Following the format in RFC 3688, the following registrations have 1290 been made. 1292 URI: urn:ietf:params:xml:ns:yang:ietf-yang-smiv2 1294 Registrant Contact: The NETMOD WG of the IETF. 1296 XML: N/A, the requested URI is an XML namespace. 1298 URI: urn:ietf:params:xml:ns:yang:smiv2 1300 Registrant Contact: The NETMOD WG of the IETF. 1302 XML: N/A, the requested URI is an XML namespace. 1304 This document registers a YANG module in the YANG Module Names 1305 registry [RFC6020]. 1307 name: ietf-yang-smiv2 1308 namespace: urn:ietf:params:xml:ns:yang:ietf-yang-smiv2 1309 prefix: smiv2 1310 reference: RFC XXXX 1312 13. Security Considerations 1314 This document defines a translation of SMIv2 MIB modules into YANG 1315 modules, enabling read-only access to data objects defined in SMIv2 1316 MIB modules via NETCONF. The translation itself has no security 1317 impact on the Internet. 1319 Users of translated SMIv2 models that have been published as RFCs 1320 should consult the security considerations of the respective RFCs. 1321 In addition, the security considerations for the NETCONF protocol 1322 [RFC6241] should be consulted to understand how NETCONF protects 1323 potentially sensitive information. 1325 14. Acknowledgements 1327 The editor wishes to thank the following individuals for providing 1328 helpful comments on various versions of this document: Andy Bierman, 1329 Martin Bjorklund, David Reid, and David Spakes. 1331 15. References 1333 15.1. Normative References 1335 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1336 Requirement Levels", BCP 14, RFC 2119, March 1997. 1338 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1339 Schoenwaelder, Ed., "Structure of Management Information 1340 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 1342 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1343 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 1344 STD 58, RFC 2579, April 1999. 1346 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 1347 "Conformance Statements for SMIv2", STD 58, RFC 2580, 1348 April 1999. 1350 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1351 the Network Configuration Protocol (NETCONF)", RFC 6020, 1352 October 2010. 1354 [RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021, 1355 October 2010. 1357 15.2. Informative References 1359 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 1360 MIB", RFC 2863, June 2000. 1362 [RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information 1363 Base for the Differentiated Services Architecture", 1364 RFC 3289, May 2002. 1366 [RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen, 1367 "Coexistence between Version 1, Version 2, and Version 3 1368 of the Internet-standard Network Management Framework", 1369 RFC 3584, August 2003. 1371 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1372 January 2004. 1374 [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB 1375 Documents", BCP 111, RFC 4181, September 2005. 1377 [RFC4502] Waldbusser, S., "Remote Network Monitoring Management 1378 Information Base Version 2", RFC 4502, May 2006. 1380 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1381 and A. Bierman, Ed., "Network Configuration Protocol 1382 (NETCONF)", RFC 6241, June 2011. 1384 Appendix A. Mapping of Well Known Types (normative) 1386 SMIv2 Module: SNMPv2-SMI 1387 SMIv2 Type: INTEGER (used as an enumeration) 1388 YANG Type: enumeration 1390 SMIv2 Module: SNMPv2-SMI 1391 SMIv2 Type: INTEGER (used as a numeric type) 1392 YANG Type: int32 1394 SMIv2 Module: SNMPv2-SMI 1395 SMIv2 Type: Integer32 1396 YANG Type: int32 1398 SMIv2 Module: SNMPv2-SMI 1399 SMIv2 Type: OCTET STRING (used as a binary string) 1400 YANG Type: binary 1402 SMIv2 Module: SNMPv2-SMI 1403 SMIv2 Type: OCTET STRING (used to hold UTF8/ASCII characters) 1404 YANG Type: string 1406 SMIv2 Module: SNMPv2-SMI 1407 SMIv2 Type: OBJECT IDENTIFIER 1408 YANG Module: ietf-yang-types 1409 YANG Type: object-identifier-128 1411 SMIv2 Module: SNMPv2-SMI 1412 SMIv2 Type: BITS 1413 YANG Type: bits 1415 SMIv2 Module: SNMPv2-SMI 1416 SMIv2 Type: IpAddress 1417 YANG Module: ietf-inet-types 1418 YANG Type: ipv4-address 1420 SMIv2 Module: SNMPv2-SMI 1421 SMIv2 Type: Counter32 1422 YANG Module: ietf-yang-types 1423 YANG Type: counter32 1425 SMIv2 Module: SNMPv2-SMI 1426 SMIv2 Type: Gauge32 1427 YANG Module: ietf-yang-types 1428 YANG Type: gauge32 1430 SMIv2 Module: SNMPv2-SMI 1431 SMIv2 Type: TimeTicks 1432 YANG Module: ietf-yang-types 1433 YANG Type: timeticks 1435 SMIv2 Module: SNMPv2-SMI 1436 SMIv2 Type: Counter64 1437 YANG Module: ietf-yang-types 1438 YANG Type: counter64 1440 SMIv2 Module: SNMPv2-SMI 1441 SMIv2 Type: Unsigned32 1442 YANG Type: uint32 1444 SMIv2 Module: SNMPv2-SMI 1445 SMIv2 Type: Opaque 1446 YANG Module: ietf-yang-smiv2 1447 YANG Type: opaque 1449 SMIv2 Module: SNMPv2-TC 1450 SMIv2 Type: PhysAddress 1451 YANG Module: ietf-yang-types 1452 YANG Type: phys-address 1454 SMIv2 Module: SNMPv2-TC 1455 SMIv2 Type: MacAddress 1456 YANG Module: ietf-yang-types 1457 YANG Type: mac-address 1459 SMIv2 Module: SNMPv2-TC 1460 SMIv2 Type: TruthValue 1461 YANG Type: boolean 1463 SMIv2 Module: SNMPv2-TC 1464 SMIv2 Type: TimeStamp 1465 YANG Module: ietf-yang-types 1466 YANG Type: timestamp 1468 SMIv2 Module: RMON2-MIB 1469 SMIv2 Type: ZeroBasedCounter32 1470 YANG Module: ietf-yang-types 1471 YANG Type: zero-based-counter32 1473 SMIv2 Module: HCNUM-TC 1474 SMIv2 Type: ZeroBasedCounter64 1475 YANG Module: ietf-yang-types 1476 YANG Type: zero-based-counter64 1478 SMIv2 Module: HCNUM-TC 1479 SMIv2 Type: CounterBasedGauge64 1480 YANG Module: ietf-yang-types 1481 YANG Type: gauge64 1483 SMIv2 Module: INET-ADDRESS-MIB 1484 SMIv2 Type: InetAutonomousSystemNumber 1485 YANG Module: ietf-inet-types 1486 YANG Type: as-number 1488 SMIv2 Module: INET-ADDRESS-MIB 1489 SMIv2 Type: InetVersion 1490 YANG Module: ietf-inet-types 1491 YANG Type: ip-version 1493 SMIv2 Module: INET-ADDRESS-MIB 1494 SMIv2 Type: InetPortNumber 1495 YANG Module: ietf-inet-types 1496 YANG Type: port-number 1498 SMIv2 Module: DIFFSERV-DSCP-TC 1499 SMIv2 Type: Dscp 1500 YANG Module: ietf-inet-types 1501 YANG Type: dscp 1503 SMIv2 Module: IPV6-FLOW-LABEL-MIB 1504 SMIv2 Type: IPv6FlowLabel 1505 YANG Module: ietf-inet-types 1506 YANG Type: ipv6-flow-label 1508 SMIv2 Module: URI-TC-MIB 1509 SMIv2 Type: Uri 1510 YANG Module: ietf-inet-types 1511 YANG Type: uri 1513 Appendix B. Module Prefix Generation (informative) 1515 This section describes an algorithm to generate module prefixes, to 1516 be used in the import statements. The input of the prefix generation 1517 algorithm is a set of prefixes (usually derived from imported module 1518 names) and a specific module name to be converted into a prefix. The 1519 algorithm described below produces a prefix for the given module name 1520 that is unique within the set of prefixes. 1522 +-----------------+--------+ 1523 | YANG Module | Prefix | 1524 +-----------------+--------+ 1525 | ietf-yang-types | yang | 1526 | ietf-inet-types | inet | 1527 | ietf-yang-smiv2 | smiv2 | 1528 +-----------------+--------+ 1530 Table 1: Special prefixes for well known YANG modules 1532 o First, some predefined translations mapping well known YANG 1533 modules to short prefixes are tried (see Table 1). If a fixed 1534 translation rule exists and leads to a conflict free prefix, then 1535 the fixed translation is used. 1537 o Otherwise, prefixes are generated by tokenizing a YANG module 1538 name, using hyphens as token separators. The tokens derived from 1539 the module name are converted to lowercase characters. The prefix 1540 then becomes the shortest sequence of tokens concatenated using 1541 hyphens as separators, which includes at least two tokens and 1542 which is unique among all prefixes used in the YANG module. 1544 In the worst case, the prefix derived from an SMIv2 module name 1545 becomes the SMIv2 module name translated to lower-case. But on 1546 average, much shorter prefixes are generated. 1548 Author's Address 1550 Juergen Schoenwaelder 1551 Jacobs University 1553 Email: j.schoenwaelder@jacobs-university.de