idnits 2.17.1 draft-bierman-core-yid-00.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 == Line 504 has weird spacing: '...le-bits uin...' == Line 514 has weird spacing: '...ocal-id yid...' == Line 1413 has weird spacing: '...x1915cc ipNet...' == Line 1414 has weird spacing: '...x195dbc ipNet...' == Line 1418 has weird spacing: '...x190bcb ipNet...' -- The document date (August 16, 2016) is 2782 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) == Missing Reference: 'RFC3688' is mentioned on line 924, but not defined == Outdated reference: A later version (-18) exists of draft-ietf-netconf-restconf-16 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 core A. Bierman 3 Internet-Draft YumaWorks, Inc. 4 Intended status: Standards Track P. van der Stok 5 Expires: February 17, 2017 consultant 6 August 16, 2016 8 Numeric YANG Identifiers 9 draft-bierman-core-yid-00 11 Abstract 13 This document describes an encoding of YANG object identifiers using 14 numeric values instead of string values. It combines several 15 techniques to provide optimized serialization in protocol messages. 17 Note 19 Discussion and suggestions for improvement are requested, and should 20 be sent to core@ietf.org. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on February 17, 2017. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1.1. Examples . . . . . . . . . . . . . . . . . . . . . . 4 59 1.1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . 4 60 1.2. Design Objectives . . . . . . . . . . . . . . . . . . . . 5 61 1.3. Solution Approach . . . . . . . . . . . . . . . . . . . . 5 62 2. YANG Identifier Registry . . . . . . . . . . . . . . . . . . 6 63 2.1. YANG Identifier Registry Example . . . . . . . . . . . . 8 64 3. YANG Identifier . . . . . . . . . . . . . . . . . . . . . . . 9 65 3.1. module-id . . . . . . . . . . . . . . . . . . . . . . . . 10 66 3.2. local-id . . . . . . . . . . . . . . . . . . . . . . . . 10 67 3.2.1. YANG Hash Numbered local-id . . . . . . . . . . . . . 11 68 3.2.2. Manually Numbered local-id . . . . . . . . . . . . . 11 69 4. YANG Identifier Registry Format . . . . . . . . . . . . . . . 12 70 4.1. ietf-yid Module . . . . . . . . . . . . . . . . . . . . . 12 71 5. YANG Hash Generation . . . . . . . . . . . . . . . . . . . . 19 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 74 7.1. YANG Module Library Entry: ietf-yid . . . . . . . . . . . 21 75 7.2. YANG Module Names Parameter Addition: module-id . . . . . 21 76 7.3. YANG Identifier Registry . . . . . . . . . . . . . . . . 22 77 7.3.1. Registry Maintenance . . . . . . . . . . . . . . . . 22 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 23 81 9.2. Informative References . . . . . . . . . . . . . . . . . 23 82 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . 24 83 Appendix B. YANG Identifier Examples . . . . . . . . . . . . . . 25 84 B.1. Hash Collision Repair Example . . . . . . . . . . . . . . 25 85 B.2. Manual Numbering Example . . . . . . . . . . . . . . . . 26 86 B.3. Augment Numbering Example . . . . . . . . . . . . . . . . 28 87 Appendix C. YANG Hash Examples . . . . . . . . . . . . . . . . . 30 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 90 1. Introduction 92 This document describes mechanisms for mapping YANG schema nodes to 93 numeric values. Existing YANG-based protocol use path expression 94 strings or element hierarchies that use element names to identify a 95 particular YANG data node. These object identifiers can represent a 96 significant percentage of protocol message payload content. 98 Constrained environments require efficient protocols and a numeric 99 (binary) representation of YANG object identifiers can help reduce 100 payload overhead in protocol messages. 102 The effective use of YANG Identifiers requires three components: 104 YANG Identifier Registry: A collection of numeric encoding rules 105 for a specific set of YANG modules. Implementations need to use 106 the contents of the registry to encode and decode object 107 identifiers for data nodes in the associated modules. 109 YANG Identifier: A hierarchical numeric YANG object identifier. 110 This is intended to be a permanent object identifier, like the 111 path expression or element names it is meant to replace. 113 Message Serialization: A set of encoding rules within a particular 114 serialization format. It is expected that CBOR will be used in 115 constrained environments. This document does not define any 116 message serialization techniques, or assume any specific protocols 117 will be used. [TBD: add ref. to YANG to CBOR draft] 119 This document replaces the YANG Hash draft 120 [I-D.bierman-core-yang-hash]. The core concepts from that draft have 121 been incorporated into this document. 123 1.1. Terminology 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [RFC2119]. 129 Readers of this specification should be familiar with all the terms 130 and concepts discussed in [RFC2578]. 132 The following terms are defined in the NETCONF protocol [RFC6241]: 133 client, configuration data, datastore, and server. 135 The following terms are defined in the YANG data modelling language 136 [RFC6020]: container, data node, key, key leaf, leaf, leaf-list, and 137 list. 139 The following terms are defined in RESTCONF protocol 140 [I-D.ietf-netconf-restconf]: data resource, data-store resource, edit 141 operation, query parameter, target resource, and unified data-store. 143 The following terms are defined in this document: 145 YANG module schema tree: The conceptual tree of YANG objects 146 comprised of all "rpc", "data-def" and "notification" statements 147 within a particular revision of a module and all submodules 148 included by this module. 150 YANG Identifier: Numeric object identifier, which is a fixed-length 151 numeric value that represents a particular schema node within a 152 YANG module schema tree. The length and format of a YANG 153 identifier are defined in the YANG Identifier Registry. Also 154 called a "YID". 156 YANG Identifier File: Also called a YID File. Contains a 157 representation of the manual numeric path assignments for a YANG 158 module. 160 1.1.1. Examples 162 Some text within examples throughout the document are split into 163 multiple lines for display purposes only. When a line ends with 164 backslash ('\') as the last character, the line is wrapped for 165 display purposes. It is to be considered to be joined to the next 166 line by deleting the backslash, the following line break, and the 167 leading whitespace of the next line. 169 1.1.2. Tree Diagrams 171 A simplified graphical representation of the data model is used in 172 the YANG modules specified in this document. The meaning of the 173 symbols in these diagrams is as follows: 175 Brackets "[" and "]" enclose list keys. 177 Abbreviations before data node names: "rw" means configuration 178 data (read-write) and "ro" state data (read-only). 180 Symbols after data node names: "?" means an optional node, "!" 181 means a presence container, and "*" denotes a list and leaf-list. 183 Parentheses enclose choice and case nodes, and case nodes are also 184 marked with a colon (":"). 186 Ellipsis ("...") stands for contents of subtrees that are not 187 shown. 189 1.2. Design Objectives 191 This work is motivated by the need to minimize the size of object 192 identifiers within protocol messages representing YANG data, encoded 193 using binary format. The string encoding size of YANG identifier 194 names can be very significant since designers are encouraged to 195 provide long descriptive names to help human readability of the YANG 196 module. 198 It is therefore desirable to produce an object numbering algorithm 199 that can be serialized efficiently in protocol messages with binary 200 encoding formats such as CBOR. 202 There are several design objectives for this work: 204 Persistent Identifiers: It is important that once an identifier is 205 assigned, that is it never changed in any future revisions in the 206 module. 208 Unique Identifiers: It is important that it is easy to ensure that 209 all identifiers are unique within a server, and all servers that 210 share the same set of YANG Identifier information. 212 Low Complexity: The algorithms need to be simple to understand. 213 Module updates need be simple, and only require the latest module 214 and registry information. Dependency on YANG statement order or 215 statement refactoring (e.g., move to groupings or submodules) must 216 be avoided. 218 Flexibility: The algorithms need be tuned for specific YANG 219 modules. Manual (packed) numbering or hash-based numbering should 220 be supported. 222 No Inter-Module Dependencies: The algorithms must not allow 223 identifiers from different YANG modules to conflict in any way. 224 An identifier that is always scoped by an administratively 225 assigned module identifier is required. 227 No Hash Collisions: The algorithms must allow hash collisions to 228 be avoided without modifying the associated YANG module. The 229 numeric assignments for all objects within a module must be 230 permanently unique (within that module scope). 232 1.3. Solution Approach 234 This document describes a solution with four components: 236 YANG Identifier Registry: A YANG Identifier registry contains 237 manually administered information for each YANG module. A minimal 238 amount of information is needed for each module. A numeric module 239 identifier needs to be assigned for each module in the registry. 240 Most registry information is permanent. New entries can be added 241 but naming information for old entries cannot be changed. Each 242 module can be either be numbered automatically using YANG Hash, or 243 manually using registry assignment. 245 YANG Identifier Format: A YANG Identifier format is a structured 246 binary identifier that allows a hierarchical YANG schema node to 247 be represented as a single integer. The mapping is based on a 248 murmur32 hash of the YANG object identifier string for each data 249 definition node. The YANG path identifier is not allowed to 250 change value after it is first assigned, so it can be safely and 251 easily used as a permanent identifier. The value does not depend 252 on module statement order or any field that is allowed to change 253 in YANG in new module revisions. 255 YANG Hash: The YANG Hash automatic numbering algorithm, defined in 256 Section 5, is used to automatically assign the numeric identifiers 257 to YANG data definition schema nodes. Hash values are scoped by 258 the module identifier, so clashes between modules are not 259 possible. If a hash collision does occur within the same module, 260 then a registry entry is used to map the clashing data nodes to 261 manually assigned identifiers. Hash collisions are not allowed in 262 the registry. They are manually avoided without any need to 263 modify the YANG module. 265 Manual Numbering: A manual numbering mechanism and a YANG Identifier 266 template to specify manually assigned local identifiers is needed. 267 This allows compact numbering of objects and therefore the most 268 efficient use of identifier numbering space. 270 2. YANG Identifier Registry 272 A YANG Identifier registry is a data structure representing the 273 numeric mapping information for a set of YANG modules. This is a 274 global registry, meaning that all servers that use the same registry 275 use the same numeric assignments. 277 Ideally, all servers will use the same registry and there will be 278 only one registry. It is expected that a server will use the 279 official registry maintained by IANA, but other registries including 280 locally administered registries are possible. Each registry is self- 281 contained. Registries cannot be mixed or reference other registries. 282 (This is a subject for future work). All YANG identifier values are 283 hierarchical, and scoped by the numeric identifier assigned in the 284 registry for the module. 286 The YANG Identifier registry supports automatically numbered objects 287 within a module using YANG Hash. It also supports manually numbered 288 objects within a module using object path to number mappings. If 289 YANG Hash is used, then some of the numbering space for the module is 290 reserved for manual assignments in case there are any hash collisions 291 within the module. 293 The size of the YANG identifiers, and the size of each field within 294 the YANG identifier, are configured in the registry. The type of 295 local identifier numbering is also configured, on a per-module basis. 296 A server can only support one registry at a time, and it is expected 297 to advertise which registry it is using via the management protocol 298 in use. 300 Each registry entry represents the numeric mapping information for 301 one YANG module. Only one entry per module is maintained, for the 302 latest revision. Registry information is never allowed to change. 303 Information for new schema nodes can be added but information for 304 existing schema nodes can never be altered. 306 A YANG Identifier registry provides the following global parameters 307 that apply to all modules: 309 name: The administrative name for the registry 311 revision: The current revision ID for the registry 313 module-bits: The number of bits assigned to a module-id in a YID 314 for the registry 316 local-bits: The number of bits assigned to a local-id in a YID for 317 the registry 319 The registry also has a list of modules that support numeric YANG 320 identifiers. Each module entry has the following parameters that 321 apply to all revisions of the module: 323 module-id: The numeric identifier assigned to the module in the 324 registry 326 name: The name of the YANG module. 328 revision: The revision ID of the registry entry for the module 329 local-type: The type of local-id values used in a YANG Identifier 330 for a schema node in the module. The values 'hash' and 'manual' 331 are supported. 333 If the 'local-type' is equal to 'manual' for a module entry, then the 334 manually assigned numbers are provided in the module registry entry. 335 This information can either be in-line in the registry entry or 336 accessible via an external URI. 338 The following information is provided for every YANG identifier in 339 the module if the mapping parameters are local: 341 local-id: The local identifier assigned to the schema node 343 path: The YANG object identifier for the schema node 345 The following information is provided for the entire module if the 346 mapping parameters are remote: 348 mapping-url: The URL for retrieval of a representation of the 349 mapping information 351 mapping-type: The media type for the 'mapping-url' 353 2.1. YANG Identifier Registry Example 355 The following example shows a JSON representation of a "yid-registry" 356 container. There are 3 modules (ietf-system, ietf-yang-library, and 357 example-address). The registry uses 32 bit identifiers. 16 bits are 358 used for local identifiers in each module. 360 { "yid-registry" : { 361 "name" : "example-reg", 362 "revision" : 0x7e00701, 363 "module-bits" : 16, 364 "local-bits" : 16, 365 "module" : [ 366 { 367 "module-id" : 1, 368 "name" : "ietf-system", 369 "revision" : 0x7de0806, 370 "local-type" : "hash" 371 }, 372 { 373 "module-id" : 2, 374 "name" : "ietf-yang-library", 375 "revision" : 0x7e00615, 376 "local-type" : "hash" 377 }, 378 { 379 "module-id" : 3, 380 "name" : "example-address", 381 "revision" : 0x7de0508, 382 "local-type" : "manual", 383 "mapping-url" : "http://example.com/yang-ids-47.json", 384 "mapping-type" : "application/json" 385 } 386 ] 387 } 388 } 390 3. YANG Identifier 392 A YANG Identifier is constructed of 2 fields: a module identifier 393 called "module-id" and a local identifier within the scope of the 394 module, called "local-id". 396 YANG Identifier Formats: 398 Form 1: YANG Hash Used 400 +-------------+ +-------------+ 401 | module-id | |R| local-id | 402 +-------------+ +-------------+ 404 Form 2: Manual Identifiers used 406 +-------------+ +-------------+ 407 | module-id | | local-id | 408 +-------------+ +-------------+ 410 The local identifier can either be a YANG Hash if the 'local-type' 411 for the module registry entry is 'hash', or manual numbering if the 412 'local-type' is 'manual'. If YANG Hash is used, then one bit is 413 reserved within the local-id as the "rehash bit". 415 A YANG Identifier is derived from the 'module-id', 'local-bits', and 416 'local-id' fields, using the following formula: 418 YID = (module-id * (2 ^^ local-bits)) + local-id 420 3.1. module-id 422 The module-id field is a mandatory fixed-width number that must be 423 unique within the registry. This number is manually assigned for 424 each YANG module and is specified in the registry entry information 425 for the YANG module. All other YANG identifier sub-fields are scoped 426 by this module-id. It is not possible for YANG identifier values 427 from different modules within a YANG Identifier registry to collide. 429 Module identifiers are expected to be assigned by the registry 430 maintainer, not by YANG module authors. It is critical that 431 assignments are unique and stable. Registry maintenance procedures 432 are discussed in the IANA Considerations section . Section 7. 434 3.2. local-id 436 The local-id is a fixed width number defined in the YANG Identifier 437 registry. Local identifiers can be one of two formats: YANG Hash or 438 Manually Assigned. 440 3.2.1. YANG Hash Numbered local-id 442 The automatic numbering of local identifier values is based on the 443 YANG Hash for the path identifier for the schema node. An absolute 444 path expression is used to identify the schema node. 446 The YANG registry value of 'local-bits' determines the size of the 447 YANG hash value. One bit is reserved as the "rehash" bit and "local- 448 bits - 1" number of bits are used for the YANG hash value. 450 A YANG Hash is calculated for the path expression for each schema 451 node according to the procedure defined in Section 5. The lowest 452 order bits are used. 454 If any hash collisions occur, then a manual registry entry is needed 455 for all but one of the colliding nodes. Since the value zero is 456 reserved, a hash value of zero is considered a clash, and must be 457 fixed using a manually assigned entry for the node. 459 For example, if 8 bits were used for the 'local-bits' value, then the 460 low order 7 bits are for hash values. The local-id values 1 - 127 461 would be allowed for hash values. The values 128 - 255 would be 462 allowed for manually assigned rehash values. 464 3.2.2. Manually Numbered local-id 466 A YANG Identifier data structure is used to represent the manually 467 assigned schema node assignments for a YANG module. Each data node 468 is explicitly assigned a numeric value that is unique within the YANG 469 module where it is defined. Data nodes that augment external modules 470 are defined in the augmenting module. Once an assignment is made it 471 can never be changed. Only new assignments can be made in new 472 revisions of a module registry entry. 474 If local identifiers are used then the mapping between the YANG 475 object identifier and numeric value MUST be provided via the 476 registry. The format for 'local' entries is defined in the YANG 477 module in Section 4.1. 479 The format of registry entry files that use the 'remote' form of 480 local-id identification is outside the scope of this document. The 481 only requirements are that the fields "local-id" and "path" MUST be 482 used in each entry to represent the YANG identifier to numeric 483 mapping. The 'mapping-type' field is used to determine the syntax 484 and semantics of the data represented by the 'mapping-url' resource. 486 4. YANG Identifier Registry Format 488 A YANG Identifier Registry is a data structure that represents the 489 module identifier encoding details for all modules in the registry. 490 It is expected that the protocol using YANG Identifiers will indicate 491 which YANG Identifier Registry it is using. 493 The YANG Identifier Registry syntax and semantics are defined using a 494 YANG module called "ietf-yid". This allows instances that conform to 495 the registry structure to be serialized in different encoding 496 formats, such as XML, JSON, or CBOR. 498 The following YANG tree diagram represents the contents of the ietf- 499 yid module: 501 +--rw yid-registry! 502 +--rw name string 503 +--rw revision yid-revision-id 504 +--rw module-bits uint8 505 +--rw local-bits uint8 506 +--rw module* [module-id] 507 +--rw module-id yid-module-id 508 +--rw name string 509 +--rw revision yid-revision-id 510 +--rw local-type enumeration 511 +--rw (local-type-parms)? 512 +--:(local) 513 | +--rw mapping* [local-id] 514 | +--rw local-id yid-local-id 515 | +--rw path string 516 +--:(remote) 517 +--rw mapping-url? inet:uri 518 +--rw mapping-type? string 520 4.1. ietf-yid Module 522 524 module ietf-yid { 525 namespace "urn:ietf:params:xml:ns:yang:ietf-yid"; 526 prefix "yid"; 527 import ietf-inet-types { prefix inet; } 529 organization 530 "IETF CORE (Constrained RESTfull Environments) Working Group"; 532 contact 533 "WG Web: 534 WG List: 536 Author: Andy Bierman 537 539 Author: Peter Van der Stock 540 541 "; 543 description 544 "This module contains a conceptual YANG specification 545 for a YANG Identifier Registry. 547 Copyright (c) 2016 IETF Trust and the persons identified as 548 authors of the code. All rights reserved. 550 Redistribution and use in source and binary forms, with or 551 without modification, is permitted pursuant to, and subject 552 to the license terms contained in, the Simplified BSD License 553 set forth in Section 4.c of the IETF Trust's Legal Provisions 554 Relating to IETF Documents 555 (http://trustee.ietf.org/license-info). 557 This version of this YANG module is part of RFC XXXX; see 558 the RFC itself for full legal notices."; 560 // RFC Ed.: replace XXXX with actual RFC number and remove this 561 // note. 563 // RFC Ed.: remove this note 564 // Note: extracted from draft-bierman-core-yid-00.txt 566 // RFC Ed.: update the date below with the date of RFC publication 567 // and remove this note. 568 revision 2016-08-16 { 569 description 570 "Initial revision."; 571 reference 572 "RFC XXXX: Numeric YANG Identifiers."; 573 } 575 extension permanent-data { 576 description 577 "This extension can be used as a sub-statement in any data 578 definition statement. It indicates that an instance of 579 the associated data node is considered permanent. 581 The value of an instance of a data node that contains this 582 extension MUST NOT change after it is assigned in 583 a published version of an instance document. 585 Note that a work-in-progress is not a published document. 586 An RFC or IANA registry entry are examples of 587 published document. 589 There is no parameter value for this extension."; 590 } 592 typedef yid-revision-id { 593 type uint32; 594 description 595 "Contains a numeric representation of the YANG Identifier 596 registry version. This value SHOULD be constructed 597 from a revision date string, using the following 598 unsigned integer format: YYYYMMDD 600 where: 602 YYYY is a 16-bit integer representation of the year 603 MM is a 8-bit integer representation of the month (1 - 12) 604 DD is a 8-bit integer representation of the day in the month 605 "; 606 } 608 typedef yid-module-id { 609 type uint32 { 610 range "1 .. max"; 611 } 612 description 613 "Represents a YANG Identifier module-id field."; 614 } 616 typedef yid-local-id { 617 type uint32 { 618 range "1 .. max"; 619 } 620 description 621 "Represents a YANG Identifier local-id field."; 622 } 624 grouping yid-registry { 625 description 626 "A grouping that representing the syntax and semantics of a 627 YANG Identifier Registry."; 629 container yid-registry { 630 presence "Instantiation of the YID registry is required."; 632 description 633 "Represents an YANG Identifier Registry"; 635 leaf name { 636 type string; 637 mandatory true; 638 description 639 "An administrative name for the YANG identifier registry. 640 This value SHOULD NOT change once assigned."; 641 } 643 leaf revision { 644 type yid-revision-id; 645 mandatory true; 646 description 647 "A revision identifier that is unique within all 648 revisions of a YANG Identifier registry. 649 This value MUST NOT change once assigned in 650 the first revision of the YANG Identifier registry."; 651 } 653 leaf module-bits { 654 yid:permanent-data; 655 type uint8 { 656 range "4 .. 32"; 657 } 658 mandatory true; 659 description 660 "The number of bits reserved for all module identifier 661 values used within the registry. 663 This value MUST NOT be changed after initial 664 publication of the registry."; 665 } 667 leaf local-bits { 668 yid:permanent-data; 669 type uint8 { 670 range "4 .. 32"; 671 } 672 mandatory true; 673 description 674 "The number of bits reserved for all local identifier 675 values used within each module. 677 The value 'module-bits + local-bits' represents 678 the total number of bits contained in all full-form 679 YANG Identifier values used within the registry. 681 This value MUST NOT be changed after initial 682 publication of the registry."; 683 } 685 list module { 686 key module-id; 687 unique name; 689 description 690 "Represents one module entry in the registry. 691 Only complete YANG module schema trees are 692 represented in a YID registry entry. 693 Sub-module or incomplete representations are 694 not allowed."; 696 uses yid-module-entry; 697 } // list module 698 } // container yid-registry 699 } // grouping yid-registry 701 grouping yid-module-entry { 703 description 704 "Represents one module entry in the registry. 705 Only complete YANG module schema trees are 706 represented in a YID registry entry. 707 Sub-module or incomplete representations are 708 not allowed."; 710 leaf module-id { 711 yid:permanent-data; 712 type yid-module-id; 713 description 714 "The numeric identifier assigned to this module. 715 This value MUST NOT be changed once the the module 716 entry is created."; 718 } 720 leaf name { 721 yid:permanent-data; 722 type string; 723 mandatory true; 724 description 725 "The module name string. This exactly matches 726 the value used in the associated YANG module. 728 This value MUST NOT be changed once the the module 729 entry is created."; 730 } 732 leaf revision { 733 type yid-revision-id; 734 mandatory true; 735 description 736 "A revision identifier that is unique within all 737 revisions of the specified YANG module. 739 This value MUST be updated to the new publication 740 identifier value each time the YANG module is updated 741 in the registry. Only one entry per module is 742 maintained."; 743 } 745 leaf local-type { 746 yid:permanent-data; 747 type enumeration { 748 enum hash { 749 value 0; 750 description 751 "All local-id values where the most significant bit 752 is set are YANG hash values. 754 All local-id values where the most significant bit 755 is not set are manually assigned YANG rehash values."; 756 } 757 enum manual { 758 value 1; 759 description 760 "All local-id values are manually assigned identifiers."; 761 } 762 } 763 mandatory true; 764 description 765 "The type of numbering used in local identifiers."; 766 } 768 choice local-type-parms { 769 description 770 "The manual local-id assignments can be done inline 771 or contained in a remote YID file representation. 772 This choice MUST be provided if any local identifier 773 mappings are used in the module. This includes 774 all manually assigned values, and and rehash entries, 775 if the associated 'local-type' value is 'hash'."; 776 case local { 777 description 778 "Case arm for inline local-id manual assignments. 779 The YID node list MAY be updated in the registry for 780 each new revision of the associated YANG module."; 782 list mapping { 783 key "local-id"; 784 unique path; 785 description 786 "Represents one manual schema node assignment."; 788 leaf local-id { 789 yid:permanent-data; 790 type yid-local-id; 791 description 792 "The manually assigned local-id value for this entry. 793 The actual allowed range for this list is controlled 794 by the value of 'local-bits'. The number of entries 795 allowed is (2 ^^ local-bits) - 2. The 'local-id' value 796 zero is reserved and cannot be used."; 797 } 799 leaf path { 800 yid:permanent-data; 801 type string; 802 mandatory true; 803 description 804 "The path expression representing this schema node. 805 This value MUST NOT be changed in new revisions 806 of an instance of a YID file."; 807 } 808 } 809 } 810 case remote { 811 leaf mapping-url { 812 type inet:uri; 813 description 814 "Case arm for remote specification of the manual 815 assignments. The value is a URI for a 816 representation of the YID File associated with the 817 manually assigned numbers for a set of YANG schema 818 nodes with a YANG module. 820 This value MAY be updated in the registry for 821 each new revision of the associated YANG module."; 822 } 823 leaf mapping-type { 824 type string; 825 description 826 "The value is a string identifying the media-type 827 for the representation of mapping information 828 identified by the associated 'mapping-url' value. 830 This value MAY be updated in the registry for 831 each new revision of the associated YANG module."; 832 } 833 } // case remote 834 } // choice local-parm-types 836 } // grouping yid-module-entry 838 uses yid-registry; 840 } 842 844 5. YANG Hash Generation 846 Hash based local identifiers are defined in this section. The 847 association between a path string value and numeric value is done 848 through a hash algorithm. The 'N' least significant bits of the 849 "murmur3" 32-bit hash algorithm are used. The value of 'N' is 850 defined by the "local-bits" value in the YANG Identifier registry. 851 This hash algorithm is described online at [murmur3]. 852 Implementations are available online [murmur-imp]. When converting 4 853 input bytes to a 32-bit integer in the hash algorithm, the Little- 854 Endian convention MUST be used. 856 The "murmur3_32" hash function is executed for the entire path 857 string. 859 The value '42' is used as the seed for the hash function. The YANG 860 hash is subsequently calculated by taking the 'N - 1' least 861 significant bits, where the value of N is defined by the "local-bits' 862 value for the YANG Identifier registry. 864 The resulting number is used by the server. If the value is already 865 being used for a different object within the same YANG module, then 866 the assignment is considered invalid, and MUST be resolved in the 867 registry entry. This is done by separating the clashing objects by 868 manually assigning identifiers. 870 The hash is generated for the string representing the object path 871 identifier. A canonical representation of the path identifier is 872 used. 874 The module name is used to identify the namespace of the object node. 875 The prefix cannot be used because it is allowed to change over time. 876 The module name is never allowed to change. 878 The module name MUST be present in the identifier for the first node 879 in the object path identifier. 881 If a child node in the object path identifier is from the same module 882 namespace as its parent, then the module-name MUST NOT be used in the 883 identifier. 885 If a child node in the object path identifier is not from the same 886 module namespace as its parent, then the module-name MUST be used in 887 the identifier. 889 Choice and case node names are not included in the path expression. 890 Only 'container', 'list', 'leaf', 'leaf-list', and 'anyxml' nodes are 891 listed in the path expression. 893 The YANG Hash value is calculated for all data nodes in the module. 894 The hash values are calculated, even if the server only implements a 895 subset of these objects. This includes all "data-def" statements. 897 Example: the following identifier is for the 'mtu' leaf in the ietf- 898 interfaces module: 900 /ietf-interfaces:interfaces/interface/mtu 902 Example: the following identifier is for the 'ipv4' container in the 903 ietf-ip module, which augments the 'interface' list in the ietf- 904 interfaces module: 906 /ietf-interfaces:interfaces/interface/ietf-ip:ipv4 908 6. Security Considerations 910 The exchange of names by numbers does not affect the security of the 911 transmitted requests. 913 7. IANA Considerations 915 This document requests the following actions be taken by IANA 917 1) add the "ietf-yid" YANG module to the YANG Module Names Registry 918 2) add a new "module-id" parameter to the YANG Module Names Registry 919 3) create a new YANG Identifiers Registry 921 7.1. YANG Module Library Entry: ietf-yid 923 This document registers one URI as a namespace in the IETF XML 924 registry [RFC3688]. Following the format in RFC 3688, the following 925 registration is requested: 927 URI: urn:ietf:params:xml:ns:yang:ietf-yid 928 Registrant Contact: The CORE WG of the IETF. 929 XML: N/A, the requested URI is an XML namespace. 931 This document registers one YANG module in the YANG Module Names 932 registry [RFC6020]: 934 name: ietf-yid 935 namespace: urn:ietf:params:xml:ns:yang:ietf-yid 936 prefix: yid 937 // RFC Ed.: replace XXXX with RFC number and remove this note 938 reference: RFCXXXX 940 7.2. YANG Module Names Parameter Addition: module-id 942 This document requests that a new parameter named "module-id" be 943 added to the YANG Module Names Registry. This value is a 20 bit 944 number, greater than zero, that represents an arbitrary integer 945 assignment (by IANA) for the YANG module. 947 This is only required for registry entries that represent YANG 948 modules, not YANG sub-modules. The YANG typedef "yid-module-id" in 949 the "ietf-yid" YANG module defines the syntax and semantics of a 950 module-id value. 952 7.3. YANG Identifier Registry 954 This document requests that a new YANG Identifier Registry be created 955 and maintained by IANA. This registry is used to archive numeric 956 numbering information for YANG modules found in the YANG Module Names 957 registry. 959 This is only required for registry entries that represent YANG 960 modules, not YANG sub-modules. The YANG data node "yid-registry" in 961 the "ietf-yid" YANG module defines the syntax and semantics of a YANG 962 Identifier registry. 964 The syntax and semantics of the registry structure is described by 965 the "yid-registry" grouping definition in the "ietf-yid" YANG module 966 defined in Section 4.1. 968 A "module" entry needs to be maintained for each YANG module 969 maintained by IANA. The "yid-module-entry" grouping in the "ietf- 970 yid" YANG module defines the syntax and semantics of each module 971 entry. The "module-id" field in the entry must match the "module-id" 972 assigned to the YANG module in the YANG Module Names registry. 974 TBD: List the tools available to generate YANG hash and manual 975 assignment entries 977 The following initial parameter values are suggested for the 978 registry: 980 { "yid-registry" : { 981 "name" : "ietf-yid", 982 "revision" : TBD, 983 "module-bits" : 20, 984 "local-bits" : 16 985 } 986 } 988 7.3.1. Registry Maintenance 990 When a YANG module is added to the YANG Module Names Registry, IANA 991 will assign a unique module-id value for the module. At this time an 992 initial YANG Identifier registry entry for the module is created. 994 When a YANG module update is being published, and IANA actions are 995 being processed for the pending RFC, an update to the YANG Identifier 996 registry for the existing module is created. The registry entry 997 "revision" field is updated to a new value that is greater than the 998 previous value. 1000 No existing entry information is allowed to change. Only new 1001 manually numbered local-id values can be added. For local mappings, 1002 new "mapping" list entries can be added. For remote mappings, the 1003 "mapping-url" and "mapping-type" fields can be updated to identify 1004 the new mapping information. 1006 For YANG modules that use YANG hash based local-id values, there is 1007 no need to update the registry entry for the module unless any hash 1008 collisions would be introduced by the new module revision. For YANG 1009 modules that use manually numbered local-id values, there is no need 1010 to update the registry unless new data nodes have been added to the 1011 YANG module. 1013 8. Acknowledgements 1015 We are very grateful to Bert Greevenbosch who suggested the use of 1016 hashes and specified the use of murmur3. 1018 9. References 1020 9.1. Normative References 1022 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1023 Requirement Levels", BCP 14, RFC 2119, 1024 DOI 10.17487/RFC2119, March 1997, 1025 . 1027 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1028 the Network Configuration Protocol (NETCONF)", RFC 6020, 1029 DOI 10.17487/RFC6020, October 2010, 1030 . 1032 [murmur3] "murmurhash family", 1033 Web http://en.wikipedia.org/wiki/MurmurHash. 1035 [murmur-imp] 1036 "murmurhash implementation", 1037 Web https://code.google.com/p/smhasher/. 1039 9.2. Informative References 1041 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1042 Schoenwaelder, Ed., "Structure of Management Information 1043 Version 2 (SMIv2)", STD 58, RFC 2578, 1044 DOI 10.17487/RFC2578, April 1999, 1045 . 1047 [RFC4293] Routhier, S., Ed., "Management Information Base for the 1048 Internet Protocol (IP)", RFC 4293, DOI 10.17487/RFC4293, 1049 April 2006, . 1051 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1052 and A. Bierman, Ed., "Network Configuration Protocol 1053 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1054 . 1056 [I-D.ietf-netconf-restconf] 1057 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1058 Protocol", draft-ietf-netconf-restconf-16 (work in 1059 progress), August 2016. 1061 [I-D.bierman-core-yang-hash] 1062 Bierman, A. and P. Stok, "YANG Hash", draft-bierman-core- 1063 yang-hash-00 (work in progress), February 2016. 1065 Appendix A. Open Issues 1067 There are some advanced features not specified in this document. 1068 These can be left as future work. 1070 When to assign a module-id: There may be significant delay between 1071 the time a module is used in development and when it is published 1072 and added to a registry. Once a module-id has been assigned, it 1073 cannot be undone or changed. When should a module-id be assigned 1074 in a YANG Identifier registry? Should it be early in development, 1075 late in development, or after the module approval process? 1077 How to support private numbering: Should it be possible for a 1078 registry used by a server to contain module-id values that have 1079 not been globally assigned in the registry? Should a numeric 1080 range be reserved for this purpose? If so, is this range globally 1081 reserved or configured into each registry? 1083 How to combine registries: What if a server vendor wants to support 1084 modules not listed in a single registry? How can this be 1085 supported? E.g., increase the size of the identifier and allocate 1086 some bits for a registry identifier? 1088 Should more YANG statements be numbered: Should "rpc" and 1089 "notification" statements be numbered? Should YANG 1.1 "action" 1090 statements be numbered? 1092 How to support anyxml and anydata subtrees: A YANG data node that is 1093 defined with the "anyxml" ar "anydata" statement has an identifier 1094 for the top of the specified subtree in instance documents. XML 1095 and JSON representations of these YANG statements uses a QName to 1096 identify each descendant node within the anyxml or anydata 1097 subtree. These descendant nodes do not exist in the YANG module 1098 schema tree. They only exist in instance documents conforming to 1099 the YANG module. Therefore it is not possible to give these nodes 1100 numeric assignments. Use of string (QName) identifiers within 1101 anyxml or anydata subtrees may be required. 1103 Appendix B. YANG Identifier Examples 1105 The following simple YANG module is used throughout these examples: 1107 module example-address { 1108 namespace "http://example.com/ns/example-address"; 1109 prefix "exaddr"; 1110 revision 2016-08-05; 1112 container addresses { 1113 list address { 1114 key "last first"; 1115 leaf last { type string; } 1116 leaf first { type string; } 1117 leaf street { type string; } 1118 leaf city { type string; } 1119 leaf zipcode { type string; } 1120 } 1121 } 1122 } 1124 B.1. Hash Collision Repair Example 1126 The following example shows how a hash collision can be avoided using 1127 the YANG Hash "rehash" bit. 1129 The following path identifiers and conceptual hash values are 1130 assigned for the "example-address" module: 1132 H1 /example-address:addresses 1133 H2 /example-address:addresses/address 1134 H3 /example-address:addresses/address/last 1135 H4 /example-address:addresses/address/first 1136 H5 /example-address:addresses/address/street 1137 H6 /example-address:addresses/address/city 1138 H7 /example-address:addresses/address/zipcode 1140 The following YANG Identifier values could be assigned using if there 1141 are no hash collisions. 1143 module-id = M 1144 local-id = Hn 1146 However, if 2 nodes have the same hash value (say H2 and H5) then one 1147 of the nodes needs to be renumbered using an manual assignment in the 1148 YANG registry. If 16 bit local identifiers are used then values 1 - 1149 32767 are reserved for hash values, and values 32768 - 65535 are 1150 reserved for manually assigned rehash mappings. 1152 { "module" : [ 1153 { 1154 "module-id" : 17, 1155 "name" : "example-address", 1156 "revision" : 0x7e00801, 1157 "local-type" : "hash", 1158 "mapping" : [ 1159 { 1160 "local-id" : 32768, 1161 "path" : "/example-address:addresses/address/street" 1162 } 1163 ] 1164 } 1165 ] 1166 } 1168 B.2. Manual Numbering Example 1170 In this example, manually assigned local-id values are given to the 1171 example-address module. Instead of hash values, simple ascending 1172 integer values are given. 1174 1 /example-address:addresses 1175 2 /example-address:addresses/address 1176 3 /example-address:addresses/address/last 1177 4 /example-address:addresses/address/first 1178 5 /example-address:addresses/address/street 1179 6 /example-address:addresses/address/city 1180 7 /example-address:addresses/address/zipcode 1182 If the 'module-id' value '17' is assigned, and the 'local-bits' value 1183 is '16', then the following YANG Identifier values would be assigned 1184 for these local-id values: 1186 0x110001 /example-address:addresses 1187 0x110002 /example-address:addresses/address 1188 0x110003 /example-address:addresses/address/last 1189 0x110004 /example-address:addresses/address/first 1190 0x110005 /example-address:addresses/address/street 1191 0x110006 /example-address:addresses/address/city 1192 0x110007 /example-address:addresses/address/zipcode 1194 The example YANG Identifier (YID) file contents: 1196 { "module" : [ 1197 { 1198 "module-id" : 17, 1199 "name" : "example-address", 1200 "revision" : 0x7e00801, 1201 "local-type" : "manual", 1202 "mapping" : [ 1203 { 1204 "local-id" : 1, 1205 "path" : "/example-address:addresses" 1206 }, 1207 { 1208 "local-id" : 2, 1209 "path" : "/example-address:addresses/address" 1210 }, 1211 { 1212 "local-id" : 3, 1213 "path" : "/example-address:addresses/address/last" 1214 }, 1215 { 1216 "local-id" : 4, 1217 "path" : "/example-address:addresses/address/first" 1218 }, 1219 { 1220 "local-id" : 5, 1221 "path" : "/example-address:addresses/address/street" 1222 }, 1223 { 1224 "local-id" : 6, 1225 "path" : "/example-address:addresses/address/city" 1226 }, 1227 { 1228 "local-id" : 7, 1229 "path" : "/example-address:addresses/address/zipcode" 1230 } 1231 ] 1232 } 1233 } 1234 } 1236 B.3. Augment Numbering Example 1238 In this example, manually assigned local-id values are given to the 1239 following "example-phone" module: 1241 module example-phone { 1242 namespace "http://example.com/ns/example-phone"; 1243 prefix "exphone"; 1244 import example-address { prefix addr; } 1245 revision 2016-08-05; 1247 augment "/addr:addresses/addr:address" { 1248 container phones { 1249 list phone { 1250 key "prefix number"; 1251 leaf prefix { type string; } 1252 leaf number { type string; } 1253 leaf type { type phone-type; } 1254 } 1255 } 1256 } 1257 } 1259 The following local-id mappings are defined in this example. 1261 1 /example-address:addresses/address/example-phone:phones 1262 2 /example-address:addresses/address/example-phone:phones\ 1263 /phone 1264 3 /example-address:addresses/address/example-phone:phones\ 1265 /phone/prefix 1266 4 /example-address:addresses/address/example-phone:phones\ 1267 /phone/number 1268 5 /example-address:addresses/address/example-phone:phones\ 1269 /phone/type 1271 If the 'module-id' value '24' is assigned, and the 'local-bits' value 1272 is '16', then the following YANG Identifier values would be assigned 1273 for these local-id values: 1275 0x180001 /example-address:addresses/address/example-phone:phones 1276 0x180002 /example-address:addresses/address/example-phone:phones\ 1277 /phone 1278 0x180003 /example-address:addresses/address/example-phone:phones\ 1279 /phone/prefix 1280 0x180004 /example-address:addresses/address/example-phone:phones\ 1281 /phone/number 1282 0x180005 /example-address:addresses/address/example-phone:phones\ 1283 /phone/type 1285 The example YANG Identifier (YID) file contents are shown below. 1287 { "module" : [ 1288 { 1289 "module-id" : 24, 1290 "name" : "example-phone", 1291 "revision" : 0x7e00801, 1292 "local-type" : "manual", 1293 "mapping" : [ 1294 { 1295 "local-id" : 1, 1296 "path" : "/example-address:addresses/address\ 1297 /example-phone:phones" 1298 }, 1299 { 1300 "local-id" : 2, 1301 "path" : "/example-address:addresses/address\ 1302 /example-phone:phones/phone" 1303 }, 1304 { 1305 "local-id" : 3, 1306 "path" : "/example-address:addresses/address\ 1307 /example-phone:phones/phone/prefix" 1308 }, 1309 { 1310 "local-id" : 4, 1311 "path" : "/example-address:addresses/address\ 1312 /example-phone:phones/phone/number" 1313 }, 1314 { 1315 "local-id" : 5, 1316 "path" : "/example-address:addresses/address\ 1317 /example-phone:phones/phone/type" 1318 } 1319 ] 1320 } 1321 } 1322 } 1324 Appendix C. YANG Hash Examples 1326 The YANG translation of the SMIv2 module specifying the 1327 ipNetToMediaTable [RFC4293] yields: 1329 container IP-MIB { 1330 container ipNetToPhysicalTable { 1331 list ipNetToPhysicalEntry { 1332 key "ipNetToPhysicalIfIndex 1333 ipNetToPhysicalNetAddressType 1334 ipNetToPhysicalNetAddress"; 1335 leaf ipNetToMediaIfIndex { 1336 type: int32; 1337 } 1338 leaf ipNetToPhysicalIfIndex { 1339 type if-mib:InterfaceIndex; 1340 } 1341 leaf ipNetToPhysicalNetAddressType { 1342 type inet-address:InetAddressType; 1343 } 1344 leaf ipNetToPhysicalNetAddress { 1345 type inet-address:InetAddress; 1346 } 1347 leaf ipNetToPhysicalPhysAddress { 1348 type yang:phys-address { 1349 length "0..65535"; 1350 } 1351 } 1352 leaf ipNetToPhysicalLastUpdated { 1353 type yang:timestamp; 1354 } 1355 leaf ipNetToPhysicalType { 1356 type enumeration { ... } 1357 } 1358 leaf ipNetToPhysicalState { 1359 type enumeration { ... } 1360 } 1361 leaf ipNetToPhysicalRowStatus { 1362 type snmpv2-tc:RowStatus; 1363 } 1364 } 1365 } 1367 The YANG hash values for 'ipNetToPhysicalEntry' and its child nodes 1368 are calculated by constructing the schema node identifier for the 1369 objects, and then calculating the 30 bit murmur3 hash values (shown 1370 in parenthesis): 1372 /IP-MIB:IP-MIB/ipNetToPhysicalTable (0x0aba15cc) 1373 /IP-MIB:IP-MIB/ipNetToPhysicalTable/ipNetToPhysicalEntry 1374 (0xo6aaddbc) 1375 /IP-MIB:IP-MIB/ipNetToPhysicalTable/ipNetToPhysicalEntry\ 1376 /ipNetToPhysicalIfIndex (0x346b3071) 1377 /IP-MIB:IP-MIB/ipNetToPhysicalTable/ipNetToPhysicalEntry\ 1378 /ipNetToPhysicalNetAddressType (0x3650bb64) 1379 /IP-MIB:IP-MIB/ipNetToPhysicalTable/ipNetToPhysicalEntry\ 1380 /ipNetToPhysicalNetAddress (0x06fd4d91) 1381 /IP-MIB/ipNetToPhysicalTable/ipNetToPhysicalEntry\ 1382 /ipNetToPhysicalPhysAddress (0x26180bcb) 1383 /IP-MIB:IP-MIB/ipNetToPhysicalTable/ipNetToPhysicalEntry\ 1384 /ipNetToPhysicalLastUpdated (0x3d6bbe90) 1385 /IP-MIB:IP-MIB/ipNetToPhysicalTable/ipNetToPhysicalEntry\ 1386 /ipNetToPhysicalType (0x35ecbb3d) 1387 /IP-MIB:IP-MIB/ipNetToPhysicalTable/ipNetToPhysicalEntry\ 1388 /ipNetToPhysicalState (0x13038bb5) 1389 /IP-MIB:IP-MIB/ipNetToPhysicalTable/ipNetToPhysicalEntry\ 1390 /ipNetToPhysicalRowStatus (0x09e1fa37) 1392 The example YANG Identifier (YID) file contents are shown below. 1393 Note that there are no hash collisions so there are no local 1394 identifiers assigned. This is expected to be the typical case. 1396 { "module" : [ 1397 { 1398 "module-id" : 25, 1399 "name" : "IP-MIB", 1400 "revision" : 0x7d60202, 1401 "local-type" : "hash" 1402 } 1403 ] 1404 } 1406 If the 'module-id' value '25' is assigned, and the 'local-bits' value 1407 is '16', then the following YANG Identifier values would be assigned 1408 for these local-id values (only the terminal node is shown since they 1409 are unique in SMIv2). Note that only 15 bits of the 30 bit hash 1410 value are used. The 16th bit is reserved to identify manually 1411 assigned rehash entries. 1413 0x1915cc ipNetToPhysicalTable 1414 0x195dbc ipNetToPhysicalEntry 1415 0x193071 ipNetToPhysicalIfIndex 1416 0x193b64 ipNetToPhysicalNetAddressType 1417 0x194d91 ipNetToPhysicalNetAddress 1418 0x190bcb ipNetToPhysicalPhysAddress 1419 0x193e90 ipNetToPhysicalLastUpdated 1420 0x193b3d ipNetToPhysicalType 1421 0x190bb5 ipNetToPhysicalState 1422 0x197a37 ipNetToPhysicalRowStatus 1424 Authors' Addresses 1426 Andy Bierman 1427 YumaWorks, Inc. 1428 685 Cochran St. 1429 Suite #160 1430 Simi Valley, CA 93065 1431 USA 1433 Email: andy@yumaworks.com 1435 Peter van der Stok 1436 consultant 1438 Phone: +31-492474673 (Netherlands), +33-966015248 (France) 1439 Email: consultancy@vanderstok.org 1440 URI: www.vanderstok.org