idnits 2.17.1 draft-ietf-netmod-rfc6991-bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to 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 (April 14, 2019) is 1833 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'XPATH' -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Schoenwaelder, Ed. 3 Internet-Draft Jacobs University 4 Obsoletes: 6991 (if approved) April 14, 2019 5 Intended status: Standards Track 6 Expires: October 15, 2019 8 Common YANG Data Types 9 draft-ietf-netmod-rfc6991-bis-00 11 Abstract 13 This document introduces a collection of common data types to be used 14 with the YANG data modeling language. This document obsoletes RFC 15 6991. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on October 15, 2019. 34 Copyright Notice 36 Copyright (c) 2019 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 This document may contain material from IETF Documents or IETF 50 Contributions published or made publicly available before November 51 10, 2008. The person(s) controlling the copyright in some of this 52 material may not have granted the IETF Trust the right to allow 53 modifications of such material outside the IETF Standards Process. 54 Without obtaining an adequate license from the person(s) controlling 55 the copyright in such materials, this document may not be modified 56 outside the IETF Standards Process, and derivative works of it may 57 not be created outside the IETF Standards Process, except to format 58 it for publication as an RFC or to translate it into languages other 59 than English. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Core YANG Derived Types . . . . . . . . . . . . . . . . . . . 6 66 4. Internet-Specific Derived Types . . . . . . . . . . . . . . . 22 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 34 69 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 35 70 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 72 9.1. Normative References . . . . . . . . . . . . . . . . . . . 37 73 9.2. Informative References . . . . . . . . . . . . . . . . . . 38 74 Appendix A. Changes from RFC 6991 . . . . . . . . . . . . . . . . 42 75 Appendix B. Changes from RFC 6021 . . . . . . . . . . . . . . . . 43 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 44 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 | hours | - | 136 | minutes | - | 137 | seconds | - | 138 | centiseconds | - | 139 | milliseconds | - | 140 | microseconds | - | 141 | nanoseconds | - | 142 | timeticks | TimeTicks (SNMPv2-SMI) | 143 | timestamp | TimeStamp (SNMPv2-TC) | 144 | phys-address | PhysAddress (SNMPv2-TC) | 145 | mac-address | MacAddress (SNMPv2-TC) | 146 | xpath1.0 | - | 147 | hex-string | - | 148 | uuid | - | 149 | dotted-quad | - | 150 | yang-identifier | - | 151 | revision-identifier | - | 152 | node-instance-identifier | - | 153 +--------------------------+--------------------------------+ 155 Table 1: ietf-yang-types 157 Table 2 lists the types defined in the ietf-inet-types YANG module 158 and the corresponding SMIv2 types (if any). 160 +----------------------+--------------------------------------------+ 161 | YANG type | Equivalent SMIv2 type (module) | 162 +----------------------+--------------------------------------------+ 163 | ip-version | InetVersion (INET-ADDRESS-MIB) | 164 | dscp | Dscp (DIFFSERV-DSCP-TC) | 165 | ipv6-flow-label | IPv6FlowLabel (IPV6-FLOW-LABEL-MIB) | 166 | port-number | InetPortNumber (INET-ADDRESS-MIB) | 167 | as-number | InetAutonomousSystemNumber | 168 | | (INET-ADDRESS-MIB) | 169 | ip-address | - | 170 | ipv4-address | - | 171 | ipv6-address | - | 172 | ip-address-no-zone | - | 173 | ipv4-address-no-zone | - | 174 | ipv6-address-no-zone | - | 175 | ip-prefix | - | 176 | ipv4-prefix | - | 177 | ipv6-prefix | - | 178 | domain-name | - | 179 | host | - | 180 | uri | Uri (URI-TC-MIB) | 181 | email-address | - | 182 +----------------------+--------------------------------------------+ 184 Table 2: ietf-inet-types 186 3. Core YANG Derived Types 188 The ietf-yang-types YANG module references [IEEE802], [ISO9834-1], 189 [RFC2578], [RFC2579], [RFC2856], [RFC3339], [RFC4122], [RFC4502], 190 [RFC5322], [RFC7950], [XPATH], and [XSD-TYPES]. 192 file "ietf-yang-types@2019-03-11.yang" 194 module ietf-yang-types { 196 namespace "urn:ietf:params:xml:ns:yang:ietf-yang-types"; 197 prefix "yang"; 199 organization 200 "IETF NETMOD (Network Modeling) Working Group"; 202 contact 203 "WG Web: 204 WG List: 206 Editor: Juergen Schoenwaelder 207 "; 209 description 210 "This module contains a collection of generally useful derived 211 YANG data types. 213 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 214 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 215 'MAY', and 'OPTIONAL' in this document are to be interpreted as 216 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 217 they appear in all capitals, as shown here. 219 Copyright (c) 2019 IETF Trust and the persons identified as 220 authors of the code. All rights reserved. 222 Redistribution and use in source and binary forms, with or 223 without modification, is permitted pursuant to, and subject 224 to the license terms contained in, the Simplified BSD License 225 set forth in Section 4.c of the IETF Trust's Legal Provisions 226 Relating to IETF Documents 227 (http://trustee.ietf.org/license-info). 229 This version of this YANG module is part of RFC XXXX; 230 see the RFC itself for full legal notices."; 232 revision 2019-03-11 { 233 description 234 "This revision adds the following new data types: 235 - date, time 236 - hours, minutes, seconds 237 - centiseconds, milliseconds, microseconds, nanoseconds 238 - revision-identifier, node-instance-identifier"; 239 reference 240 "RFC XXXX: Common YANG Data Types"; 241 } 243 revision 2013-07-15 { 244 description 245 "This revision adds the following new data types: 246 - yang-identifier 247 - hex-string 248 - uuid 249 - dotted-quad"; 250 reference 251 "RFC 6991: Common YANG Data Types"; 252 } 254 revision 2010-09-24 { 255 description 256 "Initial revision."; 257 reference 258 "RFC 6021: Common YANG Data Types"; 259 } 261 /*** collection of counter and gauge types ***/ 263 typedef counter32 { 264 type uint32; 265 description 266 "The counter32 type represents a non-negative integer 267 that monotonically increases until it reaches a 268 maximum value of 2^32-1 (4294967295 decimal), when it 269 wraps around and starts increasing again from zero. 271 Counters have no defined 'initial' value, and thus, a 272 single value of a counter has (in general) no information 273 content. Discontinuities in the monotonically increasing 274 value normally occur at re-initialization of the 275 management system, and at other times as specified in the 276 description of a schema node using this type. If such 277 other times can occur, for example, the instantiation of 278 a schema node of type counter32 at times other than 279 re-initialization, then a corresponding schema node 280 should be defined, with an appropriate type, to indicate 281 the last discontinuity. 283 The counter32 type should not be used for configuration 284 schema nodes. A default statement SHOULD NOT be used in 285 combination with the type counter32. 287 In the value set and its semantics, this type is equivalent 288 to the Counter32 type of the SMIv2."; 289 reference 290 "RFC 2578: Structure of Management Information Version 2 291 (SMIv2)"; 292 } 294 typedef zero-based-counter32 { 295 type yang:counter32; 296 default "0"; 297 description 298 "The zero-based-counter32 type represents a counter32 299 that has the defined 'initial' value zero. 301 A schema node instance of this type will be set to zero (0) 302 on creation and will thereafter increase monotonically until 303 it reaches a maximum value of 2^32-1 (4294967295 decimal), 304 when it wraps around and starts increasing again from zero. 306 Provided that an application discovers a new schema node 307 instance of this type within the minimum time to wrap, it 308 can use the 'initial' value as a delta. It is important for 309 a management station to be aware of this minimum time and the 310 actual time between polls, and to discard data if the actual 311 time is too long or there is no defined minimum time. 313 In the value set and its semantics, this type is equivalent 314 to the ZeroBasedCounter32 textual convention of the SMIv2."; 315 reference 316 "RFC 4502: Remote Network Monitoring Management Information 317 Base Version 2"; 318 } 320 typedef counter64 { 321 type uint64; 322 description 323 "The counter64 type represents a non-negative integer 324 that monotonically increases until it reaches a 325 maximum value of 2^64-1 (18446744073709551615 decimal), 326 when it wraps around and starts increasing again from zero. 328 Counters have no defined 'initial' value, and thus, a 329 single value of a counter has (in general) no information 330 content. Discontinuities in the monotonically increasing 331 value normally occur at re-initialization of the 332 management system, and at other times as specified in the 333 description of a schema node using this type. If such 334 other times can occur, for example, the instantiation of 335 a schema node of type counter64 at times other than 336 re-initialization, then a corresponding schema node 337 should be defined, with an appropriate type, to indicate 338 the last discontinuity. 340 The counter64 type should not be used for configuration 341 schema nodes. A default statement SHOULD NOT be used in 342 combination with the type counter64. 344 In the value set and its semantics, this type is equivalent 345 to the Counter64 type of the SMIv2."; 346 reference 347 "RFC 2578: Structure of Management Information Version 2 348 (SMIv2)"; 349 } 351 typedef zero-based-counter64 { 352 type yang:counter64; 353 default "0"; 354 description 355 "The zero-based-counter64 type represents a counter64 that 356 has the defined 'initial' value zero. 358 A schema node instance of this type will be set to zero (0) 359 on creation and will thereafter increase monotonically until 360 it reaches a maximum value of 2^64-1 (18446744073709551615 361 decimal), when it wraps around and starts increasing again 362 from zero. 364 Provided that an application discovers a new schema node 365 instance of this type within the minimum time to wrap, it 366 can use the 'initial' value as a delta. It is important for 367 a management station to be aware of this minimum time and the 368 actual time between polls, and to discard data if the actual 369 time is too long or there is no defined minimum time. 371 In the value set and its semantics, this type is equivalent 372 to the ZeroBasedCounter64 textual convention of the SMIv2."; 373 reference 374 "RFC 2856: Textual Conventions for Additional High Capacity 375 Data Types"; 376 } 378 typedef gauge32 { 379 type uint32; 380 description 381 "The gauge32 type represents a non-negative integer, which 382 may increase or decrease, but shall never exceed a maximum 383 value, nor fall below a minimum value. The maximum value 384 cannot be greater than 2^32-1 (4294967295 decimal), and 385 the minimum value cannot be smaller than 0. The value of 386 a gauge32 has its maximum value whenever the information 387 being modeled is greater than or equal to its maximum 388 value, and has its minimum value whenever the information 389 being modeled is smaller than or equal to its minimum value. 390 If the information being modeled subsequently decreases 391 below (increases above) the maximum (minimum) value, the 392 gauge32 also decreases (increases). 394 In the value set and its semantics, this type is equivalent 395 to the Gauge32 type of the SMIv2."; 396 reference 397 "RFC 2578: Structure of Management Information Version 2 398 (SMIv2)"; 399 } 401 typedef gauge64 { 402 type uint64; 403 description 404 "The gauge64 type represents a non-negative integer, which 405 may increase or decrease, but shall never exceed a maximum 406 value, nor fall below a minimum value. The maximum value 407 cannot be greater than 2^64-1 (18446744073709551615), and 408 the minimum value cannot be smaller than 0. The value of 409 a gauge64 has its maximum value whenever the information 410 being modeled is greater than or equal to its maximum 411 value, and has its minimum value whenever the information 412 being modeled is smaller than or equal to its minimum value. 413 If the information being modeled subsequently decreases 414 below (increases above) the maximum (minimum) value, the 415 gauge64 also decreases (increases). 417 In the value set and its semantics, this type is equivalent 418 to the CounterBasedGauge64 SMIv2 textual convention defined 419 in RFC 2856"; 420 reference 421 "RFC 2856: Textual Conventions for Additional High Capacity 422 Data Types"; 423 } 425 /*** collection of identifier-related types ***/ 426 typedef object-identifier { 427 type string { 428 pattern '(([0-1](\.[1-3]?[0-9]))|(2\.(0|([1-9]\d*))))' 429 + '(\.(0|([1-9]\d*)))*'; 430 } 431 description 432 "The object-identifier type represents administratively 433 assigned names in a registration-hierarchical-name tree. 435 Values of this type are denoted as a sequence of numerical 436 non-negative sub-identifier values. Each sub-identifier 437 value MUST NOT exceed 2^32-1 (4294967295). Sub-identifiers 438 are separated by single dots and without any intermediate 439 whitespace. 441 The ASN.1 standard restricts the value space of the first 442 sub-identifier to 0, 1, or 2. Furthermore, the value space 443 of the second sub-identifier is restricted to the range 444 0 to 39 if the first sub-identifier is 0 or 1. Finally, 445 the ASN.1 standard requires that an object identifier 446 has always at least two sub-identifiers. The pattern 447 captures these restrictions. 449 Although the number of sub-identifiers is not limited, 450 module designers should realize that there may be 451 implementations that stick with the SMIv2 limit of 128 452 sub-identifiers. 454 This type is a superset of the SMIv2 OBJECT IDENTIFIER type 455 since it is not restricted to 128 sub-identifiers. Hence, 456 this type SHOULD NOT be used to represent the SMIv2 OBJECT 457 IDENTIFIER type; the object-identifier-128 type SHOULD be 458 used instead."; 459 reference 460 "ISO9834-1: Information technology -- Open Systems 461 Interconnection -- Procedures for the operation of OSI 462 Registration Authorities: General procedures and top 463 arcs of the ASN.1 Object Identifier tree"; 464 } 466 typedef object-identifier-128 { 467 type object-identifier { 468 pattern '\d*(\.\d*){1,127}'; 469 } 470 description 471 "This type represents object-identifiers restricted to 128 472 sub-identifiers. 474 In the value set and its semantics, this type is equivalent 475 to the OBJECT IDENTIFIER type of the SMIv2."; 476 reference 477 "RFC 2578: Structure of Management Information Version 2 478 (SMIv2)"; 479 } 481 /*** collection of types related to date and time ***/ 483 typedef date-and-time { 484 type string { 485 pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?' 486 + '(Z|[\+\-]\d{2}:\d{2})'; 487 } 488 description 489 "The date-and-time type is a profile of the ISO 8601 490 standard for representation of dates and times using the 491 Gregorian calendar. The profile is defined by the 492 date-time production in Section 5.6 of RFC 3339. 494 The date-and-time type is compatible with the dateTime XML 495 schema type with the following notable exceptions: 497 (a) The date-and-time type does not allow negative years. 499 (b) The date-and-time time-offset -00:00 indicates an unknown 500 time zone (see RFC 3339) while -00:00 and +00:00 and Z 501 all represent the same time zone in dateTime. 503 (c) The canonical format (see below) of date-and-time values 504 differs from the canonical format used by the dateTime XML 505 schema type, which requires all times to be in UTC using 506 the time-offset 'Z'. 508 This type is not equivalent to the DateAndTime textual 509 convention of the SMIv2 since RFC 3339 uses a different 510 separator between full-date and full-time and provides 511 higher resolution of time-secfrac. 513 The canonical format for date-and-time values with a known time 514 zone uses a numeric time zone offset that is calculated using 515 the device's configured known offset to UTC time. A change of 516 the device's offset to UTC time will cause date-and-time values 517 to change accordingly. Such changes might happen periodically 518 in case a server follows automatically daylight saving time 519 (DST) time zone offset changes. The canonical format for 520 date-and-time values with an unknown time zone (usually 521 referring to the notion of local time) uses the time-offset 522 -00:00."; 523 reference 524 "RFC 3339: Date and Time on the Internet: Timestamps 525 RFC 2579: Textual Conventions for SMIv2 526 XSD-TYPES: XML Schema Part 2: Datatypes Second Edition"; 527 } 529 typedef date { 530 type string { 531 pattern '\d{4}-\d{2}-\d{2}' 532 + '(Z|[\+\-]\d{2}:\d{2})'; 533 } 534 description 535 "The date type represents a time-interval of the length 536 of a day, i.e., 24 hours. 538 The date type is compatible with the date XML schema 539 type with the following notable exceptions: 541 (a) The date type does not allow negative years. 543 (b) The date time-offset -00:00 indicates an unknown 544 time zone (see RFC 3339) while -00:00 and +00:00 and Z 545 all represent the same time zone in date. 547 (c) The canonical format (see below) of data values 548 differs from the canonical format used by the date XML 549 schema type, which requires all times to be in UTC using 550 the time-offset 'Z'. 552 The canonical format for date values with a known time 553 zone uses a numeric time zone offset that is calculated using 554 the device's configured known offset to UTC time. A change of 555 the device's offset to UTC time will cause date values 556 to change accordingly. Such changes might happen periodically 557 in case a server follows automatically daylight saving time 558 (DST) time zone offset changes. The canonical format for 559 date values with an unknown time zone (usually referring 560 to the notion of local time) uses the time-offset -00:00."; 561 reference 562 "RFC 3339: Date and Time on the Internet: Timestamps 563 XSD-TYPES: XML Schema Part 2: Datatypes Second Edition"; 564 } 566 /* 567 * DISCUSS: 568 * - XML schema seems to use a different canonical format, we 569 * need to take a closer look how to define the canonical format 570 * given that a data really identifies a 24 hour interval and 571 * what XSD means with 'interval midpoint'. 572 */ 574 typedef time { 575 type string { 576 pattern '\d{2}:\d{2}:\d{2}(\.\d+)?' 577 + '(Z|[\+\-]\d{2}:\d{2})'; 578 } 579 description 580 "The time type represents an instance of time of zero-duration 581 that recurs every day. 583 The time type is compatible with the time XML schema 584 type with the following notable exceptions: 586 (a) The time time-offset -00:00 indicates an unknown 587 time zone (see RFC 3339) while -00:00 and +00:00 and Z 588 all represent the same time zone in time. 590 (c) The canonical format (see below) of time values 591 differs from the canonical format used by the time XML 592 schema type, which requires all times to be in UTC using 593 the time-offset 'Z'. 595 The canonical format for time values with a known time 596 zone uses a numeric time zone offset that is calculated using 597 the device's configured known offset to UTC time. A change of 598 the device's offset to UTC time will cause time values 599 to change accordingly. Such changes might happen periodically 600 in case a server follows automatically daylight saving time 601 (DST) time zone offset changes. The canonical format for 602 time values with an unknown time zone (usually referring 603 to the notion of local time) uses the time-offset -00:00."; 604 reference 605 "RFC 3339: Date and Time on the Internet: Timestamps 606 XSD-TYPES: XML Schema Part 2: Datatypes Second Edition"; 607 } 609 typedef hours { 610 type uint32; 611 units "hours"; 612 description 613 "A period of time, measured in units of hours."; 614 } 616 typedef minutes { 617 type uint32; 618 units "minutes"; 619 description 620 "A period of time, measured in units of minutes."; 621 } 623 typedef seconds { 624 type uint32; 625 units "seconds"; 626 description 627 "A period of time, measured in units of seconds. 628 The maximum duration that can be expressed is in the 629 order of 49710 days and 6 hours and 28 minutes and 15 630 seconds."; 631 } 633 typedef centiseconds { 634 type uint32; 635 units "centiseconds"; 636 description 637 "A period of time, measured in units of 10^-2 seconds. 638 The maximum duration that can be expressed is in the 639 order of 497 days and 2 hours and 27 minutes and 52 640 seconds."; 641 } 643 typedef milliseconds { 644 type uint32; 645 units "milliseconds"; 646 description 647 "A period of time, measured in units of 10^-3 seconds. 648 The maximum duration that can be expressed is in the 649 order of 49 days and 17 hours and 2 minutes and 47 650 seconds."; 651 } 653 typedef microseconds { 654 type uint32; 655 units "microseconds"; 656 description 657 "A period of time, measured in units of 10^-6 seconds. 658 The maximum duration that can be expressed is in the 659 order of 1 hour and 11 minutes and 34 seconds."; 660 } 662 typedef nanoseconds { 663 type uint32; 664 units "nanoseconds"; 665 description 666 "A period of time, measured in units of 10^-9 seconds. 667 The maximum duration that can be expressed is in the 668 order of 4 seconds."; 669 } 671 /* 672 * DISCUSS: 673 * - do we need (nano|micro|milli)seconds with 64 bits? 674 * - do we add typedef timeinterval { type centiseconds 675 * { range 0..2147483647 } } for compatibility with SMIv2? 676 */ 678 typedef timeticks { 679 type uint32; 680 description 681 "The timeticks type represents a non-negative integer that 682 represents the time, modulo 2^32 (4294967296 decimal), in 683 hundredths of a second between two epochs. When a schema 684 node is defined that uses this type, the description of 685 the schema node identifies both of the reference epochs. 687 In the value set and its semantics, this type is equivalent 688 to the TimeTicks type of the SMIv2."; 689 reference 690 "RFC 2578: Structure of Management Information Version 2 691 (SMIv2)"; 692 } 694 typedef timestamp { 695 type yang:timeticks; 696 description 697 "The timestamp type represents the value of an associated 698 timeticks schema node instance at which a specific occurrence 699 happened. The specific occurrence must be defined in the 700 description of any schema node defined using this type. When 701 the specific occurrence occurred prior to the last time the 702 associated timeticks schema node instance was zero, then the 703 timestamp value is zero. 705 Note that this requires all timestamp values to be reset to 706 zero when the value of the associated timeticks schema node 707 instance reaches 497+ days and wraps around to zero. 709 The associated timeticks schema node must be specified 710 in the description of any schema node using this type. 712 In the value set and its semantics, this type is equivalent 713 to the TimeStamp textual convention of the SMIv2."; 715 reference 716 "RFC 2579: Textual Conventions for SMIv2"; 717 } 719 /*** collection of generic address types ***/ 721 typedef phys-address { 722 type string { 723 pattern '([0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*)?'; 724 } 725 description 726 "Represents media- or physical-level addresses represented 727 as a sequence octets, each octet represented by two hexadecimal 728 numbers. Octets are separated by colons. The canonical 729 representation uses lowercase characters. 731 In the value set and its semantics, this type is equivalent 732 to the PhysAddress textual convention of the SMIv2."; 733 reference 734 "RFC 2579: Textual Conventions for SMIv2"; 735 } 737 typedef mac-address { 738 type string { 739 pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}'; 740 } 741 description 742 "The mac-address type represents an IEEE 802 MAC address. 743 The canonical representation uses lowercase characters. 745 In the value set and its semantics, this type is equivalent 746 to the MacAddress textual convention of the SMIv2."; 747 reference 748 "IEEE 802: IEEE Standard for Local and Metropolitan Area 749 Networks: Overview and Architecture 750 RFC 2579: Textual Conventions for SMIv2"; 751 } 753 /*** collection of XML-specific types ***/ 755 typedef xpath1.0 { 756 type string; 757 description 758 "This type represents an XPATH 1.0 expression. 760 When a schema node is defined that uses this type, the 761 description of the schema node MUST specify the XPath 762 context in which the XPath expression is evaluated."; 764 reference 765 "XPATH: XML Path Language (XPath) Version 1.0"; 766 } 768 /* 769 * DISCUSS: 770 * - How do we deal with xpath expressions in other encodings 771 * such as JSON. Do we assume an xpath context populated with 772 * module names such that module names can be used to qualify 773 * path expressions. This may need discussion and/or a new 774 * definition. 775 * - This interacts with the definition of node-instance-identifier. 776 */ 778 /*** collection of string types ***/ 780 typedef hex-string { 781 type string { 782 pattern '([0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*)?'; 783 } 784 description 785 "A hexadecimal string with octets represented as hex digits 786 separated by colons. The canonical representation uses 787 lowercase characters."; 788 } 790 typedef uuid { 791 type string { 792 pattern '[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-' 793 + '[0-9a-fA-F]{4}-[0-9a-fA-F]{12}'; 794 } 795 description 796 "A Universally Unique IDentifier in the string representation 797 defined in RFC 4122. The canonical representation uses 798 lowercase characters. 800 The following is an example of a UUID in string representation: 801 f81d4fae-7dec-11d0-a765-00a0c91e6bf6 802 "; 803 reference 804 "RFC 4122: A Universally Unique IDentifier (UUID) URN 805 Namespace"; 806 } 808 typedef dotted-quad { 809 type string { 810 pattern 811 '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}' 813 + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'; 814 } 815 description 816 "An unsigned 32-bit number expressed in the dotted-quad 817 notation, i.e., four octets written as decimal numbers 818 and separated with the '.' (full stop) character."; 819 } 821 /*** collection of YANG specific types ***/ 823 typedef yang-identifier { 824 type string { 825 length "1..max"; 826 pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*'; 827 pattern '.|..|[^xX].*|.[^mM].*|..[^lL].*'; 828 } 829 description 830 "A YANG identifier string as defined by the 'identifier' 831 rule in Section 12 of RFC 6020. An identifier must 832 start with an alphabetic character or an underscore 833 followed by an arbitrary sequence of alphabetic or 834 numeric characters, underscores, hyphens, or dots. 836 A YANG identifier MUST NOT start with any possible 837 combination of the lowercase or uppercase character 838 sequence 'xml'."; 839 reference 840 "RFC 6020: YANG - A Data Modeling Language for the Network 841 Configuration Protocol (NETCONF)"; 842 } 844 typedef revision-identifier { 845 type date { 846 pattern '\d{4}-\d{2}-\d{2}'; 847 } 848 description 849 "Represents a specific revision of a YANG module by means of 850 a date value without a time zone."; 851 } 853 typedef node-instance-identifier { 854 type xpath1.0; 855 description 856 "Path expression used to represent a special 857 data node, action, or notification instance-identifier 858 string. 860 A node-instance-identifier value is an 861 unrestricted YANG instance-identifier expression. 863 All the same rules as an instance-identifier apply, 864 except that predicates for keys are optional. If a key 865 predicate is missing, then the node-instance-identifier 866 represents all possible server instances for that key. 868 This XML Path Language (XPath) expression is evaluated in the 869 following context: 871 o The set of namespace declarations are those in scope on 872 the leaf element where this type is used. 874 o The set of variable bindings contains one variable, 875 'USER', which contains the name of the user of the 876 current session. 878 o The function library is the core function library, but 879 note that due to the syntax restrictions of an 880 instance-identifier, no functions are allowed. 882 o The context node is the root node in the data tree. 884 The accessible tree includes actions and notifications tied 885 to data nodes."; 886 } 888 /* 889 * DISCUSS: 890 * - This is taken from RFC 8341 and the idea is that this definition 891 * is useful without requiring a dependency on NACM 892 * - What does the second bullet actually do? Do we keep this? 893 * - How does this work with JSON? Can we make this encoding neutral 894 * (but then we knowingly depart from NACM)? 895 * - This interacts with the definition of xpath1.0. 896 */ 898 /* DISCUSS: 899 * - It was suggested to add types for longitude, latitude, 900 * postal code, country-code. Do we go there or do we leave 901 * these for other modules to define? 902 */ 904 /* DISCUSS: 905 * - It was suggested to add percentage types but they tend to differ 906 * widely. However, percentages are also widely used. 907 */ 908 } 909 911 4. Internet-Specific Derived Types 913 The ietf-inet-types YANG module references [RFC0768], [RFC0791], 914 [RFC0793], [RFC0952], [RFC1034], [RFC1123], [RFC1930], [RFC2460], 915 [RFC2474], [RFC2780], [RFC2782], [RFC3289], [RFC3305], [RFC3595], 916 [RFC3986], [RFC4001], [RFC4007], [RFC4271], [RFC4291], [RFC4340], 917 [RFC4960], [RFC5017], [RFC5890], [RFC5952], and [RFC6793]. 919 file "ietf-inet-types@2019-03-11.yang" 921 module ietf-inet-types { 923 namespace "urn:ietf:params:xml:ns:yang:ietf-inet-types"; 924 prefix "inet"; 926 organization 927 "IETF NETMOD (Network Modeling) Working Group"; 929 contact 930 "WG Web: 931 WG List: 933 Editor: Juergen Schoenwaelder 934 "; 936 description 937 "This module contains a collection of generally useful derived 938 YANG data types for Internet addresses and related things. 940 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 941 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 942 'MAY', and 'OPTIONAL' in this document are to be interpreted as 943 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 944 they appear in all capitals, as shown here. 946 Copyright (c) 2019 IETF Trust and the persons identified as 947 authors of the code. All rights reserved. 949 Redistribution and use in source and binary forms, with or 950 without modification, is permitted pursuant to, and subject 951 to the license terms contained in, the Simplified BSD License 952 set forth in Section 4.c of the IETF Trust's Legal Provisions 953 Relating to IETF Documents 954 (http://trustee.ietf.org/license-info). 956 This version of this YANG module is part of RFC XXXX; 957 see the RFC itself for full legal notices."; 959 revision 2019-03-11 { 960 description 961 "This revision adds the following new data types: 962 - email-address"; 963 reference 964 "RFC XXXX: Common YANG Data Types"; 965 } 967 revision 2013-07-15 { 968 description 969 "This revision adds the following new data types: 970 - ip-address-no-zone 971 - ipv4-address-no-zone 972 - ipv6-address-no-zone"; 973 reference 974 "RFC 6991: Common YANG Data Types"; 975 } 977 revision 2010-09-24 { 978 description 979 "Initial revision."; 980 reference 981 "RFC 6021: Common YANG Data Types"; 982 } 984 /*** collection of types related to protocol fields ***/ 986 typedef ip-version { 987 type enumeration { 988 enum unknown { 989 value "0"; 990 description 991 "An unknown or unspecified version of the Internet 992 protocol."; 993 } 994 enum ipv4 { 995 value "1"; 996 description 997 "The IPv4 protocol as defined in RFC 791."; 998 } 999 enum ipv6 { 1000 value "2"; 1001 description 1002 "The IPv6 protocol as defined in RFC 2460."; 1003 } 1004 } 1005 description 1006 "This value represents the version of the IP protocol. 1008 In the value set and its semantics, this type is equivalent 1009 to the InetVersion textual convention of the SMIv2."; 1010 reference 1011 "RFC 791: Internet Protocol 1012 RFC 2460: Internet Protocol, Version 6 (IPv6) Specification 1013 RFC 4001: Textual Conventions for Internet Network Addresses"; 1014 } 1016 typedef dscp { 1017 type uint8 { 1018 range "0..63"; 1019 } 1020 description 1021 "The dscp type represents a Differentiated Services Code Point 1022 that may be used for marking packets in a traffic stream. 1024 In the value set and its semantics, this type is equivalent 1025 to the Dscp textual convention of the SMIv2."; 1026 reference 1027 "RFC 3289: Management Information Base for the Differentiated 1028 Services Architecture 1029 RFC 2474: Definition of the Differentiated Services Field 1030 (DS Field) in the IPv4 and IPv6 Headers 1031 RFC 2780: IANA Allocation Guidelines For Values In 1032 the Internet Protocol and Related Headers"; 1033 } 1035 typedef ipv6-flow-label { 1036 type uint32 { 1037 range "0..1048575"; 1038 } 1039 description 1040 "The ipv6-flow-label type represents the flow identifier or 1041 Flow Label in an IPv6 packet header that may be used to 1042 discriminate traffic flows. 1044 In the value set and its semantics, this type is equivalent 1045 to the IPv6FlowLabel textual convention of the SMIv2."; 1046 reference 1047 "RFC 3595: Textual Conventions for IPv6 Flow Label 1048 RFC 2460: Internet Protocol, Version 6 (IPv6) Specification"; 1049 } 1051 typedef port-number { 1052 type uint16 { 1053 range "0..65535"; 1054 } 1055 description 1056 "The port-number type represents a 16-bit port number of an 1057 Internet transport-layer protocol such as UDP, TCP, DCCP, or 1058 SCTP. Port numbers are assigned by IANA. A current list of 1059 all assignments is available from . 1061 Note that the port number value zero is reserved by IANA. In 1062 situations where the value zero does not make sense, it can 1063 be excluded by subtyping the port-number type. 1065 In the value set and its semantics, this type is equivalent 1066 to the InetPortNumber textual convention of the SMIv2."; 1067 reference 1068 "RFC 768: User Datagram Protocol 1069 RFC 793: Transmission Control Protocol 1070 RFC 4960: Stream Control Transmission Protocol 1071 RFC 4340: Datagram Congestion Control Protocol (DCCP) 1072 RFC 4001: Textual Conventions for Internet Network Addresses"; 1073 } 1075 /*** collection of types related to autonomous systems ***/ 1077 typedef as-number { 1078 type uint32; 1079 description 1080 "The as-number type represents autonomous system numbers 1081 which identify an Autonomous System (AS). An AS is a set 1082 of routers under a single technical administration, using 1083 an interior gateway protocol and common metrics to route 1084 packets within the AS, and using an exterior gateway 1085 protocol to route packets to other ASes. IANA maintains 1086 the AS number space and has delegated large parts to the 1087 regional registries. 1089 Autonomous system numbers were originally limited to 16 1090 bits. BGP extensions have enlarged the autonomous system 1091 number space to 32 bits. This type therefore uses an uint32 1092 base type without a range restriction in order to support 1093 a larger autonomous system number space. 1095 In the value set and its semantics, this type is equivalent 1096 to the InetAutonomousSystemNumber textual convention of 1097 the SMIv2."; 1098 reference 1099 "RFC 1930: Guidelines for creation, selection, and registration 1100 of an Autonomous System (AS) 1101 RFC 4271: A Border Gateway Protocol 4 (BGP-4) 1102 RFC 4001: Textual Conventions for Internet Network Addresses 1103 RFC 6793: BGP Support for Four-Octet Autonomous System (AS) 1104 Number Space"; 1105 } 1107 /*** collection of types related to IP addresses and hostnames ***/ 1109 typedef ip-address { 1110 type union { 1111 type inet:ipv4-address; 1112 type inet:ipv6-address; 1113 } 1114 description 1115 "The ip-address type represents an IP address and is IP 1116 version neutral. The format of the textual representation 1117 implies the IP version. This type supports scoped addresses 1118 by allowing zone identifiers in the address format."; 1119 reference 1120 "RFC 4007: IPv6 Scoped Address Architecture"; 1121 } 1123 typedef ipv4-address { 1124 type string { 1125 pattern 1126 '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}' 1127 + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])' 1128 + '(%[\p{N}\p{L}]+)?'; 1129 } 1130 description 1131 "The ipv4-address type represents an IPv4 address in 1132 dotted-quad notation. The IPv4 address may include a zone 1133 index, separated by a % sign. 1135 The zone index is used to disambiguate identical address 1136 values. For link-local addresses, the zone index will 1137 typically be the interface index number or the name of an 1138 interface. If the zone index is not present, the default 1139 zone of the device will be used. 1141 The canonical format for the zone index is the numerical 1142 format"; 1143 } 1145 typedef ipv6-address { 1146 type string { 1147 pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}' 1148 + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|' 1149 + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}' 1150 + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))' 1151 + '(%[\p{N}\p{L}]+)?'; 1153 pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|' 1154 + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)' 1155 + '(%.+)?'; 1156 } 1157 description 1158 "The ipv6-address type represents an IPv6 address in full, 1159 mixed, shortened, and shortened-mixed notation. The IPv6 1160 address may include a zone index, separated by a % sign. 1162 The zone index is used to disambiguate identical address 1163 values. For link-local addresses, the zone index will 1164 typically be the interface index number or the name of an 1165 interface. If the zone index is not present, the default 1166 zone of the device will be used. 1168 The canonical format of IPv6 addresses uses the textual 1169 representation defined in Section 4 of RFC 5952. The 1170 canonical format for the zone index is the numerical 1171 format as described in Section 11.2 of RFC 4007."; 1172 reference 1173 "RFC 4291: IP Version 6 Addressing Architecture 1174 RFC 4007: IPv6 Scoped Address Architecture 1175 RFC 5952: A Recommendation for IPv6 Address Text 1176 Representation"; 1177 } 1179 typedef ip-address-no-zone { 1180 type union { 1181 type inet:ipv4-address-no-zone; 1182 type inet:ipv6-address-no-zone; 1183 } 1184 description 1185 "The ip-address-no-zone type represents an IP address and is 1186 IP version neutral. The format of the textual representation 1187 implies the IP version. This type does not support scoped 1188 addresses since it does not allow zone identifiers in the 1189 address format."; 1190 reference 1191 "RFC 4007: IPv6 Scoped Address Architecture"; 1192 } 1194 typedef ipv4-address-no-zone { 1195 type inet:ipv4-address { 1196 pattern '[0-9\.]*'; 1197 } 1198 description 1199 "An IPv4 address without a zone index. This type, derived from 1200 ipv4-address, may be used in situations where the zone is known 1201 from the context and hence no zone index is needed."; 1202 } 1204 typedef ipv6-address-no-zone { 1205 type inet:ipv6-address { 1206 pattern '[0-9a-fA-F:\.]*'; 1207 } 1208 description 1209 "An IPv6 address without a zone index. This type, derived from 1210 ipv6-address, may be used in situations where the zone is known 1211 from the context and hence no zone index is needed."; 1212 reference 1213 "RFC 4291: IP Version 6 Addressing Architecture 1214 RFC 4007: IPv6 Scoped Address Architecture 1215 RFC 5952: A Recommendation for IPv6 Address Text 1216 Representation"; 1217 } 1219 typedef ip-prefix { 1220 type union { 1221 type inet:ipv4-prefix; 1222 type inet:ipv6-prefix; 1223 } 1224 description 1225 "The ip-prefix type represents an IP prefix and is IP 1226 version neutral. The format of the textual representations 1227 implies the IP version."; 1228 } 1230 typedef ipv4-prefix { 1231 type string { 1232 pattern 1233 '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}' 1234 + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])' 1235 + '/(([0-9])|([1-2][0-9])|(3[0-2]))'; 1236 } 1237 description 1238 "The ipv4-prefix type represents an IPv4 address prefix. 1239 The prefix length is given by the number following the 1240 slash character and must be less than or equal to 32. 1242 A prefix length value of n corresponds to an IP address 1243 mask that has n contiguous 1-bits from the most 1244 significant bit (MSB) and all other bits set to 0. 1246 The canonical format of an IPv4 prefix has all bits of 1247 the IPv4 address set to zero that are not part of the 1248 IPv4 prefix."; 1250 } 1252 typedef ipv6-prefix { 1253 type string { 1254 pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}' 1255 + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|' 1256 + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}' 1257 + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))' 1258 + '(/(([0-9])|([0-9]{2})|(1[0-1][0-9])|(12[0-8])))'; 1259 pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|' 1260 + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)' 1261 + '(/.+)'; 1262 } 1263 description 1264 "The ipv6-prefix type represents an IPv6 address prefix. 1265 The prefix length is given by the number following the 1266 slash character and must be less than or equal to 128. 1268 A prefix length value of n corresponds to an IP address 1269 mask that has n contiguous 1-bits from the most 1270 significant bit (MSB) and all other bits set to 0. 1272 The IPv6 address should have all bits that do not belong 1273 to the prefix set to zero. 1275 The canonical format of an IPv6 prefix has all bits of 1276 the IPv6 address set to zero that are not part of the 1277 IPv6 prefix. Furthermore, the IPv6 address is represented 1278 as defined in Section 4 of RFC 5952."; 1279 reference 1280 "RFC 5952: A Recommendation for IPv6 Address Text 1281 Representation"; 1282 } 1284 /*** collection of domain name and URI types ***/ 1286 typedef domain-name { 1287 type string { 1288 length "1..253"; 1289 pattern 1290 '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*' 1291 + '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)' 1292 + '|\.'; 1293 } 1294 description 1295 "The domain-name type represents a DNS domain name. The 1296 name SHOULD be fully qualified whenever possible. 1298 Internet domain names are only loosely specified. Section 1299 3.5 of RFC 1034 recommends a syntax (modified in Section 1300 2.1 of RFC 1123). The pattern above is intended to allow 1301 for current practice in domain name use, and some possible 1302 future expansion. It is designed to hold various types of 1303 domain names, including names used for A or AAAA records 1304 (host names) and other records, such as SRV records. Note 1305 that Internet host names have a stricter syntax (described 1306 in RFC 952) than the DNS recommendations in RFCs 1034 and 1307 1123, and that systems that want to store host names in 1308 schema node instances using the domain-name type are 1309 recommended to adhere to this stricter standard to ensure 1310 interoperability. 1312 The encoding of DNS names in the DNS protocol is limited 1313 to 255 characters. Since the encoding consists of labels 1314 prefixed by a length bytes and there is a trailing NULL 1315 byte, only 253 characters can appear in the textual dotted 1316 notation. 1318 The description clause of schema nodes using the domain-name 1319 type MUST describe when and how these names are resolved to 1320 IP addresses. Note that the resolution of a domain-name value 1321 may require to query multiple DNS records (e.g., A for IPv4 1322 and AAAA for IPv6). The order of the resolution process and 1323 which DNS record takes precedence can either be defined 1324 explicitly or may depend on the configuration of the 1325 resolver. 1327 Domain-name values use the US-ASCII encoding. Their canonical 1328 format uses lowercase US-ASCII characters. Internationalized 1329 domain names MUST be A-labels as per RFC 5890."; 1330 reference 1331 "RFC 952: DoD Internet Host Table Specification 1332 RFC 1034: Domain Names - Concepts and Facilities 1333 RFC 1123: Requirements for Internet Hosts -- Application 1334 and Support 1335 RFC 2782: A DNS RR for specifying the location of services 1336 (DNS SRV) 1337 RFC 5890: Internationalized Domain Names in Applications 1338 (IDNA): Definitions and Document Framework"; 1339 } 1341 typedef host { 1342 type union { 1343 type inet:ip-address; 1344 type inet:domain-name; 1345 } 1346 description 1347 "The host type represents either an IP address or a DNS 1348 domain name."; 1349 } 1351 typedef uri { 1352 type string; 1353 description 1354 "The uri type represents a Uniform Resource Identifier 1355 (URI) as defined by STD 66. 1357 Objects using the uri type MUST be in US-ASCII encoding, 1358 and MUST be normalized as described by RFC 3986 Sections 1359 6.2.1, 6.2.2.1, and 6.2.2.2. All unnecessary 1360 percent-encoding is removed, and all case-insensitive 1361 characters are set to lowercase except for hexadecimal 1362 digits, which are normalized to uppercase as described in 1363 Section 6.2.2.1. 1365 The purpose of this normalization is to help provide 1366 unique URIs. Note that this normalization is not 1367 sufficient to provide uniqueness. Two URIs that are 1368 textually distinct after this normalization may still be 1369 equivalent. 1371 Objects using the uri type may restrict the schemes that 1372 they permit. For example, 'data:' and 'urn:' schemes 1373 might not be appropriate. 1375 A zero-length URI is not a valid URI. This can be used to 1376 express 'URI absent' where required. 1378 In the value set and its semantics, this type is equivalent 1379 to the Uri SMIv2 textual convention defined in RFC 5017."; 1380 reference 1381 "RFC 3986: Uniform Resource Identifier (URI): Generic Syntax 1382 RFC 3305: Report from the Joint W3C/IETF URI Planning Interest 1383 Group: Uniform Resource Identifiers (URIs), URLs, 1384 and Uniform Resource Names (URNs): Clarifications 1385 and Recommendations 1386 RFC 5017: MIB Textual Conventions for Uniform Resource 1387 Identifiers (URIs)"; 1388 } 1390 typedef email-address { 1391 type string { 1392 // dot-atom-text "@" ... 1393 pattern "[a-zA-Z0-9!#$%&'*+/=?^_`{|}~-]+" 1394 + "(\\.[a-zA-Z0-9!#$%&'*+/=?^_`{|}~-]+)*" 1395 + "@" 1396 + "[a-zA-Z0-9!#$%&'*+/=?^_`{|}~-]+" 1397 + "(\\.[a-zA-Z0-9!#$%&'*+/=?^_`{|}~-]+)*"; 1398 } 1399 description 1400 "The email-address type represents an email address as 1401 defined as addr-spec in RFC 5322 section 3.4.1."; 1402 reference 1403 "RFC 5322: Internet Message Format"; 1404 } 1406 /* 1407 * DISCUSS: 1408 * - It was suggested to add email types following RFC 5322 1409 * email-address (addr-spec, per Section 3.4.1) 1410 * named-email-address (name-addr, per Section 3.4) 1411 * - This sounds useful but the devil is in the details, 1412 * in particular name-addr is a quite complex construct; 1413 * perhaps addr-spec is sufficient, this is also the 1414 * format allowed in mailto: URIs (mailto: seems to use 1415 * only a subset of addr-spec which may be good enough 1416 * here as well). 1417 * - Need to define a pattern that has a meaningful trade-off 1418 * between precision and complexity (there are very tight 1419 * pattern that are very long and complex). The current 1420 * pattern does not take care of quoted-string, obs-local-part, 1421 * domain-literal, obs-domain. 1422 */ 1423 } 1425 1427 5. IANA Considerations 1429 This document registers two URIs in the IETF XML registry [RFC3688]. 1430 Following the format in RFC 3688, the following registrations have 1431 been made. 1433 URI: urn:ietf:params:xml:ns:yang:ietf-yang-types 1434 Registrant Contact: The NETMOD WG of the IETF. 1435 XML: N/A, the requested URI is an XML namespace. 1437 URI: urn:ietf:params:xml:ns:yang:ietf-inet-types 1438 Registrant Contact: The NETMOD WG of the IETF. 1439 XML: N/A, the requested URI is an XML namespace. 1441 This document registers two YANG modules in the YANG Module Names 1442 registry [RFC6020]. 1444 name: ietf-yang-types 1445 namespace: urn:ietf:params:xml:ns:yang:ietf-yang-types 1446 prefix: yang 1447 reference: RFC XXXX 1449 name: ietf-inet-types 1450 namespace: urn:ietf:params:xml:ns:yang:ietf-inet-types 1451 prefix: inet 1452 reference: RFC XXXX 1454 6. Security Considerations 1456 This document defines common data types using the YANG data modeling 1457 language. The definitions themselves have no security impact on the 1458 Internet, but the usage of these definitions in concrete YANG modules 1459 might have. The security considerations spelled out in the YANG 1460 specification [RFC7950] apply for this document as well. 1462 7. Contributors 1464 The following people contributed significantly to the initial version 1465 of this document: 1467 - Andy Bierman (Brocade) 1468 - Martin Bjorklund (Tail-f Systems) 1469 - Balazs Lengyel (Ericsson) 1470 - David Partain (Ericsson) 1471 - Phil Shafer (Juniper Networks) 1473 8. Acknowledgments 1475 The editor wishes to thank the following individuals for providing 1476 helpful comments on various versions of this document: Andy Bierman, 1477 Martin Bjorklund, Benoit Claise, Joel M. Halpern, Ladislav Lhotka, 1478 Lars-Johan Liman, and Dan Romascanu. 1480 Juergen Schoenwaelder was partly funded by Flamingo, a Network of 1481 Excellence project (ICT-318488) supported by the European Commission 1482 under its Seventh Framework Programme. 1484 9. References 1486 9.1. Normative References 1488 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1489 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1490 RFC2119, March 1997, 1491 . 1493 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 1494 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 1495 . 1497 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1498 DOI 10.17487/RFC3688, January 2004, 1499 . 1501 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1502 Resource Identifier (URI): Generic Syntax", STD 66, 1503 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1504 . 1506 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 1507 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 1508 DOI 10.17487/RFC4007, March 2005, 1509 . 1511 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1512 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1513 DOI 10.17487/RFC4122, July 2005, 1514 . 1516 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1517 Architecture", RFC 4291, DOI 10.17487/RFC4291, 1518 February 2006, . 1520 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1521 the Network Configuration Protocol (NETCONF)", RFC 6020, 1522 DOI 10.17487/RFC6020, October 2010, 1523 . 1525 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1526 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1527 . 1529 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1530 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1531 . 1533 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1534 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1535 May 2017, . 1537 [XPATH] Clark, J. and S. DeRose, "XML Path Language (XPath) 1538 Version 1.0", World Wide Web Consortium 1539 Recommendation REC-xpath-19991116, November 1999, 1540 . 1542 9.2. Informative References 1544 [IEEE802] IEEE, "IEEE Standard for Local and Metropolitan Area 1545 Networks: Overview and Architecture", IEEE Std. 802-2001. 1547 [ISO9834-1] 1548 ISO/IEC, "Information technology -- Open Systems 1549 Interconnection -- Procedures for the operation of OSI 1550 Registration Authorities: General procedures and top arcs 1551 of the ASN.1 Object Identifier tree", ISO/IEC 9834-1:2008, 1552 2008. 1554 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1555 DOI 10.17487/RFC0768, August 1980, 1556 . 1558 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1559 DOI 10.17487/RFC0791, September 1981, 1560 . 1562 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1563 RFC 793, DOI 10.17487/RFC0793, September 1981, 1564 . 1566 [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet 1567 host table specification", RFC 952, DOI 10.17487/RFC0952, 1568 October 1985, . 1570 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1571 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1572 . 1574 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 1575 Application and Support", STD 3, RFC 1123, DOI 10.17487/ 1576 RFC1123, October 1989, 1577 . 1579 [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, 1580 selection, and registration of an Autonomous System (AS)", 1581 BCP 6, RFC 1930, DOI 10.17487/RFC1930, March 1996, 1582 . 1584 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1585 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1586 December 1998, . 1588 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1589 "Definition of the Differentiated Services Field (DS 1590 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1591 DOI 10.17487/RFC2474, December 1998, 1592 . 1594 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1595 Schoenwaelder, Ed., "Structure of Management Information 1596 Version 2 (SMIv2)", STD 58, RFC 2578, DOI 10.17487/ 1597 RFC2578, April 1999, 1598 . 1600 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1601 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 1602 STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999, 1603 . 1605 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 1606 Values In the Internet Protocol and Related Headers", 1607 BCP 37, RFC 2780, DOI 10.17487/RFC2780, March 2000, 1608 . 1610 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1611 specifying the location of services (DNS SRV)", RFC 2782, 1612 DOI 10.17487/RFC2782, February 2000, 1613 . 1615 [RFC2856] Bierman, A., McCloghrie, K., and R. Presuhn, "Textual 1616 Conventions for Additional High Capacity Data Types", 1617 RFC 2856, DOI 10.17487/RFC2856, June 2000, 1618 . 1620 [RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information 1621 Base for the Differentiated Services Architecture", 1622 RFC 3289, DOI 10.17487/RFC3289, May 2002, 1623 . 1625 [RFC3305] Mealling, M., Ed. and R. Denenberg, Ed., "Report from the 1626 Joint W3C/IETF URI Planning Interest Group: Uniform 1627 Resource Identifiers (URIs), URLs, and Uniform Resource 1628 Names (URNs): Clarifications and Recommendations", 1629 RFC 3305, DOI 10.17487/RFC3305, August 2002, 1630 . 1632 [RFC3595] Wijnen, B., "Textual Conventions for IPv6 Flow Label", 1633 RFC 3595, DOI 10.17487/RFC3595, September 2003, 1634 . 1636 [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. 1637 Schoenwaelder, "Textual Conventions for Internet Network 1638 Addresses", RFC 4001, DOI 10.17487/RFC4001, February 2005, 1639 . 1641 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1642 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1643 DOI 10.17487/RFC4271, January 2006, 1644 . 1646 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1647 Congestion Control Protocol (DCCP)", RFC 4340, 1648 DOI 10.17487/RFC4340, March 2006, 1649 . 1651 [RFC4502] Waldbusser, S., "Remote Network Monitoring Management 1652 Information Base Version 2", RFC 4502, DOI 10.17487/ 1653 RFC4502, May 2006, 1654 . 1656 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1657 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1658 . 1660 [RFC5017] McWalter, D., Ed., "MIB Textual Conventions for Uniform 1661 Resource Identifiers (URIs)", RFC 5017, DOI 10.17487/ 1662 RFC5017, September 2007, 1663 . 1665 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1666 DOI 10.17487/RFC5322, October 2008, 1667 . 1669 [RFC5890] Klensin, J., "Internationalized Domain Names for 1670 Applications (IDNA): Definitions and Document Framework", 1671 RFC 5890, DOI 10.17487/RFC5890, August 2010, 1672 . 1674 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1675 Address Text Representation", RFC 5952, DOI 10.17487/ 1676 RFC5952, August 2010, 1677 . 1679 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1680 and A. Bierman, Ed., "Network Configuration Protocol 1681 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1682 . 1684 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 1685 Autonomous System (AS) Number Space", RFC 6793, 1686 DOI 10.17487/RFC6793, December 2012, 1687 . 1689 [XSD-TYPES] 1690 Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes 1691 Second Edition", World Wide Web Consortium 1692 Recommendation REC-xmlschema-2-20041028, October 2004, 1693 . 1695 Appendix A. Changes from RFC 6991 1697 This version adds new type definitions to the YANG modules. The 1698 following new data types have been added to the ietf-yang-types 1699 module: 1701 o date, time 1703 o hours, minutes, seconds 1705 o centiseconds, milliseconds, microseconds, nanoseconds 1707 o revision-identifier, node-instance-identifier 1709 The following new data types have been added to the ietf-inet-types 1710 module: 1712 o email-address 1714 Appendix B. Changes from RFC 6021 1716 This version adds new type definitions to the YANG modules. The 1717 following new data types have been added to the ietf-yang-types 1718 module: 1720 o yang-identifier 1722 o hex-string 1724 o uuid 1726 o dotted-quad 1728 The following new data types have been added to the ietf-inet-types 1729 module: 1731 o ip-address-no-zone 1733 o ipv4-address-no-zone 1735 o ipv6-address-no-zone 1737 Author's Address 1739 Juergen Schoenwaelder (editor) 1740 Jacobs University 1742 Email: j.schoenwaelder@jacobs-university.de