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