idnits 2.17.1 draft-schoenw-netmod-rfc6991-bis-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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 27, 2019) is 1882 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'XPATH' -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Schoenwaelder, Ed. 3 Internet-Draft Jacobs University 4 Obsoletes: 6991 (if approved) February 27, 2019 5 Intended status: Standards Track 6 Expires: August 31, 2019 8 Common YANG Data Types 9 draft-schoenw-netmod-rfc6991-bis-00 11 Abstract 13 This document introduces a collection of common data types to be used 14 with the YANG data modeling language. This document obsoletes RFC 15 6991. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on August 31, 2019. 34 Copyright Notice 36 Copyright (c) 2019 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 This document may contain material from IETF Documents or IETF 50 Contributions published or made publicly available before November 51 10, 2008. The person(s) controlling the copyright in some of this 52 material may not have granted the IETF Trust the right to allow 53 modifications of such material outside the IETF Standards Process. 54 Without obtaining an adequate license from the person(s) controlling 55 the copyright in such materials, this document may not be modified 56 outside the IETF Standards Process, and derivative works of it may 57 not be created outside the IETF Standards Process, except to format 58 it for publication as an RFC or to translate it into languages other 59 than English. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Core YANG Derived Types . . . . . . . . . . . . . . . . . . . 6 66 4. Internet-Specific Derived Types . . . . . . . . . . . . . . . 17 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 69 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29 70 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 72 9.1. Normative References . . . . . . . . . . . . . . . . . . . 31 73 9.2. Informative References . . . . . . . . . . . . . . . . . . 32 74 Appendix A. Changes from RFC 6991 . . . . . . . . . . . . . . . . 36 75 Appendix B. Changes from RFC 6021 . . . . . . . . . . . . . . . . 37 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 38 78 1. Introduction 80 YANG [RFC7950] is a data modeling language used to model 81 configuration and state data manipulated by the Network Configuration 82 Protocol (NETCONF) [RFC6241]. The YANG language supports a small set 83 of built-in data types and provides mechanisms to derive other types 84 from the built-in types. 86 This document introduces a collection of common data types derived 87 from the built-in YANG data types. The derived types are designed to 88 be applicable for modeling all areas of management information. The 89 definitions are organized in several YANG modules. The 90 "ietf-yang-types" module contains generally useful data types. The 91 "ietf-inet-types" module contains definitions that are relevant for 92 the Internet protocol suite. 94 This document adds new type definitions to the YANG modules and 95 obsoletes [RFC6991]. For further details, see the revision 96 statements of the YANG modules in Section 3 and Section 4 and the 97 summary in Appendix A. 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 101 "OPTIONAL" in this document are to be interpreted as described in BCP 102 14 [RFC2119]. 104 2. Overview 106 This section provides a short overview of the types defined in 107 subsequent sections and their equivalent Structure of Management 108 Information Version 2 (SMIv2) [RFC2578][RFC2579] data types. A YANG 109 data type is equivalent to an SMIv2 data type if the data types have 110 the same set of values and the semantics of the values are 111 equivalent. 113 Table 1 lists the types defined in the ietf-yang-types YANG module 114 and the corresponding SMIv2 types (- indicates there is no 115 corresponding SMIv2 type). 117 +-----------------------+--------------------------------+ 118 | YANG type | Equivalent SMIv2 type (module) | 119 +-----------------------+--------------------------------+ 120 | counter32 | Counter32 (SNMPv2-SMI) | 121 | zero-based-counter32 | ZeroBasedCounter32 (RMON2-MIB) | 122 | counter64 | Counter64 (SNMPv2-SMI) | 123 | zero-based-counter64 | ZeroBasedCounter64 (HCNUM-TC) | 124 | gauge32 | Gauge32 (SNMPv2-SMI) | 125 | gauge64 | CounterBasedGauge64 (HCNUM-TC) | 126 | object-identifier | - | 127 | object-identifier-128 | OBJECT IDENTIFIER | 128 | yang-identifier | - | 129 | date-and-time | - | 130 | timeticks | TimeTicks (SNMPv2-SMI) | 131 | timestamp | TimeStamp (SNMPv2-TC) | 132 | phys-address | PhysAddress (SNMPv2-TC) | 133 | mac-address | MacAddress (SNMPv2-TC) | 134 | xpath1.0 | - | 135 | hex-string | - | 136 | uuid | - | 137 | dotted-quad | - | 138 +-----------------------+--------------------------------+ 140 Table 1: ietf-yang-types 142 Table 2 lists the types defined in the ietf-inet-types YANG module 143 and the corresponding SMIv2 types (if any). 145 +----------------------+--------------------------------------------+ 146 | YANG type | Equivalent SMIv2 type (module) | 147 +----------------------+--------------------------------------------+ 148 | ip-version | InetVersion (INET-ADDRESS-MIB) | 149 | dscp | Dscp (DIFFSERV-DSCP-TC) | 150 | ipv6-flow-label | IPv6FlowLabel (IPV6-FLOW-LABEL-MIB) | 151 | port-number | InetPortNumber (INET-ADDRESS-MIB) | 152 | as-number | InetAutonomousSystemNumber | 153 | | (INET-ADDRESS-MIB) | 154 | ip-address | - | 155 | ipv4-address | - | 156 | ipv6-address | - | 157 | ip-address-no-zone | - | 158 | ipv4-address-no-zone | - | 159 | ipv6-address-no-zone | - | 160 | ip-prefix | - | 161 | ipv4-prefix | - | 162 | ipv6-prefix | - | 163 | domain-name | - | 164 | host | - | 165 | uri | Uri (URI-TC-MIB) | 166 +----------------------+--------------------------------------------+ 168 Table 2: ietf-inet-types 170 3. Core YANG Derived Types 172 The ietf-yang-types YANG module references [IEEE802], [ISO9834-1], 173 [RFC2578], [RFC2579], [RFC2856], [RFC3339], [RFC4122], [RFC4502], 174 [RFC7950], [XPATH], and [XSD-TYPES]. 176 file "ietf-yang-types@2019-02-27.yang" 178 module ietf-yang-types { 180 namespace "urn:ietf:params:xml:ns:yang:ietf-yang-types"; 181 prefix "yang"; 183 organization 184 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 186 contact 187 "WG Web: 188 WG List: 190 WG Chair: David Kessens 191 193 WG Chair: Juergen Schoenwaelder 194 196 Editor: Juergen Schoenwaelder 197 "; 199 description 200 "This module contains a collection of generally useful derived 201 YANG data types. 203 Copyright (c) 2019 IETF Trust and the persons identified as 204 authors of the code. All rights reserved. 206 Redistribution and use in source and binary forms, with or 207 without modification, is permitted pursuant to, and subject 208 to the license terms contained in, the Simplified BSD License 209 set forth in Section 4.c of the IETF Trust's Legal Provisions 210 Relating to IETF Documents 211 (http://trustee.ietf.org/license-info). 213 This version of this YANG module is part of RFC XXXX; see 214 the RFC itself for full legal notices."; 216 revision 2019-02-27 { 217 description 218 "This revision adds the following new data types: 219 - TBD"; 220 reference 221 "RFC XXXX: Common YANG Data Types"; 222 } 224 revision 2013-07-15 { 225 description 226 "This revision adds the following new data types: 227 - yang-identifier 228 - hex-string 229 - uuid 230 - dotted-quad"; 231 reference 232 "RFC 6991: Common YANG Data Types"; 233 } 235 revision 2010-09-24 { 236 description 237 "Initial revision."; 238 reference 239 "RFC 6021: Common YANG Data Types"; 240 } 242 /*** collection of counter and gauge types ***/ 244 typedef counter32 { 245 type uint32; 246 description 247 "The counter32 type represents a non-negative integer 248 that monotonically increases until it reaches a 249 maximum value of 2^32-1 (4294967295 decimal), when it 250 wraps around and starts increasing again from zero. 252 Counters have no defined 'initial' value, and thus, a 253 single value of a counter has (in general) no information 254 content. Discontinuities in the monotonically increasing 255 value normally occur at re-initialization of the 256 management system, and at other times as specified in the 257 description of a schema node using this type. If such 258 other times can occur, for example, the creation of 259 a schema node of type counter32 at times other than 260 re-initialization, then a corresponding schema node 261 should be defined, with an appropriate type, to indicate 262 the last discontinuity. 264 The counter32 type should not be used for configuration 265 schema nodes. A default statement SHOULD NOT be used in 266 combination with the type counter32. 268 In the value set and its semantics, this type is equivalent 269 to the Counter32 type of the SMIv2."; 270 reference 271 "RFC 2578: Structure of Management Information Version 2 272 (SMIv2)"; 273 } 275 typedef zero-based-counter32 { 276 type yang:counter32; 277 default "0"; 278 description 279 "The zero-based-counter32 type represents a counter32 280 that has the defined 'initial' value zero. 282 A schema node of this type will be set to zero (0) on creation 283 and will thereafter increase monotonically until it reaches 284 a maximum value of 2^32-1 (4294967295 decimal), when it 285 wraps around and starts increasing again from zero. 287 Provided that an application discovers a new schema node 288 of this type within the minimum time to wrap, it can use the 289 'initial' value as a delta. It is important for a management 290 station to be aware of this minimum time and the actual time 291 between polls, and to discard data if the actual time is too 292 long or there is no defined minimum time. 294 In the value set and its semantics, this type is equivalent 295 to the ZeroBasedCounter32 textual convention of the SMIv2."; 296 reference 297 "RFC 4502: Remote Network Monitoring Management Information 298 Base Version 2"; 299 } 301 typedef counter64 { 302 type uint64; 303 description 304 "The counter64 type represents a non-negative integer 305 that monotonically increases until it reaches a 306 maximum value of 2^64-1 (18446744073709551615 decimal), 307 when it wraps around and starts increasing again from zero. 309 Counters have no defined 'initial' value, and thus, a 310 single value of a counter has (in general) no information 311 content. Discontinuities in the monotonically increasing 312 value normally occur at re-initialization of the 313 management system, and at other times as specified in the 314 description of a schema node using this type. If such 315 other times can occur, for example, the creation of 316 a schema node of type counter64 at times other than 317 re-initialization, then a corresponding schema node 318 should be defined, with an appropriate type, to indicate 319 the last discontinuity. 321 The counter64 type should not be used for configuration 322 schema nodes. A default statement SHOULD NOT be used in 323 combination with the type counter64. 325 In the value set and its semantics, this type is equivalent 326 to the Counter64 type of the SMIv2."; 327 reference 328 "RFC 2578: Structure of Management Information Version 2 329 (SMIv2)"; 330 } 332 typedef zero-based-counter64 { 333 type yang:counter64; 334 default "0"; 335 description 336 "The zero-based-counter64 type represents a counter64 that 337 has the defined 'initial' value zero. 339 A schema node of this type will be set to zero (0) on creation 340 and will thereafter increase monotonically until it reaches 341 a maximum value of 2^64-1 (18446744073709551615 decimal), 342 when it wraps around and starts increasing again from zero. 344 Provided that an application discovers a new schema node 345 of this type within the minimum time to wrap, it can use the 346 'initial' value as a delta. It is important for a management 347 station to be aware of this minimum time and the actual time 348 between polls, and to discard data if the actual time is too 349 long or there is no defined minimum time. 351 In the value set and its semantics, this type is equivalent 352 to the ZeroBasedCounter64 textual convention of the SMIv2."; 353 reference 354 "RFC 2856: Textual Conventions for Additional High Capacity 355 Data Types"; 356 } 358 typedef gauge32 { 359 type uint32; 360 description 361 "The gauge32 type represents a non-negative integer, which 362 may increase or decrease, but shall never exceed a maximum 363 value, nor fall below a minimum value. The maximum value 364 cannot be greater than 2^32-1 (4294967295 decimal), and 365 the minimum value cannot be smaller than 0. The value of 366 a gauge32 has its maximum value whenever the information 367 being modeled is greater than or equal to its maximum 368 value, and has its minimum value whenever the information 369 being modeled is smaller than or equal to its minimum value. 370 If the information being modeled subsequently decreases 371 below (increases above) the maximum (minimum) value, the 372 gauge32 also decreases (increases). 374 In the value set and its semantics, this type is equivalent 375 to the Gauge32 type of the SMIv2."; 376 reference 377 "RFC 2578: Structure of Management Information Version 2 378 (SMIv2)"; 379 } 381 typedef gauge64 { 382 type uint64; 383 description 384 "The gauge64 type represents a non-negative integer, which 385 may increase or decrease, but shall never exceed a maximum 386 value, nor fall below a minimum value. The maximum value 387 cannot be greater than 2^64-1 (18446744073709551615), and 388 the minimum value cannot be smaller than 0. The value of 389 a gauge64 has its maximum value whenever the information 390 being modeled is greater than or equal to its maximum 391 value, and has its minimum value whenever the information 392 being modeled is smaller than or equal to its minimum value. 393 If the information being modeled subsequently decreases 394 below (increases above) the maximum (minimum) value, the 395 gauge64 also decreases (increases). 397 In the value set and its semantics, this type is equivalent 398 to the CounterBasedGauge64 SMIv2 textual convention defined 399 in RFC 2856"; 400 reference 401 "RFC 2856: Textual Conventions for Additional High Capacity 402 Data Types"; 403 } 405 /*** collection of identifier-related types ***/ 407 typedef object-identifier { 408 type string { 409 pattern '(([0-1](\.[1-3]?[0-9]))|(2\.(0|([1-9]\d*))))' 410 + '(\.(0|([1-9]\d*)))*'; 411 } 412 description 413 "The object-identifier type represents administratively 414 assigned names in a registration-hierarchical-name tree. 416 Values of this type are denoted as a sequence of numerical 417 non-negative sub-identifier values. Each sub-identifier 418 value MUST NOT exceed 2^32-1 (4294967295). Sub-identifiers 419 are separated by single dots and without any intermediate 420 whitespace. 422 The ASN.1 standard restricts the value space of the first 423 sub-identifier to 0, 1, or 2. Furthermore, the value space 424 of the second sub-identifier is restricted to the range 425 0 to 39 if the first sub-identifier is 0 or 1. Finally, 426 the ASN.1 standard requires that an object identifier 427 has always at least two sub-identifiers. The pattern 428 captures these restrictions. 430 Although the number of sub-identifiers is not limited, 431 module designers should realize that there may be 432 implementations that stick with the SMIv2 limit of 128 433 sub-identifiers. 435 This type is a superset of the SMIv2 OBJECT IDENTIFIER type 436 since it is not restricted to 128 sub-identifiers. Hence, 437 this type SHOULD NOT be used to represent the SMIv2 OBJECT 438 IDENTIFIER type; the object-identifier-128 type SHOULD be 439 used instead."; 440 reference 441 "ISO9834-1: Information technology -- Open Systems 442 Interconnection -- Procedures for the operation of OSI 443 Registration Authorities: General procedures and top 444 arcs of the ASN.1 Object Identifier tree"; 445 } 447 typedef object-identifier-128 { 448 type object-identifier { 449 pattern '\d*(\.\d*){1,127}'; 450 } 451 description 452 "This type represents object-identifiers restricted to 128 453 sub-identifiers. 455 In the value set and its semantics, this type is equivalent 456 to the OBJECT IDENTIFIER type of the SMIv2."; 457 reference 458 "RFC 2578: Structure of Management Information Version 2 459 (SMIv2)"; 460 } 462 typedef yang-identifier { 463 type string { 464 length "1..max"; 465 pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*'; 466 pattern '.|..|[^xX].*|.[^mM].*|..[^lL].*'; 467 } 468 description 469 "A YANG identifier string as defined by the 'identifier' 470 rule in Section 12 of RFC 6020. An identifier must 471 start with an alphabetic character or an underscore 472 followed by an arbitrary sequence of alphabetic or 473 numeric characters, underscores, hyphens, or dots. 475 A YANG identifier MUST NOT start with any possible 476 combination of the lowercase or uppercase character 477 sequence 'xml'."; 478 reference 479 "RFC 6020: YANG - A Data Modeling Language for the Network 480 Configuration Protocol (NETCONF)"; 481 } 483 /*** collection of types related to date and time ***/ 485 typedef date-and-time { 486 type string { 487 pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?' 488 + '(Z|[\+\-]\d{2}:\d{2})'; 489 } 490 description 491 "The date-and-time type is a profile of the ISO 8601 492 standard for representation of dates and times using the 493 Gregorian calendar. The profile is defined by the 494 date-time production in Section 5.6 of RFC 3339. 496 The date-and-time type is compatible with the dateTime XML 497 schema type with the following notable exceptions: 499 (a) The date-and-time type does not allow negative years. 501 (b) The date-and-time time-offset -00:00 indicates an unknown 502 time zone (see RFC 3339) while -00:00 and +00:00 and Z 503 all represent the same time zone in dateTime. 505 (c) The canonical format (see below) of data-and-time values 506 differs from the canonical format used by the dateTime XML 507 schema type, which requires all times to be in UTC using 508 the time-offset 'Z'. 510 This type is not equivalent to the DateAndTime textual 511 convention of the SMIv2 since RFC 3339 uses a different 512 separator between full-date and full-time and provides 513 higher resolution of time-secfrac. 515 The canonical format for date-and-time values with a known time 516 zone uses a numeric time zone offset that is calculated using 517 the device's configured known offset to UTC time. A change of 518 the device's offset to UTC time will cause date-and-time values 519 to change accordingly. Such changes might happen periodically 520 in case a server follows automatically daylight saving time 521 (DST) time zone offset changes. The canonical format for 522 date-and-time values with an unknown time zone (usually 523 referring to the notion of local time) uses the time-offset 524 -00:00."; 525 reference 526 "RFC 3339: Date and Time on the Internet: Timestamps 527 RFC 2579: Textual Conventions for SMIv2 528 XSD-TYPES: XML Schema Part 2: Datatypes Second Edition"; 529 } 531 typedef timeticks { 532 type uint32; 533 description 534 "The timeticks type represents a non-negative integer that 535 represents the time, modulo 2^32 (4294967296 decimal), in 536 hundredths of a second between two epochs. When a schema 537 node is defined that uses this type, the description of 538 the schema node identifies both of the reference epochs. 540 In the value set and its semantics, this type is equivalent 541 to the TimeTicks type of the SMIv2."; 542 reference 543 "RFC 2578: Structure of Management Information Version 2 544 (SMIv2)"; 545 } 547 typedef timestamp { 548 type yang:timeticks; 549 description 550 "The timestamp type represents the value of an associated 551 timeticks schema node at which a specific occurrence 552 happened. The specific occurrence must be defined in the 553 description of any schema node defined using this type. When 554 the specific occurrence occurred prior to the last time the 555 associated timeticks attribute was zero, then the timestamp 556 value is zero. Note that this requires all timestamp values 557 to be reset to zero when the value of the associated timeticks 558 attribute reaches 497+ days and wraps around to zero. 560 The associated timeticks schema node must be specified 561 in the description of any schema node using this type. 563 In the value set and its semantics, this type is equivalent 564 to the TimeStamp textual convention of the SMIv2."; 565 reference 566 "RFC 2579: Textual Conventions for SMIv2"; 567 } 569 /*** collection of generic address types ***/ 571 typedef phys-address { 572 type string { 573 pattern '([0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*)?'; 574 } 575 description 576 "Represents media- or physical-level addresses represented 577 as a sequence octets, each octet represented by two hexadecimal 578 numbers. Octets are separated by colons. The canonical 579 representation uses lowercase characters. 581 In the value set and its semantics, this type is equivalent 582 to the PhysAddress textual convention of the SMIv2."; 583 reference 584 "RFC 2579: Textual Conventions for SMIv2"; 585 } 587 typedef mac-address { 588 type string { 589 pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}'; 590 } 591 description 592 "The mac-address type represents an IEEE 802 MAC address. 593 The canonical representation uses lowercase characters. 595 In the value set and its semantics, this type is equivalent 596 to the MacAddress textual convention of the SMIv2."; 597 reference 598 "IEEE 802: IEEE Standard for Local and Metropolitan Area 599 Networks: Overview and Architecture 600 RFC 2579: Textual Conventions for SMIv2"; 601 } 602 /*** collection of XML-specific types ***/ 604 typedef xpath1.0 { 605 type string; 606 description 607 "This type represents an XPATH 1.0 expression. 609 When a schema node is defined that uses this type, the 610 description of the schema node MUST specify the XPath 611 context in which the XPath expression is evaluated."; 612 reference 613 "XPATH: XML Path Language (XPath) Version 1.0"; 614 } 616 /*** collection of string types ***/ 618 typedef hex-string { 619 type string { 620 pattern '([0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*)?'; 621 } 622 description 623 "A hexadecimal string with octets represented as hex digits 624 separated by colons. The canonical representation uses 625 lowercase characters."; 626 } 628 typedef uuid { 629 type string { 630 pattern '[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-' 631 + '[0-9a-fA-F]{4}-[0-9a-fA-F]{12}'; 632 } 633 description 634 "A Universally Unique IDentifier in the string representation 635 defined in RFC 4122. The canonical representation uses 636 lowercase characters. 638 The following is an example of a UUID in string representation: 639 f81d4fae-7dec-11d0-a765-00a0c91e6bf6 640 "; 641 reference 642 "RFC 4122: A Universally Unique IDentifier (UUID) URN 643 Namespace"; 644 } 646 typedef dotted-quad { 647 type string { 648 pattern 649 '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}' 651 + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'; 652 } 653 description 654 "An unsigned 32-bit number expressed in the dotted-quad 655 notation, i.e., four octets written as decimal numbers 656 and separated with the '.' (full stop) character."; 657 } 658 } 660 662 4. Internet-Specific Derived Types 664 The ietf-inet-types YANG module references [RFC0768], [RFC0791], 665 [RFC0793], [RFC0952], [RFC1034], [RFC1123], [RFC1930], [RFC2460], 666 [RFC2474], [RFC2780], [RFC2782], [RFC3289], [RFC3305], [RFC3595], 667 [RFC3986], [RFC4001], [RFC4007], [RFC4271], [RFC4291], [RFC4340], 668 [RFC4960], [RFC5017], [RFC5890], [RFC5952], and [RFC6793]. 670 file "ietf-inet-types@2019-02-27.yang" 672 module ietf-inet-types { 674 namespace "urn:ietf:params:xml:ns:yang:ietf-inet-types"; 675 prefix "inet"; 677 organization 678 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 680 contact 681 "WG Web: 682 WG List: 684 WG Chair: David Kessens 685 687 WG Chair: Juergen Schoenwaelder 688 690 Editor: Juergen Schoenwaelder 691 "; 693 description 694 "This module contains a collection of generally useful derived 695 YANG data types for Internet addresses and related things. 697 Copyright (c) 2019 IETF Trust and the persons identified as 698 authors of the code. All rights reserved. 700 Redistribution and use in source and binary forms, with or 701 without modification, is permitted pursuant to, and subject 702 to the license terms contained in, the Simplified BSD License 703 set forth in Section 4.c of the IETF Trust's Legal Provisions 704 Relating to IETF Documents 705 (http://trustee.ietf.org/license-info). 707 This version of this YANG module is part of RFC XXXX; see 708 the RFC itself for full legal notices."; 710 revision 2019-02-27 { 711 description 712 "This revision adds the following new data types: 713 - TBD"; 714 reference 715 "RFC XXXX: Common YANG Data Types"; 716 } 718 revision 2013-07-15 { 719 description 720 "This revision adds the following new data types: 721 - ip-address-no-zone 722 - ipv4-address-no-zone 723 - ipv6-address-no-zone"; 724 reference 725 "RFC 6991: Common YANG Data Types"; 726 } 728 revision 2010-09-24 { 729 description 730 "Initial revision."; 731 reference 732 "RFC 6021: Common YANG Data Types"; 733 } 735 /*** collection of types related to protocol fields ***/ 737 typedef ip-version { 738 type enumeration { 739 enum unknown { 740 value "0"; 741 description 742 "An unknown or unspecified version of the Internet 743 protocol."; 744 } 745 enum ipv4 { 746 value "1"; 747 description 748 "The IPv4 protocol as defined in RFC 791."; 749 } 750 enum ipv6 { 751 value "2"; 752 description 753 "The IPv6 protocol as defined in RFC 2460."; 754 } 755 } 756 description 757 "This value represents the version of the IP protocol. 759 In the value set and its semantics, this type is equivalent 760 to the InetVersion textual convention of the SMIv2."; 761 reference 762 "RFC 791: Internet Protocol 763 RFC 2460: Internet Protocol, Version 6 (IPv6) Specification 764 RFC 4001: Textual Conventions for Internet Network Addresses"; 765 } 767 typedef dscp { 768 type uint8 { 769 range "0..63"; 770 } 771 description 772 "The dscp type represents a Differentiated Services Code Point 773 that may be used for marking packets in a traffic stream. 775 In the value set and its semantics, this type is equivalent 776 to the Dscp textual convention of the SMIv2."; 777 reference 778 "RFC 3289: Management Information Base for the Differentiated 779 Services Architecture 780 RFC 2474: Definition of the Differentiated Services Field 781 (DS Field) in the IPv4 and IPv6 Headers 782 RFC 2780: IANA Allocation Guidelines For Values In 783 the Internet Protocol and Related Headers"; 784 } 786 typedef ipv6-flow-label { 787 type uint32 { 788 range "0..1048575"; 789 } 790 description 791 "The ipv6-flow-label type represents the flow identifier or 792 Flow Label in an IPv6 packet header that may be used to 793 discriminate traffic flows. 795 In the value set and its semantics, this type is equivalent 796 to the IPv6FlowLabel textual convention of the SMIv2."; 797 reference 798 "RFC 3595: Textual Conventions for IPv6 Flow Label 799 RFC 2460: Internet Protocol, Version 6 (IPv6) Specification"; 800 } 802 typedef port-number { 803 type uint16 { 804 range "0..65535"; 805 } 806 description 807 "The port-number type represents a 16-bit port number of an 808 Internet transport-layer protocol such as UDP, TCP, DCCP, or 809 SCTP. Port numbers are assigned by IANA. A current list of 810 all assignments is available from . 812 Note that the port number value zero is reserved by IANA. In 813 situations where the value zero does not make sense, it can 814 be excluded by subtyping the port-number type. 816 In the value set and its semantics, this type is equivalent 817 to the InetPortNumber textual convention of the SMIv2."; 818 reference 819 "RFC 768: User Datagram Protocol 820 RFC 793: Transmission Control Protocol 821 RFC 4960: Stream Control Transmission Protocol 822 RFC 4340: Datagram Congestion Control Protocol (DCCP) 823 RFC 4001: Textual Conventions for Internet Network Addresses"; 824 } 826 /*** collection of types related to autonomous systems ***/ 828 typedef as-number { 829 type uint32; 830 description 831 "The as-number type represents autonomous system numbers 832 which identify an Autonomous System (AS). An AS is a set 833 of routers under a single technical administration, using 834 an interior gateway protocol and common metrics to route 835 packets within the AS, and using an exterior gateway 836 protocol to route packets to other ASes. IANA maintains 837 the AS number space and has delegated large parts to the 838 regional registries. 840 Autonomous system numbers were originally limited to 16 841 bits. BGP extensions have enlarged the autonomous system 842 number space to 32 bits. This type therefore uses an uint32 843 base type without a range restriction in order to support 844 a larger autonomous system number space. 846 In the value set and its semantics, this type is equivalent 847 to the InetAutonomousSystemNumber textual convention of 848 the SMIv2."; 849 reference 850 "RFC 1930: Guidelines for creation, selection, and registration 851 of an Autonomous System (AS) 852 RFC 4271: A Border Gateway Protocol 4 (BGP-4) 853 RFC 4001: Textual Conventions for Internet Network Addresses 854 RFC 6793: BGP Support for Four-Octet Autonomous System (AS) 855 Number Space"; 856 } 858 /*** collection of types related to IP addresses and hostnames ***/ 860 typedef ip-address { 861 type union { 862 type inet:ipv4-address; 863 type inet:ipv6-address; 864 } 865 description 866 "The ip-address type represents an IP address and is IP 867 version neutral. The format of the textual representation 868 implies the IP version. This type supports scoped addresses 869 by allowing zone identifiers in the address format."; 870 reference 871 "RFC 4007: IPv6 Scoped Address Architecture"; 872 } 874 typedef ipv4-address { 875 type string { 876 pattern 877 '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}' 878 + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])' 879 + '(%[\p{N}\p{L}]+)?'; 880 } 881 description 882 "The ipv4-address type represents an IPv4 address in 883 dotted-quad notation. The IPv4 address may include a zone 884 index, separated by a % sign. 886 The zone index is used to disambiguate identical address 887 values. For link-local addresses, the zone index will 888 typically be the interface index number or the name of an 889 interface. If the zone index is not present, the default 890 zone of the device will be used. 892 The canonical format for the zone index is the numerical 893 format"; 894 } 896 typedef ipv6-address { 897 type string { 898 pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}' 899 + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|' 900 + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}' 901 + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))' 902 + '(%[\p{N}\p{L}]+)?'; 904 pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|' 905 + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)' 906 + '(%.+)?'; 907 } 908 description 909 "The ipv6-address type represents an IPv6 address in full, 910 mixed, shortened, and shortened-mixed notation. The IPv6 911 address may include a zone index, separated by a % sign. 913 The zone index is used to disambiguate identical address 914 values. For link-local addresses, the zone index will 915 typically be the interface index number or the name of an 916 interface. If the zone index is not present, the default 917 zone of the device will be used. 919 The canonical format of IPv6 addresses uses the textual 920 representation defined in Section 4 of RFC 5952. The 921 canonical format for the zone index is the numerical 922 format as described in Section 11.2 of RFC 4007."; 923 reference 924 "RFC 4291: IP Version 6 Addressing Architecture 925 RFC 4007: IPv6 Scoped Address Architecture 926 RFC 5952: A Recommendation for IPv6 Address Text 927 Representation"; 928 } 930 typedef ip-address-no-zone { 931 type union { 932 type inet:ipv4-address-no-zone; 933 type inet:ipv6-address-no-zone; 934 } 935 description 936 "The ip-address-no-zone type represents an IP address and is 937 IP version neutral. The format of the textual representation 938 implies the IP version. This type does not support scoped 939 addresses since it does not allow zone identifiers in the 940 address format."; 941 reference 942 "RFC 4007: IPv6 Scoped Address Architecture"; 943 } 945 typedef ipv4-address-no-zone { 946 type inet:ipv4-address { 947 pattern '[0-9\.]*'; 948 } 949 description 950 "An IPv4 address without a zone index. This type, derived from 951 ipv4-address, may be used in situations where the zone is known 952 from the context and hence no zone index is needed."; 953 } 955 typedef ipv6-address-no-zone { 956 type inet:ipv6-address { 957 pattern '[0-9a-fA-F:\.]*'; 958 } 959 description 960 "An IPv6 address without a zone index. This type, derived from 961 ipv6-address, may be used in situations where the zone is known 962 from the context and hence no zone index is needed."; 963 reference 964 "RFC 4291: IP Version 6 Addressing Architecture 965 RFC 4007: IPv6 Scoped Address Architecture 966 RFC 5952: A Recommendation for IPv6 Address Text 967 Representation"; 968 } 970 typedef ip-prefix { 971 type union { 972 type inet:ipv4-prefix; 973 type inet:ipv6-prefix; 974 } 975 description 976 "The ip-prefix type represents an IP prefix and is IP 977 version neutral. The format of the textual representations 978 implies the IP version."; 979 } 981 typedef ipv4-prefix { 982 type string { 983 pattern 984 '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}' 985 + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])' 986 + '/(([0-9])|([1-2][0-9])|(3[0-2]))'; 987 } 988 description 989 "The ipv4-prefix type represents an IPv4 address prefix. 990 The prefix length is given by the number following the 991 slash character and must be less than or equal to 32. 993 A prefix length value of n corresponds to an IP address 994 mask that has n contiguous 1-bits from the most 995 significant bit (MSB) and all other bits set to 0. 997 The canonical format of an IPv4 prefix has all bits of 998 the IPv4 address set to zero that are not part of the 999 IPv4 prefix."; 1001 } 1003 typedef ipv6-prefix { 1004 type string { 1005 pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}' 1006 + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|' 1007 + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}' 1008 + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))' 1009 + '(/(([0-9])|([0-9]{2})|(1[0-1][0-9])|(12[0-8])))'; 1010 pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|' 1011 + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)' 1012 + '(/.+)'; 1013 } 1014 description 1015 "The ipv6-prefix type represents an IPv6 address prefix. 1016 The prefix length is given by the number following the 1017 slash character and must be less than or equal to 128. 1019 A prefix length value of n corresponds to an IP address 1020 mask that has n contiguous 1-bits from the most 1021 significant bit (MSB) and all other bits set to 0. 1023 The IPv6 address should have all bits that do not belong 1024 to the prefix set to zero. 1026 The canonical format of an IPv6 prefix has all bits of 1027 the IPv6 address set to zero that are not part of the 1028 IPv6 prefix. Furthermore, the IPv6 address is represented 1029 as defined in Section 4 of RFC 5952."; 1030 reference 1031 "RFC 5952: A Recommendation for IPv6 Address Text 1032 Representation"; 1033 } 1035 /*** collection of domain name and URI types ***/ 1037 typedef domain-name { 1038 type string { 1039 length "1..253"; 1040 pattern 1041 '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*' 1042 + '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)' 1043 + '|\.'; 1044 } 1045 description 1046 "The domain-name type represents a DNS domain name. The 1047 name SHOULD be fully qualified whenever possible. 1049 Internet domain names are only loosely specified. Section 1050 3.5 of RFC 1034 recommends a syntax (modified in Section 1051 2.1 of RFC 1123). The pattern above is intended to allow 1052 for current practice in domain name use, and some possible 1053 future expansion. It is designed to hold various types of 1054 domain names, including names used for A or AAAA records 1055 (host names) and other records, such as SRV records. Note 1056 that Internet host names have a stricter syntax (described 1057 in RFC 952) than the DNS recommendations in RFCs 1034 and 1058 1123, and that systems that want to store host names in 1059 schema nodes using the domain-name type are recommended to 1060 adhere to this stricter standard to ensure interoperability. 1062 The encoding of DNS names in the DNS protocol is limited 1063 to 255 characters. Since the encoding consists of labels 1064 prefixed by a length bytes and there is a trailing NULL 1065 byte, only 253 characters can appear in the textual dotted 1066 notation. 1068 The description clause of schema nodes using the domain-name 1069 type MUST describe when and how these names are resolved to 1070 IP addresses. Note that the resolution of a domain-name value 1071 may require to query multiple DNS records (e.g., A for IPv4 1072 and AAAA for IPv6). The order of the resolution process and 1073 which DNS record takes precedence can either be defined 1074 explicitly or may depend on the configuration of the 1075 resolver. 1077 Domain-name values use the US-ASCII encoding. Their canonical 1078 format uses lowercase US-ASCII characters. Internationalized 1079 domain names MUST be A-labels as per RFC 5890."; 1080 reference 1081 "RFC 952: DoD Internet Host Table Specification 1082 RFC 1034: Domain Names - Concepts and Facilities 1083 RFC 1123: Requirements for Internet Hosts -- Application 1084 and Support 1085 RFC 2782: A DNS RR for specifying the location of services 1086 (DNS SRV) 1087 RFC 5890: Internationalized Domain Names in Applications 1088 (IDNA): Definitions and Document Framework"; 1089 } 1091 typedef host { 1092 type union { 1093 type inet:ip-address; 1094 type inet:domain-name; 1095 } 1096 description 1097 "The host type represents either an IP address or a DNS 1098 domain name."; 1099 } 1101 typedef uri { 1102 type string; 1103 description 1104 "The uri type represents a Uniform Resource Identifier 1105 (URI) as defined by STD 66. 1107 Objects using the uri type MUST be in US-ASCII encoding, 1108 and MUST be normalized as described by RFC 3986 Sections 1109 6.2.1, 6.2.2.1, and 6.2.2.2. All unnecessary 1110 percent-encoding is removed, and all case-insensitive 1111 characters are set to lowercase except for hexadecimal 1112 digits, which are normalized to uppercase as described in 1113 Section 6.2.2.1. 1115 The purpose of this normalization is to help provide 1116 unique URIs. Note that this normalization is not 1117 sufficient to provide uniqueness. Two URIs that are 1118 textually distinct after this normalization may still be 1119 equivalent. 1121 Objects using the uri type may restrict the schemes that 1122 they permit. For example, 'data:' and 'urn:' schemes 1123 might not be appropriate. 1125 A zero-length URI is not a valid URI. This can be used to 1126 express 'URI absent' where required. 1128 In the value set and its semantics, this type is equivalent 1129 to the Uri SMIv2 textual convention defined in RFC 5017."; 1130 reference 1131 "RFC 3986: Uniform Resource Identifier (URI): Generic Syntax 1132 RFC 3305: Report from the Joint W3C/IETF URI Planning Interest 1133 Group: Uniform Resource Identifiers (URIs), URLs, 1134 and Uniform Resource Names (URNs): Clarifications 1135 and Recommendations 1136 RFC 5017: MIB Textual Conventions for Uniform Resource 1137 Identifiers (URIs)"; 1138 } 1140 } 1142 1144 5. IANA Considerations 1146 This document registers two URIs in the IETF XML registry [RFC3688]. 1147 Following the format in RFC 3688, the following registrations have 1148 been made. 1150 URI: urn:ietf:params:xml:ns:yang:ietf-yang-types 1151 Registrant Contact: The NETMOD WG of the IETF. 1152 XML: N/A, the requested URI is an XML namespace. 1154 URI: urn:ietf:params:xml:ns:yang:ietf-inet-types 1155 Registrant Contact: The NETMOD WG of the IETF. 1156 XML: N/A, the requested URI is an XML namespace. 1158 This document registers two YANG modules in the YANG Module Names 1159 registry [RFC6020]. 1161 name: ietf-yang-types 1162 namespace: urn:ietf:params:xml:ns:yang:ietf-yang-types 1163 prefix: yang 1164 reference: RFC XXXX 1166 name: ietf-inet-types 1167 namespace: urn:ietf:params:xml:ns:yang:ietf-inet-types 1168 prefix: inet 1169 reference: RFC XXXX 1171 6. Security Considerations 1173 This document defines common data types using the YANG data modeling 1174 language. The definitions themselves have no security impact on the 1175 Internet, but the usage of these definitions in concrete YANG modules 1176 might have. The security considerations spelled out in the YANG 1177 specification [RFC7950] apply for this document as well. 1179 7. Contributors 1181 The following people contributed significantly to the initial version 1182 of this document: 1184 - Andy Bierman (Brocade) 1185 - Martin Bjorklund (Tail-f Systems) 1186 - Balazs Lengyel (Ericsson) 1187 - David Partain (Ericsson) 1188 - Phil Shafer (Juniper Networks) 1190 8. Acknowledgments 1192 The editor wishes to thank the following individuals for providing 1193 helpful comments on various versions of this document: Andy Bierman, 1194 Martin Bjorklund, Benoit Claise, Joel M. Halpern, Ladislav Lhotka, 1195 Lars-Johan Liman, and Dan Romascanu. 1197 Juergen Schoenwaelder was partly funded by Flamingo, a Network of 1198 Excellence project (ICT-318488) supported by the European Commission 1199 under its Seventh Framework Programme. 1201 9. References 1203 9.1. Normative References 1205 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1206 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1207 RFC2119, March 1997, 1208 . 1210 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 1211 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 1212 . 1214 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1215 DOI 10.17487/RFC3688, January 2004, 1216 . 1218 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1219 Resource Identifier (URI): Generic Syntax", STD 66, 1220 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1221 . 1223 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 1224 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 1225 DOI 10.17487/RFC4007, March 2005, 1226 . 1228 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1229 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1230 DOI 10.17487/RFC4122, July 2005, 1231 . 1233 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1234 Architecture", RFC 4291, DOI 10.17487/RFC4291, 1235 February 2006, . 1237 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1238 the Network Configuration Protocol (NETCONF)", RFC 6020, 1239 DOI 10.17487/RFC6020, October 2010, 1240 . 1242 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1243 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1244 . 1246 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1247 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1248 . 1250 [XPATH] Clark, J. and S. DeRose, "XML Path Language (XPath) 1251 Version 1.0", World Wide Web Consortium 1252 Recommendation REC-xpath-19991116, November 1999, 1253 . 1255 9.2. Informative References 1257 [IEEE802] IEEE, "IEEE Standard for Local and Metropolitan Area 1258 Networks: Overview and Architecture", IEEE Std. 802-2001. 1260 [ISO9834-1] 1261 ISO/IEC, "Information technology -- Open Systems 1262 Interconnection -- Procedures for the operation of OSI 1263 Registration Authorities: General procedures and top arcs 1264 of the ASN.1 Object Identifier tree", ISO/IEC 9834-1:2008, 1265 2008. 1267 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1268 DOI 10.17487/RFC0768, August 1980, 1269 . 1271 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1272 DOI 10.17487/RFC0791, September 1981, 1273 . 1275 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1276 RFC 793, DOI 10.17487/RFC0793, September 1981, 1277 . 1279 [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet 1280 host table specification", RFC 952, DOI 10.17487/RFC0952, 1281 October 1985, . 1283 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1284 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1285 . 1287 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 1288 Application and Support", STD 3, RFC 1123, DOI 10.17487/ 1289 RFC1123, October 1989, 1290 . 1292 [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, 1293 selection, and registration of an Autonomous System (AS)", 1294 BCP 6, RFC 1930, DOI 10.17487/RFC1930, March 1996, 1295 . 1297 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1298 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1299 December 1998, . 1301 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1302 "Definition of the Differentiated Services Field (DS 1303 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1304 DOI 10.17487/RFC2474, December 1998, 1305 . 1307 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1308 Schoenwaelder, Ed., "Structure of Management Information 1309 Version 2 (SMIv2)", STD 58, RFC 2578, DOI 10.17487/ 1310 RFC2578, April 1999, 1311 . 1313 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1314 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 1315 STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999, 1316 . 1318 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 1319 Values In the Internet Protocol and Related Headers", 1320 BCP 37, RFC 2780, DOI 10.17487/RFC2780, March 2000, 1321 . 1323 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1324 specifying the location of services (DNS SRV)", RFC 2782, 1325 DOI 10.17487/RFC2782, February 2000, 1326 . 1328 [RFC2856] Bierman, A., McCloghrie, K., and R. Presuhn, "Textual 1329 Conventions for Additional High Capacity Data Types", 1330 RFC 2856, DOI 10.17487/RFC2856, June 2000, 1331 . 1333 [RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information 1334 Base for the Differentiated Services Architecture", 1335 RFC 3289, DOI 10.17487/RFC3289, May 2002, 1336 . 1338 [RFC3305] Mealling, M., Ed. and R. Denenberg, Ed., "Report from the 1339 Joint W3C/IETF URI Planning Interest Group: Uniform 1340 Resource Identifiers (URIs), URLs, and Uniform Resource 1341 Names (URNs): Clarifications and Recommendations", 1342 RFC 3305, DOI 10.17487/RFC3305, August 2002, 1343 . 1345 [RFC3595] Wijnen, B., "Textual Conventions for IPv6 Flow Label", 1346 RFC 3595, DOI 10.17487/RFC3595, September 2003, 1347 . 1349 [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. 1350 Schoenwaelder, "Textual Conventions for Internet Network 1351 Addresses", RFC 4001, DOI 10.17487/RFC4001, February 2005, 1352 . 1354 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1355 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1356 DOI 10.17487/RFC4271, January 2006, 1357 . 1359 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1360 Congestion Control Protocol (DCCP)", RFC 4340, 1361 DOI 10.17487/RFC4340, March 2006, 1362 . 1364 [RFC4502] Waldbusser, S., "Remote Network Monitoring Management 1365 Information Base Version 2", RFC 4502, DOI 10.17487/ 1366 RFC4502, May 2006, 1367 . 1369 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1370 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1371 . 1373 [RFC5017] McWalter, D., Ed., "MIB Textual Conventions for Uniform 1374 Resource Identifiers (URIs)", RFC 5017, DOI 10.17487/ 1375 RFC5017, September 2007, 1376 . 1378 [RFC5890] Klensin, J., "Internationalized Domain Names for 1379 Applications (IDNA): Definitions and Document Framework", 1380 RFC 5890, DOI 10.17487/RFC5890, August 2010, 1381 . 1383 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1384 Address Text Representation", RFC 5952, DOI 10.17487/ 1385 RFC5952, August 2010, 1386 . 1388 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1389 and A. Bierman, Ed., "Network Configuration Protocol 1390 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1391 . 1393 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 1394 Autonomous System (AS) Number Space", RFC 6793, 1395 DOI 10.17487/RFC6793, December 2012, 1396 . 1398 [XSD-TYPES] 1399 Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes 1400 Second Edition", World Wide Web Consortium 1401 Recommendation REC-xmlschema-2-20041028, October 2004, 1402 . 1404 Appendix A. Changes from RFC 6991 1405 Appendix B. Changes from RFC 6021 1407 This version adds new type definitions to the YANG modules. The 1408 following new data types have been added to the ietf-yang-types 1409 module: 1411 o yang-identifier 1413 o hex-string 1415 o uuid 1417 o dotted-quad 1419 The following new data types have been added to the ietf-inet-types 1420 module: 1422 o ip-address-no-zone 1424 o ipv4-address-no-zone 1426 o ipv6-address-no-zone 1428 Author's Address 1430 Juergen Schoenwaelder (editor) 1431 Jacobs University 1433 Email: j.schoenwaelder@jacobs-university.de