idnits 2.17.1 draft-ietf-netmod-rfc6991-bis-13.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 2 instances 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 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 (March 22, 2022) is 759 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 4960 (Obsoleted by RFC 9260) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 4 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) March 22, 2022 5 Intended status: Standards Track 6 Expires: September 23, 2022 8 Common YANG Data Types 9 draft-ietf-netmod-rfc6991-bis-13 11 Abstract 13 This document defines 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 https://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 September 23, 2022. 34 Copyright Notice 36 Copyright (c) 2022 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Core YANG Derived Types . . . . . . . . . . . . . . . . . . . 6 66 4. Internet-Specific Derived Types . . . . . . . . . . . . . . . 21 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 35 69 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 71 8.1. Normative References . . . . . . . . . . . . . . . . . . 36 72 8.2. Informative References . . . . . . . . . . . . . . . . . 37 73 Appendix A. Changes from RFC 6991 . . . . . . . . . . . . . . . 41 74 Appendix B. Changes from RFC 6021 . . . . . . . . . . . . . . . 41 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 41 77 1. Introduction 79 YANG [RFC7950] is a data modeling language used to model 80 configuration and state data manipulated by the Network Configuration 81 Protocol (NETCONF) [RFC6241]. The YANG language supports a small set 82 of built-in data types and provides mechanisms to derive other types 83 from the built-in types. 85 This document introduces a collection of common data types derived 86 from the built-in YANG data types. The derived types are designed to 87 be applicable for modeling all areas of management information. The 88 definitions are organized in two YANG modules. The "ietf-yang-types" 89 module contains generally useful data types. The "ietf-inet-types" 90 module contains definitions that are relevant for the Internet 91 protocol suite. 93 This document adds new type definitions to these YANG modules and 94 obsoletes [RFC6991]. For further details, see the revision 95 statements of the YANG modules in Section 3 and Section 4 and the 96 summary in Appendix A. 98 This document uses the YANG terminology defined in Section 3 of 99 [RFC7950]. 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 103 "OPTIONAL" in this document are to be interpreted as described in BCP 104 14 [RFC2119] [RFC8174] when, and only when, they appear in all 105 capitals, as shown here. 107 2. Overview 109 Table 1 and Table 2 list the types defined in the YANG modules 110 "ietf-yang-types" and "ietf-inet-types". For each type, the name of 111 the type, the base type it was derived from, and the RFC introducing 112 the type is listed. 114 +-----------------------+-------------------+------------+ 115 | Type | Base Type | Introduced | 116 +-----------------------+-------------------+------------+ 117 | counter32 | uint32 | RFC 6021 | 118 | zero-based-counter32 | uint32 | RFC 6021 | 119 | counter64 | uint64 | RFC 6021 | 120 | zero-based-counter64 | uint64 | RFC 6021 | 121 | gauge32 | uint32 | RFC 6021 | 122 | gauge64 | uint64 | RFC 6021 | 123 | object-identifier | string | RFC 6021 | 124 | object-identifier-128 | object-identifier | RFC 6021 | 125 | date-and-time | string | RFC 6021 | 126 | date | string | RFC XXXX | 127 | date-no-zone | string | RFC XXXX | 128 | time | string | RFC XXXX | 129 | time-no-zone | string | RFC XXXX | 130 | hours32 | int32 | RFC XXXX | 131 | minutes32 | int32 | RFC XXXX | 132 | seconds32 | int32 | RFC XXXX | 133 | centiseconds32 | int32 | RFC XXXX | 134 | milliseconds32 | int32 | RFC XXXX | 135 | microseconds32 | int32 | RFC XXXX | 136 | microseconds64 | int64 | RFC XXXX | 137 | nanoseconds32 | int32 | RFC XXXX | 138 | nanoseconds64 | int64 | RFC XXXX | 139 | timeticks | int32 | RFC 6021 | 140 | timestamp | timeticks | RFC 6021 | 141 | phys-address | string | RFC 6021 | 142 | mac-address | string | RFC 6021 | 143 | xpath1.0 | string | RFC 6021 | 144 | hex-string | string | RFC 6991 | 145 | uuid | string | RFC 6991 | 146 | dotted-quad | string | RFC 6991 | 147 | yang-identifier | string | RFC 6991 | 148 +-----------------------+-------------------+------------+ 150 Table 1: Types defined in ietf-yang-types 152 +-------------------------+--------------+------------+ 153 | Type | Base Type | Introduced | 154 +-------------------------+--------------+------------+ 155 | ip-version | enum | RFC 6021 | 156 | dscp | uint8 | RFC 6021 | 157 | ipv6-flow-label | uint32 | RFC 6021 | 158 | port-number | uint16 | RFC 6021 | 159 | protocol-number | uint8 | RFC XXXX | 160 | as-number | uint32 | RFC 6021 | 161 | ip-address | union | RFC 6021 | 162 | ipv4-address | string | RFC 6021 | 163 | ipv6-address | string | RFC 6021 | 164 | ip-address-no-zone | union | RFC 6991 | 165 | ipv4-address-no-zone | ipv4-address | RFC 6991 | 166 | ipv6-address-no-zone | ipv6-address | RFC 6991 | 167 | ip-address-link-local | union | RFC XXXX | 168 | ipv4-address-link-local | ipv4-address | RFC XXXX | 169 | ipv6-address-link-local | ipv6-address | RFC XXXX | 170 | ip-prefix | union | RFC 6021 | 171 | ipv4-prefix | string | RFC 6021 | 172 | ipv6-prefix | string | RFC 6021 | 173 | ip-address-and-prefix | union | RFC XXXX | 174 | ipv4-address-and-prefix | string | RFC XXXX | 175 | ipv6-address-and-prefix | string | RFC XXXX | 176 | domain-name | string | RFC 6021 | 177 | host-name | domain-name | RFC XXXX | 178 | host | union | RFC 6021 | 179 | uri | string | RFC 6021 | 180 | email-address | string | RFC XXXX | 181 +-------------------------+--------------+------------+ 183 Table 2: Types defined in ietf-inet-types 185 Some types have an equivalent Structure of Management Information 186 Version 2 (SMIv2) [RFC2578][RFC2579] data type. A YANG data type is 187 equivalent to an SMIv2 data type if the data types have the same set 188 of values and the semantics of the values are equivalent. 190 Table 3 lists the types defined in the "ietf-yang-types" YANG module 191 with their corresponding SMIv2 types and Table 4 lists the types 192 defined in the "ietf-inet-types" module with their corresponding 193 SMIv2 types. 195 +-----------------------+--------------------------------+ 196 | YANG type | Equivalent SMIv2 type (module) | 197 +-----------------------+--------------------------------+ 198 | counter32 | Counter32 (SNMPv2-SMI) | 199 | zero-based-counter32 | ZeroBasedCounter32 (RMON2-MIB) | 200 | counter64 | Counter64 (SNMPv2-SMI) | 201 | zero-based-counter64 | ZeroBasedCounter64 (HCNUM-TC) | 202 | gauge32 | Gauge32 (SNMPv2-SMI) | 203 | gauge64 | CounterBasedGauge64 (HCNUM-TC) | 204 | object-identifier-128 | OBJECT IDENTIFIER | 205 | centiseconds32 | TimeInterval (SNMPv2-TC) | 206 | timeticks | TimeTicks (SNMPv2-SMI) | 207 | timestamp | TimeStamp (SNMPv2-TC) | 208 | phys-address | PhysAddress (SNMPv2-TC) | 209 | mac-address | MacAddress (SNMPv2-TC) | 210 +-----------------------+--------------------------------+ 212 Table 3: Equivalent SMIv2 types for ietf-yang-types 214 +-----------------+-----------------------------------------------+ 215 | YANG type | Equivalent SMIv2 type (module) | 216 +-----------------+-----------------------------------------------+ 217 | ip-version | InetVersion (INET-ADDRESS-MIB) | 218 | dscp | Dscp (DIFFSERV-DSCP-TC) | 219 | ipv6-flow-label | IPv6FlowLabel (IPV6-FLOW-LABEL-MIB) | 220 | port-number | InetPortNumber (INET-ADDRESS-MIB) | 221 | as-number | InetAutonomousSystemNumber (INET-ADDRESS-MIB) | 222 | uri | Uri (URI-TC-MIB) | 223 +-----------------+-----------------------------------------------+ 225 Table 4: Equivalent SMIv2 types for ietf-inet-types 227 3. Core YANG Derived Types 229 The ietf-yang-types YANG module references [IEEE802], [ISO9834-1], 230 [RFC2578], [RFC2579], [RFC2856], [RFC3339], [RFC4122], [RFC4502], 231 [RFC7950], [RFC8294], [XPATH], and [XSD-TYPES]. 233 file "ietf-yang-types@2022-03-22.yang" 235 module ietf-yang-types { 237 namespace "urn:ietf:params:xml:ns:yang:ietf-yang-types"; 238 prefix "yang"; 240 organization 241 "IETF Network Modeling (NETMOD) Working Group"; 243 contact 244 "WG Web: 245 WG List: 247 Editor: Juergen Schoenwaelder 248 "; 250 description 251 "This module contains a collection of generally useful derived 252 YANG data types. 254 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 255 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 256 'MAY', and 'OPTIONAL' in this document are to be interpreted as 257 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 258 they appear in all capitals, as shown here. 260 Copyright (c) 2022 IETF Trust and the persons identified as 261 authors of the code. All rights reserved. 263 Redistribution and use in source and binary forms, with or 264 without modification, is permitted pursuant to, and subject 265 to the license terms contained in, the Simplified BSD License 266 set forth in Section 4.c of the IETF Trust's Legal Provisions 267 Relating to IETF Documents 268 (https://trustee.ietf.org/license-info). 270 This version of this YANG module is part of RFC XXXX; 271 see the RFC itself for full legal notices."; 273 revision 2022-03-22 { 274 description 275 "This revision adds the following new data types: 276 - date, date-no-zone, time, time-no-zone, 277 - hours32, minutes32, seconds32, centiseconds32, milliseconds32, 278 - microseconds32, microseconds64, nanoseconds32, nanoseconds64 279 The yang-identifier definition has been aligned with YANG 1.1."; 280 reference 281 "RFC XXXX: Common YANG Data Types"; 282 } 284 revision 2013-07-15 { 285 description 286 "This revision adds the following new data types: 287 - yang-identifier 288 - hex-string 289 - uuid 290 - dotted-quad"; 292 reference 293 "RFC 6991: Common YANG Data Types"; 294 } 296 revision 2010-09-24 { 297 description 298 "Initial revision."; 299 reference 300 "RFC 6021: Common YANG Data Types"; 301 } 303 /*** collection of counter and gauge types ***/ 305 typedef counter32 { 306 type uint32; 307 description 308 "The counter32 type represents a non-negative integer 309 that monotonically increases until it reaches a 310 maximum value of 2^32-1 (4294967295 decimal), when it 311 wraps around and starts increasing again from zero. 313 Counters have no defined 'initial' value, and thus, a 314 single value of a counter has (in general) no information 315 content. Discontinuities in the monotonically increasing 316 value normally occur at re-initialization of the 317 management system, and at other times as specified in the 318 description of a schema node using this type. If such 319 other times can occur, for example, the instantiation of 320 a schema node of type counter32 at times other than 321 re-initialization, then a corresponding schema node 322 should be defined, with an appropriate type, to indicate 323 the last discontinuity. 325 The counter32 type should not be used for configuration 326 schema nodes. A default statement SHOULD NOT be used in 327 combination with the type counter32. 329 In the value set and its semantics, this type is equivalent 330 to the Counter32 type of the SMIv2."; 331 reference 332 "RFC 2578: Structure of Management Information Version 2 333 (SMIv2)"; 334 } 336 typedef zero-based-counter32 { 337 type yang:counter32; 338 default "0"; 339 description 340 "The zero-based-counter32 type represents a counter32 341 that has the defined 'initial' value zero. 343 A schema node instance of this type will be set to zero (0) 344 on creation and will thereafter increase monotonically until 345 it reaches a maximum value of 2^32-1 (4294967295 decimal), 346 when it wraps around and starts increasing again from zero. 348 Provided that an application discovers a new schema node 349 instance of this type within the minimum time to wrap, it 350 can use the 'initial' value as a delta. It is important for 351 a management station to be aware of this minimum time and the 352 actual time between polls, and to discard data if the actual 353 time is too long or there is no defined minimum time. 355 In the value set and its semantics, this type is equivalent 356 to the ZeroBasedCounter32 textual convention of the SMIv2."; 357 reference 358 "RFC 4502: Remote Network Monitoring Management Information 359 Base Version 2"; 360 } 362 typedef counter64 { 363 type uint64; 364 description 365 "The counter64 type represents a non-negative integer 366 that monotonically increases until it reaches a 367 maximum value of 2^64-1 (18446744073709551615 decimal), 368 when it wraps around and starts increasing again from zero. 370 Counters have no defined 'initial' value, and thus, a 371 single value of a counter has (in general) no information 372 content. Discontinuities in the monotonically increasing 373 value normally occur at re-initialization of the 374 management system, and at other times as specified in the 375 description of a schema node using this type. If such 376 other times can occur, for example, the instantiation of 377 a schema node of type counter64 at times other than 378 re-initialization, then a corresponding schema node 379 should be defined, with an appropriate type, to indicate 380 the last discontinuity. 382 The counter64 type should not be used for configuration 383 schema nodes. A default statement SHOULD NOT be used in 384 combination with the type counter64. 386 In the value set and its semantics, this type is equivalent 387 to the Counter64 type of the SMIv2."; 389 reference 390 "RFC 2578: Structure of Management Information Version 2 391 (SMIv2)"; 392 } 394 typedef zero-based-counter64 { 395 type yang:counter64; 396 default "0"; 397 description 398 "The zero-based-counter64 type represents a counter64 that 399 has the defined 'initial' value zero. 401 A schema node instance of this type will be set to zero (0) 402 on creation and will thereafter increase monotonically until 403 it reaches a maximum value of 2^64-1 (18446744073709551615 404 decimal), when it wraps around and starts increasing again 405 from zero. 407 Provided that an application discovers a new schema node 408 instance of this type within the minimum time to wrap, it 409 can use the 'initial' value as a delta. It is important for 410 a management station to be aware of this minimum time and the 411 actual time between polls, and to discard data if the actual 412 time is too long or there is no defined minimum time. 414 In the value set and its semantics, this type is equivalent 415 to the ZeroBasedCounter64 textual convention of the SMIv2."; 416 reference 417 "RFC 2856: Textual Conventions for Additional High Capacity 418 Data Types"; 419 } 421 typedef gauge32 { 422 type uint32; 423 description 424 "The gauge32 type represents a non-negative integer, which 425 may increase or decrease, but shall never exceed a maximum 426 value, nor fall below a minimum value. The maximum value 427 cannot be greater than 2^32-1 (4294967295 decimal), and 428 the minimum value cannot be smaller than 0. The value of 429 a gauge32 has its maximum value whenever the information 430 being modeled is greater than or equal to its maximum 431 value, and has its minimum value whenever the information 432 being modeled is smaller than or equal to its minimum value. 433 If the information being modeled subsequently decreases 434 below (increases above) the maximum (minimum) value, the 435 gauge32 also decreases (increases). 437 In the value set and its semantics, this type is equivalent 438 to the Gauge32 type of the SMIv2."; 439 reference 440 "RFC 2578: Structure of Management Information Version 2 441 (SMIv2)"; 442 } 444 typedef gauge64 { 445 type uint64; 446 description 447 "The gauge64 type represents a non-negative integer, which 448 may increase or decrease, but shall never exceed a maximum 449 value, nor fall below a minimum value. The maximum value 450 cannot be greater than 2^64-1 (18446744073709551615), and 451 the minimum value cannot be smaller than 0. The value of 452 a gauge64 has its maximum value whenever the information 453 being modeled is greater than or equal to its maximum 454 value, and has its minimum value whenever the information 455 being modeled is smaller than or equal to its minimum value. 456 If the information being modeled subsequently decreases 457 below (increases above) the maximum (minimum) value, the 458 gauge64 also decreases (increases). 460 In the value set and its semantics, this type is equivalent 461 to the CounterBasedGauge64 SMIv2 textual convention defined 462 in RFC 2856"; 463 reference 464 "RFC 2856: Textual Conventions for Additional High Capacity 465 Data Types"; 466 } 468 /*** collection of identifier-related types ***/ 470 typedef object-identifier { 471 type string { 472 pattern '(([0-1](\.[1-3]?[0-9]))|(2\.(0|([1-9][0-9]*))))' 473 + '(\.(0|([1-9][0-9]*)))*'; 474 } 475 description 476 "The object-identifier type represents administratively 477 assigned names in a registration-hierarchical-name tree. 479 Values of this type are denoted as a sequence of numerical 480 non-negative sub-identifier values. Each sub-identifier 481 value MUST NOT exceed 2^32-1 (4294967295). Sub-identifiers 482 are separated by single dots and without any intermediate 483 whitespace. 485 The ASN.1 standard restricts the value space of the first 486 sub-identifier to 0, 1, or 2. Furthermore, the value space 487 of the second sub-identifier is restricted to the range 488 0 to 39 if the first sub-identifier is 0 or 1. Finally, 489 the ASN.1 standard requires that an object identifier 490 has always at least two sub-identifiers. The pattern 491 captures these restrictions. 493 Although the number of sub-identifiers is not limited, 494 module designers should realize that there may be 495 implementations that stick with the SMIv2 limit of 128 496 sub-identifiers. 498 This type is a superset of the SMIv2 OBJECT IDENTIFIER type 499 since it is not restricted to 128 sub-identifiers. Hence, 500 this type SHOULD NOT be used to represent the SMIv2 OBJECT 501 IDENTIFIER type; the object-identifier-128 type SHOULD be 502 used instead."; 503 reference 504 "ISO9834-1: Information technology -- Open Systems 505 Interconnection -- Procedures for the operation of OSI 506 Registration Authorities: General procedures and top 507 arcs of the ASN.1 Object Identifier tree"; 508 } 510 typedef object-identifier-128 { 511 type object-identifier { 512 pattern '[0-9]*(\.[0-9]*){1,127}'; 513 } 514 description 515 "This type represents object-identifiers restricted to 128 516 sub-identifiers. 518 In the value set and its semantics, this type is equivalent 519 to the OBJECT IDENTIFIER type of the SMIv2."; 520 reference 521 "RFC 2578: Structure of Management Information Version 2 522 (SMIv2)"; 523 } 525 /*** collection of types related to date and time ***/ 527 typedef date-and-time { 528 type string { 529 pattern '[0-9]{4}-(1[0-2]|0[1-9])-(0[1-9]|[1-2][0-9]|3[0-1])' 530 + 'T(0[0-9]|1[0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9](\.[0-9]+)?' 531 + '(Z|[\+\-]((1[0-3]|0[0-9]):([0-5][0-9])|14:00))?'; 532 } 533 description 534 "The date-and-time type is a profile of the ISO 8601 535 standard for representation of dates and times using the 536 Gregorian calendar. The profile is defined by the 537 date-time production in Section 5.6 of RFC 3339. 539 The date-and-time type is compatible with the dateTime XML 540 schema dateTime type with the following notable exceptions: 542 (a) The date-and-time type does not allow negative years. 544 (b) The time-offset -00:00 indicates that the date-and-time 545 value is reported in UTC and that the local time zone 546 reference point is unknown. The time-offsets +00:00 and Z 547 both indicate that the date-and-time value is reported in 548 UTC and that the local time reference point is UTC (see RFC 549 3339 section 4.3). 551 This type is not equivalent to the DateAndTime textual 552 convention of the SMIv2 since RFC 3339 uses a different 553 separator between full-date and full-time and provides 554 higher resolution of time-secfrac. 556 The canonical format for date-and-time values with a known time 557 zone uses a numeric time zone offset that is calculated using 558 the device's configured known offset to UTC time. A change of 559 the device's offset to UTC time will cause date-and-time values 560 to change accordingly. Such changes might happen periodically 561 in case a server follows automatically daylight saving time 562 (DST) time zone offset changes. The canonical format for 563 date-and-time values with an unknown time zone (usually 564 referring to the notion of local time) uses the time-offset 565 -00:00, i.e., date-and-time values must be reported in UTC."; 566 reference 567 "RFC 3339: Date and Time on the Internet: Timestamps 568 RFC 2579: Textual Conventions for SMIv2 569 XSD-TYPES: XML Schema Definition Language (XSD) 1.1 570 Part 2: Datatypes"; 571 } 573 typedef date { 574 type string { 575 pattern '[0-9]{4}-(1[0-2]|0[1-9])-(0[1-9]|[1-2][0-9]|3[0-1])' 576 + '(Z|[\+\-]((1[0-3]|0[0-9]):([0-5][0-9])|14:00))?'; 577 } 578 description 579 "The date type represents a time-interval of the length 580 of a day, i.e., 24 hours. 582 The date type is compatible with the XML schema date 583 type with the following notable exceptions: 585 (a) The date type does not allow negative years. 587 (b) The time-offset -00:00 indicates that the date value is 588 reported in UTC and that the local time zone reference point 589 is unknown. The time-offsets +00:00 and Z both indicate that 590 the date value is reported in UTC and that the local time 591 reference point is UTC (see RFC 3339 section 4.3). 593 The canonical format for date values with a known time 594 zone uses a numeric time zone offset that is calculated using 595 the device's configured known offset to UTC time. A change of 596 the device's offset to UTC time will cause date values 597 to change accordingly. Such changes might happen periodically 598 in case a server follows automatically daylight saving time 599 (DST) time zone offset changes. The canonical format for 600 date values with an unknown time zone (usually referring 601 to the notion of local time) uses the time-offset -00:00, 602 i.e., date values must be reported in UTC."; 603 reference 604 "RFC 3339: Date and Time on the Internet: Timestamps 605 XSD-TYPES: XML Schema Definition Language (XSD) 1.1 606 Part 2: Datatypes"; 607 } 609 typedef date-no-zone { 610 type date { 611 pattern '[0-9]{4}-(1[0-2]|0[1-9])-(0[1-9]|[1-2][0-9]|3[0-1])'; 612 } 613 description 614 "The date-no-zone type represents a date without the optional 615 time zone offset information."; 616 } 618 typedef time { 619 type string { 620 pattern '(0[0-9]|1[0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9](\.[0-9]+)?' 621 + '(Z|[\+\-]((1[0-3]|0[0-9]):([0-5][0-9])|14:00))?'; 622 } 623 description 624 "The time type represents an instance of time of zero-duration 625 that recurs every day. 627 The time type is compatible with the XML schema time 628 type with the following notable exception: 630 (a) The time-offset -00:00 indicates that the time value is 631 reported in UTC and that the local time zone reference point 632 is unknown. The time-offsets +00:00 and Z both indicate that 633 the time value is reported in UTC and that the local time 634 reference point is UTC (see RFC 3339 section 4.3). 636 The canonical format for time values with a known time 637 zone uses a numeric time zone offset that is calculated using 638 the device's configured known offset to UTC time. A change of 639 the device's offset to UTC time will cause time values 640 to change accordingly. Such changes might happen periodically 641 in case a server follows automatically daylight saving time 642 (DST) time zone offset changes. The canonical format for 643 time values with an unknown time zone (usually referring 644 to the notion of local time) uses the time-offset -00:00, 645 i.e., time values must be reported in UTC."; 646 reference 647 "RFC 3339: Date and Time on the Internet: Timestamps 648 XSD-TYPES: XML Schema Definition Language (XSD) 1.1 649 Part 2: Datatypes"; 650 } 652 typedef time-no-zone { 653 type time { 654 pattern '(0[0-9]|1[0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9](\.[0-9]+)?'; 655 } 656 description 657 "The time-no-zone type represents a time without the optional 658 time zone offset information."; 659 } 661 typedef hours32 { 662 type int32; 663 units "hours"; 664 description 665 "A period of time, measured in units of hours. 667 The maximum time period that can be expressed is in the 668 range [-89478485 days 08:00:00 to 89478485 days 07:00:00]. 670 This type should be range restricted in situations 671 where only non-negative time periods are desirable, 672 (i.e., range '0..max')."; 673 } 675 typedef minutes32 { 676 type int32; 677 units "minutes"; 678 description 679 "A period of time, measured in units of minutes. 681 The maximum time period that can be expressed is in the 682 range [-1491308 days 2:08:00 to 1491308 days 2:07:00]. 684 This type should be range restricted in situations 685 where only non-negative time periods are desirable, 686 (i.e., range '0..max')."; 687 } 689 typedef seconds32 { 690 type int32; 691 units "seconds"; 692 description 693 "A period of time, measured in units of seconds. 695 The maximum time period that can be expressed is in the 696 range [-24855 days 03:14:08 to 24855 days 03:14:07]. 698 This type should be range restricted in situations 699 where only non-negative time periods are desirable, 700 (i.e., range '0..max')."; 701 } 703 typedef centiseconds32 { 704 type int32; 705 units "centiseconds"; 706 description 707 "A period of time, measured in units of 10^-2 seconds. 709 The maximum time period that can be expressed is in the 710 range [-248 days 13:13:56 to 248 days 13:13:56]. 712 This type should be range restricted in situations 713 where only non-negative time periods are desirable, 714 (i.e., range '0..max')."; 715 } 717 typedef milliseconds32 { 718 type int32; 719 units "milliseconds"; 720 description 721 "A period of time, measured in units of 10^-3 seconds. 723 The maximum time period that can be expressed is in the 724 range [-24 days 20:31:23 to 24 days 20:31:23]. 726 This type should be range restricted in situations 727 where only non-negative time periods are desirable, 728 (i.e., range '0..max')."; 729 } 731 typedef microseconds32 { 732 type int32; 733 units "microseconds"; 734 description 735 "A period of time, measured in units of 10^-6 seconds. 737 The maximum time period that can be expressed is in the 738 range [-00:35:47 to 00:35:47]. 740 This type should be range restricted in situations 741 where only non-negative time periods are desirable, 742 (i.e., range '0..max')."; 743 } 745 typedef microseconds64 { 746 type int64; 747 units "microseconds"; 748 description 749 "A period of time, measured in units of 10^-6 seconds. 751 The maximum time period that can be expressed is in the 752 range [-106751991 days 04:00:54 to 106751991 days 04:00:54]. 754 This type should be range restricted in situations 755 where only non-negative time periods are desirable, 756 (i.e., range '0..max')."; 757 } 759 typedef nanoseconds32 { 760 type int32; 761 units "nanoseconds"; 762 description 763 "A period of time, measured in units of 10^-9 seconds. 765 The maximum time period that can be expressed is in the 766 range [-00:00:02 to 00:00:02]. 768 This type should be range restricted in situations 769 where only non-negative time periods are desirable, 770 (i.e., range '0..max')."; 771 } 773 typedef nanoseconds64 { 774 type int64; 775 units "nanoseconds"; 776 description 777 "A period of time, measured in units of 10^-9 seconds. 779 The maximum time period that can be expressed is in the 780 range [-106753 days 23:12:44 to 106752 days 0:47:16]. 782 This type should be range restricted in situations 783 where only non-negative time periods are desirable, 784 (i.e., range '0..max')."; 785 } 787 typedef timeticks { 788 type uint32; 789 description 790 "The timeticks type represents a non-negative integer that 791 represents the time, modulo 2^32 (4294967296 decimal), in 792 hundredths of a second between two epochs. When a schema 793 node is defined that uses this type, the description of 794 the schema node identifies both of the reference epochs. 796 In the value set and its semantics, this type is equivalent 797 to the TimeTicks type of the SMIv2."; 798 reference 799 "RFC 2578: Structure of Management Information Version 2 800 (SMIv2)"; 801 } 803 typedef timestamp { 804 type yang:timeticks; 805 description 806 "The timestamp type represents the value of an associated 807 timeticks schema node instance at which a specific occurrence 808 happened. The specific occurrence must be defined in the 809 description of any schema node defined using this type. When 810 the specific occurrence occurred prior to the last time the 811 associated timeticks schema node instance was zero, then the 812 timestamp value is zero. 814 Note that this requires all timestamp values to be reset to 815 zero when the value of the associated timeticks schema node 816 instance reaches 497+ days and wraps around to zero. 818 The associated timeticks schema node must be specified 819 in the description of any schema node using this type. 821 In the value set and its semantics, this type is equivalent 822 to the TimeStamp textual convention of the SMIv2."; 823 reference 824 "RFC 2579: Textual Conventions for SMIv2"; 825 } 827 /*** collection of generic address types ***/ 829 typedef phys-address { 830 type string { 831 pattern '([0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*)?'; 832 } 833 description 834 "Represents media- or physical-level addresses represented 835 as a sequence octets, each octet represented by two hexadecimal 836 numbers. Octets are separated by colons. The canonical 837 representation uses lowercase characters. 839 In the value set and its semantics, this type is equivalent 840 to the PhysAddress textual convention of the SMIv2."; 841 reference 842 "RFC 2579: Textual Conventions for SMIv2"; 843 } 845 typedef mac-address { 846 type string { 847 pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}'; 848 } 849 description 850 "The mac-address type represents an IEEE 802 MAC address. 851 The canonical representation uses lowercase characters. 853 In the value set and its semantics, this type is equivalent 854 to the MacAddress textual convention of the SMIv2."; 855 reference 856 "IEEE 802: IEEE Standard for Local and Metropolitan Area 857 Networks: Overview and Architecture 858 RFC 2579: Textual Conventions for SMIv2"; 859 } 861 /*** collection of XML-specific types ***/ 863 typedef xpath1.0 { 864 type string; 865 description 866 "This type represents an XPATH 1.0 expression. 868 When a schema node is defined that uses this type, the 869 description of the schema node MUST specify the XPath 870 context in which the XPath expression is evaluated."; 871 reference 872 "XPATH: XML Path Language (XPath) Version 1.0"; 873 } 875 /*** collection of string types ***/ 877 typedef hex-string { 878 type string { 879 pattern '([0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*)?'; 880 } 881 description 882 "A hexadecimal string with octets represented as hex digits 883 separated by colons. The canonical representation uses 884 lowercase characters."; 885 } 887 typedef uuid { 888 type string { 889 pattern '[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-' 890 + '[0-9a-fA-F]{4}-[0-9a-fA-F]{12}'; 891 } 892 description 893 "A Universally Unique IDentifier in the string representation 894 defined in RFC 4122. The canonical representation uses 895 lowercase characters. 897 The following is an example of a UUID in string representation: 898 f81d4fae-7dec-11d0-a765-00a0c91e6bf6 899 "; 900 reference 901 "RFC 4122: A Universally Unique IDentifier (UUID) URN 902 Namespace"; 903 } 905 typedef dotted-quad { 906 type string { 907 pattern 908 '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}' 909 + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'; 910 } 911 description 912 "An unsigned 32-bit number expressed in the dotted-quad 913 notation, i.e., four octets written as decimal numbers 914 and separated with the '.' (full stop) character."; 915 } 917 /*** collection of YANG specific types ***/ 918 typedef yang-identifier { 919 type string { 920 length "1..max"; 921 pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*'; 922 } 923 description 924 "A YANG identifier string as defined by the 'identifier' 925 rule in Section 14 of RFC 7950. An identifier must 926 start with an alphabetic character or an underscore 927 followed by an arbitrary sequence of alphabetic or 928 numeric characters, underscores, hyphens, or dots. 930 This definition conforms to YANG 1.1 defined in RFC 931 7950. An earlier version of this definition did exclude 932 all identifiers starting with any possible combination 933 of the lowercase or uppercase character sequence 'xml', 934 as required by YANG 1 defined in RFC 6020. If this type 935 is used in a YANG 1 context, then this restriction still 936 applies."; 937 reference 938 "RFC 7950: The YANG 1.1 Data Modeling Language 939 RFC 6020: YANG - A Data Modeling Language for the 940 Network Configuration Protocol (NETCONF)"; 941 } 943 } 945 947 4. Internet-Specific Derived Types 949 The ietf-inet-types YANG module references [RFC0768], [RFC0791], 950 [RFC0793], [RFC0952], [RFC1034], [RFC1123], [RFC1930], [RFC2317], 951 [RFC2474], [RFC2780], [RFC2782], [RFC3289], [RFC3305], [RFC3595], 952 [RFC3927], [RFC3986], [RFC4001], [RFC4007], [RFC4271], [RFC4291], 953 [RFC4340], [RFC4592] [RFC4960], [RFC5017], [RFC5322], [RFC5890], 954 [RFC5952], [RFC6793], and [RFC8200]. 956 file "ietf-inet-types@2022-03-22.yang" 958 module ietf-inet-types { 960 namespace "urn:ietf:params:xml:ns:yang:ietf-inet-types"; 961 prefix "inet"; 963 organization 964 "IETF Network Modeling (NETMOD) Working Group"; 966 contact 967 "WG Web: 968 WG List: 970 Editor: Juergen Schoenwaelder 971 "; 973 description 974 "This module contains a collection of generally useful derived 975 YANG data types for Internet addresses and related things. 977 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 978 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 979 'MAY', and 'OPTIONAL' in this document are to be interpreted as 980 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 981 they appear in all capitals, as shown here. 983 Copyright (c) 2022 IETF Trust and the persons identified as 984 authors of the code. All rights reserved. 986 Redistribution and use in source and binary forms, with or 987 without modification, is permitted pursuant to, and subject 988 to the license terms contained in, the Simplified BSD License 989 set forth in Section 4.c of the IETF Trust's Legal Provisions 990 Relating to IETF Documents 991 (https://trustee.ietf.org/license-info). 993 This version of this YANG module is part of RFC XXXX; 994 see the RFC itself for full legal notices."; 996 revision 2022-03-22 { 997 description 998 "This revision adds the following new data types: 999 - inet:ip-address-and-prefix 1000 - inet:ipv4-address-and-prefix 1001 - inet:ipv6-address-and-prefix 1002 - inet:protocol-number 1003 - inet:host-name 1004 - inet:email-address 1005 - inet:ip-address-link-local 1006 - inet:ipv4-address-link-local 1007 - inet:ipv6-address-link-local 1008 The inet:host union was changed to use inet:host-name instead 1009 of inet:domain-name."; 1010 reference 1011 "RFC XXXX: Common YANG Data Types"; 1012 } 1013 revision 2013-07-15 { 1014 description 1015 "This revision adds the following new data types: 1016 - inet:ip-address-no-zone 1017 - inet:ipv4-address-no-zone 1018 - inet:ipv6-address-no-zone"; 1019 reference 1020 "RFC 6991: Common YANG Data Types"; 1021 } 1023 revision 2010-09-24 { 1024 description 1025 "Initial revision."; 1026 reference 1027 "RFC 6021: Common YANG Data Types"; 1028 } 1030 /*** collection of types related to protocol fields ***/ 1032 typedef ip-version { 1033 type enumeration { 1034 enum unknown { 1035 value "0"; 1036 description 1037 "An unknown or unspecified version of the Internet 1038 protocol."; 1039 } 1040 enum ipv4 { 1041 value "1"; 1042 description 1043 "The IPv4 protocol as defined in RFC 791."; 1044 } 1045 enum ipv6 { 1046 value "2"; 1047 description 1048 "The IPv6 protocol as defined in RFC 8200."; 1049 } 1050 } 1051 description 1052 "This value represents the version of the IP protocol. 1054 In the value set and its semantics, this type is equivalent 1055 to the InetVersion textual convention of the SMIv2."; 1056 reference 1057 "RFC 791: Internet Protocol 1058 RFC 8200: Internet Protocol, Version 6 (IPv6) Specification 1059 RFC 4001: Textual Conventions for Internet Network Addresses"; 1060 } 1061 typedef dscp { 1062 type uint8 { 1063 range "0..63"; 1064 } 1065 description 1066 "The dscp type represents a Differentiated Services Code Point 1067 that may be used for marking packets in a traffic stream. 1069 In the value set and its semantics, this type is equivalent 1070 to the Dscp textual convention of the SMIv2."; 1071 reference 1072 "RFC 3289: Management Information Base for the Differentiated 1073 Services Architecture 1074 RFC 2474: Definition of the Differentiated Services Field 1075 (DS Field) in the IPv4 and IPv6 Headers 1076 RFC 2780: IANA Allocation Guidelines For Values In 1077 the Internet Protocol and Related Headers"; 1078 } 1080 typedef ipv6-flow-label { 1081 type uint32 { 1082 range "0..1048575"; 1083 } 1084 description 1085 "The ipv6-flow-label type represents the flow identifier or 1086 Flow Label in an IPv6 packet header that may be used to 1087 discriminate traffic flows. 1089 In the value set and its semantics, this type is equivalent 1090 to the IPv6FlowLabel textual convention of the SMIv2."; 1091 reference 1092 "RFC 3595: Textual Conventions for IPv6 Flow Label 1093 RFC 8200: Internet Protocol, Version 6 (IPv6) Specification"; 1094 } 1096 typedef port-number { 1097 type uint16 { 1098 range "0..65535"; 1099 } 1100 description 1101 "The port-number type represents a 16-bit port number of an 1102 Internet transport-layer protocol such as UDP, TCP, DCCP, or 1103 SCTP. 1105 Port numbers are assigned by IANA. The current list of 1106 all assignments is available from . 1108 Note that the port number value zero is reserved by IANA. In 1109 situations where the value zero does not make sense, it can 1110 be excluded by subtyping the port-number type. 1112 In the value set and its semantics, this type is equivalent 1113 to the InetPortNumber textual convention of the SMIv2."; 1114 reference 1115 "RFC 768: User Datagram Protocol 1116 RFC 793: Transmission Control Protocol 1117 RFC 4960: Stream Control Transmission Protocol 1118 RFC 4340: Datagram Congestion Control Protocol (DCCP) 1119 RFC 4001: Textual Conventions for Internet Network Addresses"; 1120 } 1122 typedef protocol-number { 1123 type uint8; 1124 description 1125 "The protocol-number type represents an 8-bit Internet 1126 protocol number, carried in the 'protocol' field of the 1127 IPv4 header or in the 'next header' field of the IPv6 1128 header. If IPv6 extension headers are present, then the 1129 protocol number type represents the upper layer protocol 1130 number, i.e., the number of the last next header' field 1131 of the IPv6 extension headers. 1133 Protocol numbers are assigned by IANA. The current list of 1134 all assignments is available from ."; 1135 reference 1136 "RFC 791: Internet Protocol 1137 RFC 8200: Internet Protocol, Version 6 (IPv6) Specification"; 1138 } 1140 /*** collection of types related to autonomous systems ***/ 1142 typedef as-number { 1143 type uint32; 1144 description 1145 "The as-number type represents autonomous system numbers 1146 which identify an Autonomous System (AS). An AS is a set 1147 of routers under a single technical administration, using 1148 an interior gateway protocol and common metrics to route 1149 packets within the AS, and using an exterior gateway 1150 protocol to route packets to other ASes. IANA maintains 1151 the AS number space and has delegated large parts to the 1152 regional registries. 1154 Autonomous system numbers were originally limited to 16 1155 bits. BGP extensions have enlarged the autonomous system 1156 number space to 32 bits. This type therefore uses an uint32 1157 base type without a range restriction in order to support 1158 a larger autonomous system number space. 1160 In the value set and its semantics, this type is equivalent 1161 to the InetAutonomousSystemNumber textual convention of 1162 the SMIv2."; 1163 reference 1164 "RFC 1930: Guidelines for creation, selection, and registration 1165 of an Autonomous System (AS) 1166 RFC 4271: A Border Gateway Protocol 4 (BGP-4) 1167 RFC 4001: Textual Conventions for Internet Network Addresses 1168 RFC 6793: BGP Support for Four-Octet Autonomous System (AS) 1169 Number Space"; 1170 } 1172 /*** collection of types related to IP addresses and hostnames ***/ 1174 typedef ip-address { 1175 type union { 1176 type inet:ipv4-address; 1177 type inet:ipv6-address; 1178 } 1179 description 1180 "The ip-address type represents an IP address and is IP 1181 version neutral. The format of the textual representation 1182 implies the IP version. This type supports scoped addresses 1183 by allowing zone identifiers in the address format."; 1184 reference 1185 "RFC 4007: IPv6 Scoped Address Architecture"; 1186 } 1188 typedef ipv4-address { 1189 type string { 1190 pattern 1191 '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}' 1192 + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])' 1193 + '(%[\p{N}\p{L}]+)?'; 1194 } 1195 description 1196 "The ipv4-address type represents an IPv4 address in 1197 dotted-quad notation. The IPv4 address may include a zone 1198 index, separated by a % sign. 1200 The zone index is used to disambiguate identical address 1201 values. For link-local addresses, the zone index will 1202 typically be the interface index number or the name of an 1203 interface. If the zone index is not present, the default 1204 zone of the device will be used. 1206 The canonical format for the zone index is the numerical 1207 format"; 1208 } 1210 typedef ipv6-address { 1211 type string { 1212 pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}' 1213 + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|' 1214 + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}' 1215 + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))' 1216 + '(%[\p{N}\p{L}]+)?'; 1217 pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|' 1218 + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)' 1219 + '(%.+)?'; 1220 } 1221 description 1222 "The ipv6-address type represents an IPv6 address in full, 1223 mixed, shortened, and shortened-mixed notation. The IPv6 1224 address may include a zone index, separated by a % sign. 1226 The zone index is used to disambiguate identical address 1227 values. For link-local addresses, the zone index will 1228 typically be the interface index number or the name of an 1229 interface. If the zone index is not present, the default 1230 zone of the device will be used. 1232 The canonical format of IPv6 addresses uses the textual 1233 representation defined in Section 4 of RFC 5952. The 1234 canonical format for the zone index is the numerical 1235 format as described in Section 11.2 of RFC 4007."; 1236 reference 1237 "RFC 4291: IP Version 6 Addressing Architecture 1238 RFC 4007: IPv6 Scoped Address Architecture 1239 RFC 5952: A Recommendation for IPv6 Address Text 1240 Representation"; 1241 } 1243 typedef ip-address-no-zone { 1244 type union { 1245 type inet:ipv4-address-no-zone; 1246 type inet:ipv6-address-no-zone; 1247 } 1248 description 1249 "The ip-address-no-zone type represents an IP address and is 1250 IP version neutral. The format of the textual representation 1251 implies the IP version. This type does not support scoped 1252 addresses since it does not allow zone identifiers in the 1253 address format."; 1255 reference 1256 "RFC 4007: IPv6 Scoped Address Architecture"; 1257 } 1259 typedef ipv4-address-no-zone { 1260 type inet:ipv4-address { 1261 pattern '[0-9\.]*'; 1262 } 1263 description 1264 "An IPv4 address without a zone index. This type, derived from 1265 ipv4-address, may be used in situations where the zone is known 1266 from the context and hence no zone index is needed."; 1267 } 1269 typedef ipv6-address-no-zone { 1270 type inet:ipv6-address { 1271 pattern '[0-9a-fA-F:\.]*'; 1272 } 1273 description 1274 "An IPv6 address without a zone index. This type, derived from 1275 ipv6-address, may be used in situations where the zone is known 1276 from the context and hence no zone index is needed."; 1277 reference 1278 "RFC 4291: IP Version 6 Addressing Architecture 1279 RFC 4007: IPv6 Scoped Address Architecture 1280 RFC 5952: A Recommendation for IPv6 Address Text 1281 Representation"; 1282 } 1284 typedef ip-address-link-local { 1285 type union { 1286 type inet:ipv4-address-link-local; 1287 type inet:ipv6-address-link-local; 1288 } 1289 description 1290 "The ip-address-link-local type represents a link-local IP 1291 address and is IP version neutral. The format of the textual 1292 representation implies the IP version."; 1293 } 1295 typedef ipv4-address-link-local { 1296 type ipv4-address { 1297 pattern '169\.254\..*'; 1298 } 1299 description 1300 "A link-local IPv4 address in the prefix 169.254.0.0/16 as 1301 defined in section 2.1. of RFC 3927."; 1302 reference 1303 "RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses"; 1304 } 1306 typedef ipv6-address-link-local { 1307 type ipv6-address { 1308 pattern '[fF][eE]80:.*'; 1309 } 1310 description 1311 "A link-local IPv6 address in the prefix fe80::/10 as defined 1312 in section 2.5.6. of RFC 4291."; 1313 reference 1314 "RFC 4291: IP Version 6 Addressing Architecture"; 1315 } 1317 typedef ip-prefix { 1318 type union { 1319 type inet:ipv4-prefix; 1320 type inet:ipv6-prefix; 1321 } 1322 description 1323 "The ip-prefix type represents an IP prefix and is IP 1324 version neutral. The format of the textual representations 1325 implies the IP version."; 1326 } 1328 typedef ipv4-prefix { 1329 type string { 1330 pattern 1331 '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}' 1332 + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])' 1333 + '/(([0-9])|([1-2][0-9])|(3[0-2]))'; 1334 } 1335 description 1336 "The ipv4-prefix type represents an IPv4 prefix. 1337 The prefix length is given by the number following the 1338 slash character and must be less than or equal to 32. 1340 A prefix length value of n corresponds to an IP address 1341 mask that has n contiguous 1-bits from the most 1342 significant bit (MSB) and all other bits set to 0. 1344 The canonical format of an IPv4 prefix has all bits of 1345 the IPv4 address set to zero that are not part of the 1346 IPv4 prefix. 1348 The definition of ipv4-prefix does not require that bits, 1349 which are not part of the prefix, are set to zero. However, 1350 implementations have to return values in canonical format, 1351 which requires non-prefix bits to be set to zero. This means 1352 that 192.0.2.1/24 must be accepted as a valid value but it 1353 will be converted into the canonical format 192.0.2.0/24."; 1354 } 1356 typedef ipv6-prefix { 1357 type string { 1358 pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}' 1359 + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|' 1360 + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}' 1361 + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))' 1362 + '(/(([0-9])|([0-9]{2})|(1[0-1][0-9])|(12[0-8])))'; 1363 pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|' 1364 + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)' 1365 + '(/.+)'; 1366 } 1367 description 1368 "The ipv6-prefix type represents an IPv6 prefix. 1369 The prefix length is given by the number following the 1370 slash character and must be less than or equal to 128. 1372 A prefix length value of n corresponds to an IP address 1373 mask that has n contiguous 1-bits from the most 1374 significant bit (MSB) and all other bits set to 0. 1376 The canonical format of an IPv6 prefix has all bits of 1377 the IPv6 address set to zero that are not part of the 1378 IPv6 prefix. Furthermore, the IPv6 address is represented 1379 as defined in Section 4 of RFC 5952. 1381 The definition of ipv6-prefix does not require that bits, 1382 which are not part of the prefix, are set to zero. However, 1383 implementations have to return values in canonical format, 1384 which requires non-prefix bits to be set to zero. This means 1385 that 2001:db8::1/64 must be accepted as a valid value but it 1386 will be converted into the canonical format 2001:db8::/64."; 1387 reference 1388 "RFC 5952: A Recommendation for IPv6 Address Text 1389 Representation"; 1390 } 1392 typedef ip-address-and-prefix { 1393 type union { 1394 type inet:ipv4-address-and-prefix; 1395 type inet:ipv6-address-and-prefix; 1396 } 1397 description 1398 "The ip-address-and-prefix type represents an IP address and 1399 prefix and is IP version neutral. The format of the textual 1400 representations implies the IP version."; 1401 } 1403 typedef ipv4-address-and-prefix { 1404 type string { 1405 pattern 1406 '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}' 1407 + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])' 1408 + '/(([0-9])|([1-2][0-9])|(3[0-2]))'; 1409 } 1410 description 1411 "The ipv4-address-and-prefix type represents an IPv4 1412 address and an associated ipv4 prefix. 1413 The prefix length is given by the number following the 1414 slash character and must be less than or equal to 32. 1416 A prefix length value of n corresponds to an IP address 1417 mask that has n contiguous 1-bits from the most 1418 significant bit (MSB) and all other bits set to 0."; 1419 } 1421 typedef ipv6-address-and-prefix { 1422 type string { 1423 pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}' 1424 + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|' 1425 + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}' 1426 + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))' 1427 + '(/(([0-9])|([0-9]{2})|(1[0-1][0-9])|(12[0-8])))'; 1428 pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|' 1429 + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)' 1430 + '(/.+)'; 1431 } 1432 description 1433 "The ipv6-address-and-prefix type represents an IPv6 1434 address and an associated ipv4 prefix. 1435 The prefix length is given by the number following the 1436 slash character and must be less than or equal to 128. 1438 A prefix length value of n corresponds to an IP address 1439 mask that has n contiguous 1-bits from the most 1440 significant bit (MSB) and all other bits set to 0. 1442 The canonical format requires that the IPv6 address is 1443 represented as defined in Section 4 of RFC 5952."; 1444 reference 1445 "RFC 5952: A Recommendation for IPv6 Address Text 1446 Representation"; 1448 } 1450 /*** collection of domain name and URI types ***/ 1452 typedef domain-name { 1453 type string { 1454 length "1..253"; 1455 pattern 1456 '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*' 1457 + '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)' 1458 + '|\.'; 1459 } 1460 description 1461 "The domain-name type represents a DNS domain name. The 1462 name SHOULD be fully qualified whenever possible. This 1463 type does not support wildcards (see RFC 4592) or 1464 classless in-addr.arpa delegations (see RFC 2317). 1466 Internet domain names are only loosely specified. Section 1467 3.5 of RFC 1034 recommends a syntax (modified in Section 1468 2.1 of RFC 1123). The pattern above is intended to allow 1469 for current practice in domain name use, and some possible 1470 future expansion. Note that Internet host names have a 1471 stricter syntax (described in RFC 952) than the DNS 1472 recommendations in RFCs 1034 and 1123. Schema nodes 1473 representing host names should use the host-name type 1474 instead of the domain-type. 1476 The encoding of DNS names in the DNS protocol is limited 1477 to 255 characters. Since the encoding consists of labels 1478 prefixed by a length bytes and there is a trailing NULL 1479 byte, only 253 characters can appear in the textual dotted 1480 notation. 1482 The description clause of schema nodes using the domain-name 1483 type MUST describe when and how these names are resolved to 1484 IP addresses. Note that the resolution of a domain-name value 1485 may require to query multiple DNS records (e.g., A for IPv4 1486 and AAAA for IPv6). The order of the resolution process and 1487 which DNS record takes precedence can either be defined 1488 explicitly or may depend on the configuration of the 1489 resolver. 1491 Domain-name values use the US-ASCII encoding. Their canonical 1492 format uses lowercase US-ASCII characters. Internationalized 1493 domain names MUST be A-labels as per RFC 5890."; 1494 reference 1495 "RFC 952: DoD Internet Host Table Specification 1496 RFC 1034: Domain Names - Concepts and Facilities 1497 RFC 1123: Requirements for Internet Hosts -- Application 1498 and Support 1499 RFC 2317: Classless IN-ADDR.ARPA delegation 1500 RFC 2782: A DNS RR for specifying the location of services 1501 (DNS SRV) 1502 RFC 4592: The Role of Wildcards in the Domain Name System 1503 RFC 5890: Internationalized Domain Names in Applications 1504 (IDNA): Definitions and Document Framework"; 1505 } 1507 typedef host-name { 1508 type domain-name { 1509 pattern '[a-zA-Z0-9\-\.]+'; 1510 length "2..max"; 1511 } 1512 description 1513 "The host-name type represents (fully qualified) host names. 1514 Host names must be at least two characters long (see RFC 952) 1515 and they are restricted to labels consisting of letters, digits 1516 and hyphens separated by dots (see RFC1123 and RFC 952)."; 1517 reference 1518 "RFC 952: DoD Internet Host Table Specification 1519 RFC 1123: Requirements for Internet Hosts -- Application 1520 and Support"; 1521 } 1523 typedef host { 1524 type union { 1525 type inet:ip-address; 1526 type inet:host-name; 1527 } 1528 description 1529 "The host type represents either an IP address or a (fully 1530 qualified) host name."; 1531 } 1533 typedef uri { 1534 type string { 1535 pattern '[a-z][a-z0-9+.-]*:.*'; 1536 } 1537 description 1538 "The uri type represents a Uniform Resource Identifier 1539 (URI) as defined by the rule 'URI' in RFC 3986. 1541 Objects using the uri type MUST be in US-ASCII encoding, 1542 and MUST be normalized as described by RFC 3986 Sections 1543 6.2.1, 6.2.2.1, and 6.2.2.2. All unnecessary 1544 percent-encoding is removed, and all case-insensitive 1545 characters are set to lowercase except for hexadecimal 1546 digits, which are normalized to uppercase as described in 1547 Section 6.2.2.1. 1549 The purpose of this normalization is to help provide 1550 unique URIs. Note that this normalization is not 1551 sufficient to provide uniqueness. Two URIs that are 1552 textually distinct after this normalization may still be 1553 equivalent. 1555 Objects using the uri type may restrict the schemes that 1556 they permit. For example, 'data:' and 'urn:' schemes 1557 might not be appropriate. 1559 A zero-length URI is not a valid URI. This can be used to 1560 express 'URI absent' where required. 1562 In the value set and its semantics, this type is equivalent 1563 to the Uri SMIv2 textual convention defined in RFC 5017."; 1564 reference 1565 "RFC 3986: Uniform Resource Identifier (URI): Generic Syntax 1566 RFC 3305: Report from the Joint W3C/IETF URI Planning Interest 1567 Group: Uniform Resource Identifiers (URIs), URLs, 1568 and Uniform Resource Names (URNs): Clarifications 1569 and Recommendations 1570 RFC 5017: MIB Textual Conventions for Uniform Resource 1571 Identifiers (URIs)"; 1572 } 1574 typedef email-address { 1575 type string { 1576 pattern '(([a-zA-Z0-9!#$%&'+"'"+'*+/=?\^_`{|}~-]+' 1577 + '(\.[a-zA-Z0-9!#$%&'+"'"+'*+/=?\^_`{|}~-]+)*)|' 1578 + '("[a-zA-Z0-9!#$%&'+"'"+'()*+,./\[\]\^_`{|}~-]*"))' 1579 + '@' 1580 + '(([a-zA-Z0-9!#$%&'+"'"+'*+/=?\^_`{|}~-]+' 1581 + '(\.[a-zA-Z0-9!#$%&'+"'"+'*+/=?\^_`{|}~-]+)*)|' 1582 + '\[[a-zA-Z0-9!"#$%&'+"'"+'()*+,./:;<=>?@\^_`{|}~-]+\])'; 1583 } 1584 description 1585 "The email-address type represents an email address as 1586 defined as addr-spec in RFC 5322 section 3.4.1 except 1587 that obs-local-part, obs-domain and obs-qtext of the 1588 quoted-string are not supported. 1590 The email-address type uses US-ASCII characters. The 1591 canonical format of the domain part of an email-address 1592 uses lowercase US-ASCII characters."; 1593 reference 1594 "RFC 5322: Internet Message Format"; 1595 } 1597 } 1599 1601 5. IANA Considerations 1603 This document registers two URIs in the IETF XML registry [RFC3688]. 1604 Following the format in RFC 3688, the following registrations have 1605 been made. 1607 URI: urn:ietf:params:xml:ns:yang:ietf-yang-types 1608 Registrant Contact: The NETMOD WG of the IETF. 1609 XML: N/A, the requested URI is an XML namespace. 1611 URI: urn:ietf:params:xml:ns:yang:ietf-inet-types 1612 Registrant Contact: The NETMOD WG of the IETF. 1613 XML: N/A, the requested URI is an XML namespace. 1615 This document registers two YANG modules in the YANG Module Names 1616 registry [RFC6020]. 1618 name: ietf-yang-types 1619 namespace: urn:ietf:params:xml:ns:yang:ietf-yang-types 1620 prefix: yang 1621 reference: RFC XXXX 1623 name: ietf-inet-types 1624 namespace: urn:ietf:params:xml:ns:yang:ietf-inet-types 1625 prefix: inet 1626 reference: RFC XXXX 1628 6. Security Considerations 1630 This document defines common data types using the YANG data modeling 1631 language. The definitions themselves have no security impact on the 1632 Internet, but the usage of these definitions in concrete YANG modules 1633 might have. The security considerations spelled out in the YANG 1634 specification [RFC7950] apply for this document as well. 1636 7. Acknowledgments 1638 The following people contributed significantly to the original 1639 version of this document published as [RFC6020]: Andy Bierman, Martin 1640 Bjorklund, Balazs Lengyel, David Partain and Phil Shafer. 1642 Helpful comments on various versions of this document were provided 1643 by the following individuals: Andy Bierman, Martin Bjorklund, Benoit 1644 Claise, Joel M. Halpern, Ladislav Lhotka, Lars-Johan Liman, and Dan 1645 Romascanu. 1647 Juergen Schoenwaelder was partly funded by the European Union's 1648 Seventh Framework Programme under Grant Agreement ICT-318488 and the 1649 European Union's Horizon 2020 research and innovation programme under 1650 Grant Agreement No. 830927. 1652 8. References 1654 8.1. Normative References 1656 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1657 Requirement Levels", BCP 14, RFC 2119, 1658 DOI 10.17487/RFC2119, March 1997, 1659 . 1661 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 1662 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 1663 . 1665 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1666 DOI 10.17487/RFC3688, January 2004, 1667 . 1669 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1670 Resource Identifier (URI): Generic Syntax", STD 66, 1671 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1672 . 1674 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 1675 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 1676 DOI 10.17487/RFC4007, March 2005, 1677 . 1679 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1680 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1681 DOI 10.17487/RFC4122, July 2005, 1682 . 1684 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1685 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 1686 2006, . 1688 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1689 the Network Configuration Protocol (NETCONF)", RFC 6020, 1690 DOI 10.17487/RFC6020, October 2010, 1691 . 1693 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1694 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1695 . 1697 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1698 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1699 . 1701 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1702 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1703 May 2017, . 1705 [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, 1706 "Common YANG Data Types for the Routing Area", RFC 8294, 1707 DOI 10.17487/RFC8294, December 2017, 1708 . 1710 [XPATH] Clark, J. and S. DeRose, "XML Path Language (XPath) 1711 Version 1.0", World Wide Web Consortium Recommendation 1712 REC-xpath-19991116, November 1999, 1713 . 1715 8.2. Informative References 1717 [IEEE802] IEEE, "IEEE Standard for Local and Metropolitan Area 1718 Networks: Overview and Architecture", IEEE Std. 802-2001, 1719 June 2001. 1721 [ISO9834-1] 1722 ISO/IEC, "Information technology -- Open Systems 1723 Interconnection -- Procedures for the operation of OSI 1724 Registration Authorities: General procedures and top arcs 1725 of the ASN.1 Object Identifier tree", ISO/IEC 9834-1:2008, 1726 2008. 1728 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1729 DOI 10.17487/RFC0768, August 1980, 1730 . 1732 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1733 DOI 10.17487/RFC0791, September 1981, 1734 . 1736 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1737 RFC 793, DOI 10.17487/RFC0793, September 1981, 1738 . 1740 [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet 1741 host table specification", RFC 952, DOI 10.17487/RFC0952, 1742 October 1985, . 1744 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1745 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1746 . 1748 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 1749 Application and Support", STD 3, RFC 1123, 1750 DOI 10.17487/RFC1123, October 1989, 1751 . 1753 [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, 1754 selection, and registration of an Autonomous System (AS)", 1755 BCP 6, RFC 1930, DOI 10.17487/RFC1930, March 1996, 1756 . 1758 [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN- 1759 ADDR.ARPA delegation", BCP 20, RFC 2317, 1760 DOI 10.17487/RFC2317, March 1998, 1761 . 1763 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1764 "Definition of the Differentiated Services Field (DS 1765 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1766 DOI 10.17487/RFC2474, December 1998, 1767 . 1769 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1770 Schoenwaelder, Ed., "Structure of Management Information 1771 Version 2 (SMIv2)", STD 58, RFC 2578, 1772 DOI 10.17487/RFC2578, April 1999, 1773 . 1775 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1776 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 1777 STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999, 1778 . 1780 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 1781 Values In the Internet Protocol and Related Headers", 1782 BCP 37, RFC 2780, DOI 10.17487/RFC2780, March 2000, 1783 . 1785 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1786 specifying the location of services (DNS SRV)", RFC 2782, 1787 DOI 10.17487/RFC2782, February 2000, 1788 . 1790 [RFC2856] Bierman, A., McCloghrie, K., and R. Presuhn, "Textual 1791 Conventions for Additional High Capacity Data Types", 1792 RFC 2856, DOI 10.17487/RFC2856, June 2000, 1793 . 1795 [RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information 1796 Base for the Differentiated Services Architecture", 1797 RFC 3289, DOI 10.17487/RFC3289, May 2002, 1798 . 1800 [RFC3305] Mealling, M., Ed. and R. Denenberg, Ed., "Report from the 1801 Joint W3C/IETF URI Planning Interest Group: Uniform 1802 Resource Identifiers (URIs), URLs, and Uniform Resource 1803 Names (URNs): Clarifications and Recommendations", 1804 RFC 3305, DOI 10.17487/RFC3305, August 2002, 1805 . 1807 [RFC3595] Wijnen, B., "Textual Conventions for IPv6 Flow Label", 1808 RFC 3595, DOI 10.17487/RFC3595, September 2003, 1809 . 1811 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 1812 Configuration of IPv4 Link-Local Addresses", RFC 3927, 1813 DOI 10.17487/RFC3927, May 2005, 1814 . 1816 [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. 1817 Schoenwaelder, "Textual Conventions for Internet Network 1818 Addresses", RFC 4001, DOI 10.17487/RFC4001, February 2005, 1819 . 1821 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1822 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1823 DOI 10.17487/RFC4271, January 2006, 1824 . 1826 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1827 Congestion Control Protocol (DCCP)", RFC 4340, 1828 DOI 10.17487/RFC4340, March 2006, 1829 . 1831 [RFC4502] Waldbusser, S., "Remote Network Monitoring Management 1832 Information Base Version 2", RFC 4502, 1833 DOI 10.17487/RFC4502, May 2006, 1834 . 1836 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 1837 System", RFC 4592, DOI 10.17487/RFC4592, July 2006, 1838 . 1840 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1841 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1842 . 1844 [RFC5017] McWalter, D., Ed., "MIB Textual Conventions for Uniform 1845 Resource Identifiers (URIs)", RFC 5017, 1846 DOI 10.17487/RFC5017, September 2007, 1847 . 1849 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1850 DOI 10.17487/RFC5322, October 2008, 1851 . 1853 [RFC5890] Klensin, J., "Internationalized Domain Names for 1854 Applications (IDNA): Definitions and Document Framework", 1855 RFC 5890, DOI 10.17487/RFC5890, August 2010, 1856 . 1858 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1859 Address Text Representation", RFC 5952, 1860 DOI 10.17487/RFC5952, August 2010, 1861 . 1863 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1864 and A. Bierman, Ed., "Network Configuration Protocol 1865 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1866 . 1868 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 1869 Autonomous System (AS) Number Space", RFC 6793, 1870 DOI 10.17487/RFC6793, December 2012, 1871 . 1873 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1874 (IPv6) Specification", STD 86, RFC 8200, 1875 DOI 10.17487/RFC8200, July 2017, 1876 . 1878 [XSD-TYPES] 1879 Peterson, D., Gao, S., Malhotra, A., Sperberg-McQueen, C., 1880 and H. Thompson, "W3C XML Schema Definition Language (XSD) 1881 1.1 Part 2: Datatypes", World Wide Web Consortium 1882 Recommendation REC-xmlschema-2-20041028, April 2012, 1883 . 1885 Appendix A. Changes from RFC 6991 1887 This version adds new type definitions to the YANG modules. For an 1888 overview, see Table 1 and Table 2 and the revision statements in the 1889 YANG modules. 1891 The yang-identifier definition has been aligned with YANG 1.1. Some 1892 pattern statements have been rewritten in order to make them tighter. 1893 Finally, this version addresses errata 4076 and 5105 of RFC 6991. 1895 Appendix B. Changes from RFC 6021 1897 This version adds new type definitions to the YANG modules. For an 1898 overview, see Table 1 and Table 2 and the revision statements in the 1899 YANG modules. 1901 Author's Address 1903 Juergen Schoenwaelder (editor) 1904 Jacobs University 1906 Email: j.schoenwaelder@jacobs-university.de