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