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