idnits 2.17.1 draft-ietf-netmod-yang-types-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2588. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2599. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2606. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2612. == In addition to a regular copyright notice, the document also has a copyright notice embedded in the text. 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 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 933 has weird spacing: '...g-types urn...' == Line 934 has weird spacing: '...t-types urn...' == Line 935 has weird spacing: '...e-types urn...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 4, 2008) is 5706 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '0-1' is mentioned on line 2397, but not defined == Missing Reference: '1-3' is mentioned on line 2120, but not defined == Missing Reference: '0-9' is mentioned on line 2398, but not defined == Missing Reference: '1-9' is mentioned on line 2120, but not defined == Missing Reference: '0-4' is mentioned on line 2398, but not defined == Missing Reference: '0-5' is mentioned on line 2398, but not defined == Missing Reference: '6-9' is mentioned on line 2351, but not defined == Missing Reference: '3-9' is mentioned on line 2351, but not defined == Missing Reference: '0-9a-fA-F' is mentioned on line 1654, but not defined == Unused Reference: 'RFC0768' is defined on line 993, but no explicit reference was found in the text == Unused Reference: 'RFC0791' is defined on line 996, but no explicit reference was found in the text == Unused Reference: 'RFC0793' is defined on line 999, but no explicit reference was found in the text == Unused Reference: 'RFC1034' is defined on line 1002, but no explicit reference was found in the text == Unused Reference: 'RFC1123' is defined on line 1005, but no explicit reference was found in the text == Unused Reference: 'RFC1930' is defined on line 1008, but no explicit reference was found in the text == Unused Reference: 'RFC2021' is defined on line 1012, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 1016, but no explicit reference was found in the text == Unused Reference: 'RFC2474' is defined on line 1019, but no explicit reference was found in the text == Unused Reference: 'RFC2578' is defined on line 1024, but no explicit reference was found in the text == Unused Reference: 'RFC2579' is defined on line 1028, but no explicit reference was found in the text == Unused Reference: 'RFC2780' is defined on line 1032, but no explicit reference was found in the text == Unused Reference: 'RFC2856' is defined on line 1036, but no explicit reference was found in the text == Unused Reference: 'RFC2960' is defined on line 1040, but no explicit reference was found in the text == Unused Reference: 'RFC3289' is defined on line 1045, but no explicit reference was found in the text == Unused Reference: 'RFC3305' is defined on line 1049, but no explicit reference was found in the text == Unused Reference: 'RFC3339' is defined on line 1055, but no explicit reference was found in the text == Unused Reference: 'RFC3595' is defined on line 1058, but no explicit reference was found in the text == Unused Reference: 'RFC3986' is defined on line 1061, but no explicit reference was found in the text == Unused Reference: 'RFC4001' is defined on line 1065, but no explicit reference was found in the text == Unused Reference: 'RFC4007' is defined on line 1069, but no explicit reference was found in the text == Unused Reference: 'RFC4188' is defined on line 1073, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 1076, but no explicit reference was found in the text == Unused Reference: 'RFC4340' is defined on line 1079, but no explicit reference was found in the text == Unused Reference: 'RFC5017' is defined on line 1085, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-13) exists of draft-ietf-netmod-yang-01 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2021 (Obsoleted by RFC 4502) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2960 (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 4741 (Obsoleted by RFC 6241) Summary: 2 errors (**), 0 flaws (~~), 41 warnings (==), 13 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 September 4, 2008 5 Expires: March 8, 2009 7 Common YANG Data Types 8 draft-ietf-netmod-yang-types-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on March 8, 2009. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This document introduces a collection of common data types to be used 42 with the YANG data modeling language. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Core YANG Derived Types . . . . . . . . . . . . . . . . . . . 4 48 3. Internet Specific Derived Types . . . . . . . . . . . . . . . 12 49 4. IEEE Specific Derived Types . . . . . . . . . . . . . . . . . 20 50 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 51 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 52 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 25 53 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 54 8.1. Normative References . . . . . . . . . . . . . . . . . . . 26 55 8.2. Informative References . . . . . . . . . . . . . . . . . . 26 56 Appendix A. XSD Translations . . . . . . . . . . . . . . . . . . 29 57 A.1. XSD of Core YANG Derived Types . . . . . . . . . . . . . . 29 58 A.2. XSD of Internet Specific Derived Types . . . . . . . . . . 36 59 A.3. XSD of IEEE Specific Derived Types . . . . . . . . . . . . 44 60 Appendix B. RelaxNG Translations . . . . . . . . . . . . . . . . 47 61 B.1. RelaxNG of Core YANG Derived Types . . . . . . . . . . . . 47 62 B.2. RelaxNG of Internet Specific Derived Types . . . . . . . . 53 63 B.3. RelaxNG of IEEE Specific Derived Types . . . . . . . . . . 58 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 61 65 Intellectual Property and Copyright Statements . . . . . . . . . . 62 67 1. Introduction 69 YANG [YANG] is a data modeling language used to model configuration 70 and state data manipulated by the NETCONF [RFC4741] protocol. The 71 YANG language supports a small set of built-in data types and 72 provides mechanisms to derive other types from the built-in types. 74 This document introduces a collection of common data types derived 75 from the built-in YANG data types. The definitions are organized in 76 several YANG modules. The "yang-types" module contains generally 77 useful data types. The "inet-types" module contains definitions that 78 are relevant for the Internet protocol suite while the "ieee-types" 79 module contains definitions that are relevant for IEEE 802 protocols. 81 Their derived types are generally designed to be applicable for 82 modeling all areas of management information. 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 86 "OPTIONAL" in this document are to be interpreted as described in BCP 87 14, [RFC2119]. 89 2. Core YANG Derived Types 91 module yang-types { 93 namespace "urn:ietf:params:xml:ns:yang:yang-types"; 94 prefix "yang"; 96 organization 97 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 99 contact 100 "WG Web: 101 WG List: 103 WG Chair: David Partain 104 106 WG Chair: David Harrington 107 109 Editor: Juergen Schoenwaelder 110 "; 112 description 113 "This module contains a collection of generally useful derived 114 YANG data types. 116 Copyright (C) The IETF Trust (2008). This version of this 117 YANG module is part of RFC XXXX; see the RFC itself for full 118 legal notices."; 119 // RFC Ed.: replace XXXX with actual RFC number and remove this note 121 revision 2008-08-26 { 122 description 123 "Initial revision, published as RFC XXXX."; 124 } 125 // RFC Ed.: replace XXXX with actual RFC number and remove this note 127 /*** collection of counter and gauge types ***/ 129 typedef counter32 { 130 type uint32; 131 description 132 "The counter32 type represents a non-negative integer 133 which monotonically increases until it reaches a 134 maximum value of 2^32-1 (4294967295 decimal), when it 135 wraps around and starts increasing again from zero. 137 Counters have no defined `initial' value, and thus, a 138 single value of a counter has (in general) no information 139 content. Discontinuities in the monotonically increasing 140 value normally occur at re-initialization of the 141 management system, and at other times as specified in the 142 description of an object instance using this type. If 143 such other times can occur, for example, the creation of 144 an object instance of type counter32 at times other than 145 re-initialization, then a corresponding object should be 146 defined, with an appropriate type, to indicate the last 147 discontinuity. 149 The counter32 type should not be used for configuration 150 objects. A default statement should not be used for 151 attributes with a type value of counter32. 153 This type is in the value set and its semantics equivalent 154 to the Counter32 type of the SMIv2."; 155 reference 156 "RFC 2578: Structure of Management Information Version 2 (SMIv2)"; 157 } 159 typedef zero-based-counter32 { 160 type yang:counter32; 161 default "0"; 162 description 163 "The zero-based-counter32 type represents a counter32 164 which has the defined `initial' value zero. 166 Objects of this type will be set to zero(0) on creation 167 and will thereafter count appropriate events, wrapping 168 back to zero(0) when the value 2^32 is reached. 170 Provided that an application discovers the new object within 171 the minimum time to wrap it can use the initial value as a 172 delta since it last polled the table of which this object is 173 part. It is important for a management station to be aware 174 of this minimum time and the actual time between polls, and 175 to discard data if the actual time is too long or there is 176 no defined minimum time. 178 This type is in the value set and its semantics equivalent 179 to the ZeroBasedCounter32 textual convention of the SMIv2."; 180 reference 181 "RFC 2021: Remote Network Monitoring Management Information 182 Base Version 2 using SMIv2"; 183 } 184 typedef counter64 { 185 type uint64; 186 description 187 "The counter64 type represents a non-negative integer 188 which monotonically increases until it reaches a 189 maximum value of 2^64-1 (18446744073709551615), when 190 it wraps around and starts increasing again from zero. 192 Counters have no defined `initial' value, and thus, a 193 single value of a counter has (in general) no information 194 content. Discontinuities in the monotonically increasing 195 value normally occur at re-initialization of the 196 management system, and at other times as specified in the 197 description of an object instance using this type. If 198 such other times can occur, for example, the creation of 199 an object instance of type counter64 at times other than 200 re-initialization, then a corresponding object should be 201 defined, with an appropriate type, to indicate the last 202 discontinuity. 204 The counter64 type should not be used for configuration 205 objects. A default statement should not be used for 206 attributes with a type value of counter64. 208 This type is in the value set and its semantics equivalent 209 to the Counter64 type of the SMIv2."; 210 reference 211 "RFC 2578: Structure of Management Information Version 2 (SMIv2)"; 212 } 214 typedef zero-based-counter64 { 215 type yang:counter64; 216 default "0"; 217 description 218 "The zero-based-counter64 type represents a counter64 which 219 has the defined `initial' value zero. 221 Objects of this type will be set to zero(0) on creation 222 and will thereafter count appropriate events, wrapping 223 back to zero(0) when the value 2^64 is reached. 225 Provided that an application discovers the new object within 226 the minimum time to wrap it can use the initial value as a 227 delta since it last polled the table of which this object is 228 part. It is important for a management station to be aware 229 of this minimum time and the actual time between polls, and 230 to discard data if the actual time is too long or there is 231 no defined minimum time. 233 This type is in the value set and its semantics equivalent 234 to the ZeroBasedCounter64 textual convention of the SMIv2."; 235 reference 236 "RFC 2856: Textual Conventions for Additional High Capacity 237 Data Types"; 238 } 240 typedef gauge32 { 241 type uint32; 242 description 243 "The gauge32 type represents a non-negative integer, which 244 may increase or decrease, but shall never exceed a maximum 245 value, nor fall below a minimum value. The maximum value 246 can not be greater than 2^32-1 (4294967295 decimal), and 247 the minimum value can not be smaller than 0. The value of 248 a gauge32 has its maximum value whenever the information 249 being modeled is greater than or equal to its maximum 250 value, and has its minimum value whenever the information 251 being modeled is smaller than or equal to its minimum value. 252 If the information being modeled subsequently decreases 253 below (increases above) the maximum (minimum) value, the 254 gauge32 also decreases (increases). 256 This type is in the value set and its semantics equivalent 257 to the Counter32 type of the SMIv2."; 258 reference 259 "RFC 2578: Structure of Management Information Version 2 (SMIv2)"; 260 } 262 typedef gauge64 { 263 type uint64; 264 description 265 "The gauge64 type represents a non-negative integer, which 266 may increase or decrease, but shall never exceed a maximum 267 value, nor fall below a minimum value. The maximum value 268 can not be greater than 2^64-1 (18446744073709551615), and 269 the minimum value can not be smaller than 0. The value of 270 a gauge64 has its maximum value whenever the information 271 being modeled is greater than or equal to its maximum 272 value, and has its minimum value whenever the information 273 being modeled is smaller than or equal to its minimum value. 274 If the information being modeled subsequently decreases 275 below (increases above) the maximum (minimum) value, the 276 gauge64 also decreases (increases). 278 This type is in the value set and its semantics equivalent 279 to the CounterBasedGauge64 SMIv2 textual convention defined 280 in RFC 2856"; 282 reference 283 "RFC 2856: Textual Conventions for Additional High Capacity 284 Data Types"; 285 } 287 /*** collection of identifier related types ***/ 289 typedef object-identifier { 290 type string { 291 pattern '(([0-1](\.[1-3]?[0-9]))|(2.(0|([1-9]\d*))))' 292 + '(\.(0|([1-9]\d*)))*'; 293 } 294 description 295 "The object-identifier type represents administratively 296 assigned names in a registration-hierarchical-name tree. 298 Values of this type are denoted as a sequence of numerical 299 non-negative sub-identifier values. Each sub-identifier 300 value MUST NOT exceed 2^32-1 (4294967295). Sub-identifiers 301 are separated by single dots and without any intermediate 302 white space. 304 Although the number of sub-identifiers is not limited, 305 module designers should realize that there may be 306 implementations that stick with the SMIv2 limit of 128 307 sub-identifiers. 309 This type is a superset of the SMIv2 OBJECT IDENTIFIER type 310 since it is not restricted to 128 sub-identifiers."; 311 reference 312 "ISO/IEC 9834-1: Information technology -- Open Systems 313 Interconnection -- Procedures for the operation of OSI 314 Registration Authorities: General procedures and top 315 arcs of the ASN.1 Object Identifier tree"; 316 } 318 typedef object-identifier-128 { 319 type object-identifier { 320 pattern '\d*(.\d){1,127}'; 321 } 322 description 323 "This type represents object-identifiers restricted to 128 324 sub-identifiers. 326 This type is in the value set and its semantics equivalent to 327 the OBJECT IDENTIFIER type of the SMIv2."; 328 reference 329 "RFC 2578: Structure of Management Information Version 2 (SMIv2)"; 331 } 333 /*** collection of date and time related types ***/ 335 typedef date-and-time { 336 type string { 337 pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?' 338 + '(Z|(\+|-)\d{2}:\d{2})'; 339 } 340 description 341 'The date-and-time type is a profile of the ISO 8601 342 standard for representation of dates and times using the 343 Gregorian calendar. The format is most easily described 344 using the following ABFN (see RFC 3339): 346 date-fullyear = 4DIGIT 347 date-month = 2DIGIT ; 01-12 348 date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 349 time-hour = 2DIGIT ; 00-23 350 time-minute = 2DIGIT ; 00-59 351 time-second = 2DIGIT ; 00-58, 00-59, 00-60 352 time-secfrac = "." 1*DIGIT 353 time-numoffset = ("+" / "-") time-hour ":" time-minute 354 time-offset = "Z" / time-numoffset 356 partial-time = time-hour ":" time-minute ":" time-second 357 [time-secfrac] 358 full-date = date-fullyear "-" date-month "-" date-mday 359 full-time = partial-time time-offset 361 date-time = full-date "T" full-time 363 The date-and-time type is compatible with the dateTime XML 364 schema type except that dateTime allows negative years 365 which are not allowed by RFC 3339. 367 This type is not equivalent to the DateAndTime textual 368 convention of the SMIv2 since RFC 3339 uses a different 369 separator between full-date and full-time and provides 370 higher resolution of time-secfrac.'; 371 reference 372 "RFC 3339: Date and Time on the Internet: Timestamps 373 RFC 2579: Textual Conventions for SMIv2"; 374 } 376 typedef timeticks { 377 type uint32; 378 description 379 "The timeticks type represents a non-negative integer which 380 represents the time, modulo 2^32 (4294967296 decimal), in 381 hundredths of a second between two epochs. When objects 382 are defined which use this type, the description of the 383 object identifies both of the reference epochs. 385 This type is in the value set and its semantics equivalent to 386 the TimeStamp textual convention of the SMIv2."; 387 reference 388 "RFC 2579: Textual Conventions for SMIv2"; 389 } 391 typedef timestamp { 392 type yang:timeticks; 393 description 394 "The timestamp type represents the value of an associated 395 timeticks object at which a specific occurrence happened. 396 The specific occurrence must be defined in the description 397 of any object defined using this type. When the specific 398 occurrence occurred prior to the last time the associated 399 timeticks attribute was zero, then the timestamp value is 400 zero. Note that this requires all timestamp values to be 401 reset to zero when the value of the associated timeticks 402 attribute reaches 497+ days and wraps around to zero. 404 The associated timeticks object must be specified 405 in the description of any object using this type. 407 This type is in the value set and its semantics equivalent to 408 the TimeStamp textual convention of the SMIv2."; 409 reference 410 "RFC 2579: Textual Conventions for SMIv2"; 411 } 413 /*** collection of generic address types ***/ 415 typedef phys-address { 416 type string { 417 pattern '([0-9a0-fA-F]{2}(:[0-9a0-fA-F]{2})*)?'; 418 } 419 description 420 "Represents media- or physical-level addresses represented 421 as a sequence octets, each octet represented by two hexadecimal 422 numbers. Octets are separated by colons. 424 This type is in the value set and its semantics equivalent to 425 the PhysAddress textual convention of the SMIv2."; 426 reference 427 "RFC 2579: Textual Conventions for SMIv2"; 428 } 430 } 432 3. Internet Specific Derived Types 434 module inet-types { 436 namespace "urn:ietf:params:xml:ns:yang:inet-types"; 437 prefix "inet"; 439 organization 440 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 442 contact 443 "WG Web: 444 WG List: 446 WG Chair: David Partain 447 449 WG Chair: David Harrington 450 452 Editor: Juergen Schoenwaelder 453 "; 455 description 456 "This module contains a collection of generally useful derived 457 YANG data types for Internet addresses and related things. 459 Copyright (C) The IETF Trust (2008). This version of this 460 YANG module is part of RFC XXXX; see the RFC itself for full 461 legal notices."; 462 // RFC Ed.: replace XXXX with actual RFC number and remove this note 464 revision 2008-08-26 { 465 description 466 "Initial revision, published as RFC XXXX."; 467 } 468 // RFC Ed.: replace XXXX with actual RFC number and remove this note 470 /*** collection of protocol field related types ***/ 472 typedef ip-version { 473 type enumeration { 474 enum unknown { 475 value "0"; 476 description 477 "An unknown or unspecified version of the Internet protocol."; 478 } 479 enum ipv4 { 480 value "1"; 481 description 482 "The IPv4 protocol as defined in RFC 791."; 483 } 484 enum ipv6 { 485 value "2"; 486 description 487 "The IPv6 protocol as defined in RFC 2460."; 488 } 489 } 490 description 491 "This value represents the version of the IP protocol. 493 This type is in the value set and its semantics equivalent 494 to the InetVersion textual convention of the SMIv2. However, 495 the lexical appearance is different from the InetVersion 496 textual convention."; 497 reference 498 "RFC 791: Internet Protocol 499 RFC 2460: Internet Protocol, Version 6 (IPv6) Specification 500 RFC 4001: Textual Conventions for Internet Network Addresses"; 501 } 503 typedef dscp { 504 type uint8 { 505 range "0..63"; 506 } 507 description 508 "The dscp type represents a Differentiated Services Code-Point 509 that may be used for marking a traffic stream. 511 This type is in the value set and its semantics equivalent 512 to the Dscp textual convention of the SMIv2."; 513 reference 514 "RFC 3289: Management Information Base for the Differentiated 515 Services Architecture 516 RFC 2474: Definition of the Differentiated Services Field 517 (DS Field) in the IPv4 and IPv6 Headers 518 RFC 2780: IANA Allocation Guidelines For Values In 519 the Internet Protocol and Related Headers"; 520 } 522 typedef flow-label { 523 type uint32 { 524 range "0..1048575"; 525 } 526 description 527 "The flow-label type represents flow identifier or Flow Label 528 in an IPv6 packet header that may be used to discriminate 529 traffic flows. 531 This type is in the value set and its semantics equivalent 532 to the IPv6FlowLabel textual convention of the SMIv2."; 533 reference 534 "RFC 3595: Textual Conventions for IPv6 Flow Label 535 RFC 2460: Internet Protocol, Version 6 (IPv6) Specification"; 536 } 538 typedef port-number { 539 type uint16 { 540 range "1..65535"; 541 } 542 description 543 "The port-number type represents a 16-bit port number of an 544 Internet transport layer protocol such as UDP, TCP, DCCP or 545 SCTP. Port numbers are assigned by IANA. A current list of 546 all assignments is available from . 548 Note that the value zero is not a valid port number. A union 549 type might be used in situations where the value zero is 550 meaningful. 552 This type is in the value set and its semantics equivalent 553 to the InetPortNumber textual convention of the SMIv2."; 554 reference 555 "RFC 768: User Datagram Protocol 556 RFC 793: Transmission Control Protocol 557 RFC 2960: Stream Control Transmission Protocol 558 RFC 4340: Datagram Congestion Control Protocol (DCCP) 559 RFC 4001: Textual Conventions for Internet Network Addresses"; 560 } 562 /*** collection of autonomous system related types ***/ 564 typedef autonomous-system-number { 565 type uint32; 566 description 567 "The as-number type represents autonomous system numbers 568 which identify an Autonomous System (AS). An AS is a set 569 of routers under a single technical administration, using 570 an interior gateway protocol and common metrics to route 571 packets within the AS, and using an exterior gateway 572 protocol to route packets to other ASs'. IANA maintains 573 ; the AS number space and has delegated large parts to the 574 regional registries. 576 Autonomous system numbers are currently limited to 16 bits 577 (0..65535). There is however work in progress to enlarge 578 the autonomous system number space to 32 bits. This 579 textual convention therefore uses an uint32 base type 580 without a range restriction in order to support a larger 581 autonomous system number space. 583 This type is in the value set and its semantics equivalent 584 to the InetAutonomousSystemNumber textual convention of 585 the SMIv2."; 586 reference 587 "RFC 1930: Guidelines for creation, selection, and registration 588 of an Autonomous System (AS) 589 RFC 4271: A Border Gateway Protocol 4 (BGP-4) 590 RFC 4001: Textual Conventions for Internet Network Addresses"; 591 } 593 /*** collection of IP address and hostname related types ***/ 595 typedef ip-address { 596 type union { 597 type inet:ipv4-address; 598 type inet:ipv6-address; 599 } 600 description 601 "The ip-address type represents an IP address and is IP 602 version neutral. The format of the textual representations 603 implies the IP version."; 604 } 606 typedef ipv4-address { 607 type string { 608 pattern '((0' 609 + '|(1[0-9]{0,2})' 610 + '|(2(([0-4][0-9]?)|(5[0-5]?)|([6-9]?)))' 611 + '|([3-9][0-9]?)' 612 + ')' 613 + '\.){3}' 614 + '(0' 615 + '|(1[0-9]{0,2})' 616 + '|(2(([0-4][0-9]?)|(5[0-5]?)|([6-9]?)))' 617 + '|([3-9][0-9]?)' 618 + ')(%[\p{N}\p{L}]+)?'; 619 } 620 description 621 "The ipv4-address type represents an IPv4 address in 622 dotted-quad notation. The IPv4 address may include a zone 623 index, separated by a % sign. 625 The zone index is used to disambiguate identical address 626 values. For link-local addresses, the zone index will 627 typically be the interface index number or the name of an 628 interface. If the zone index is not present, the default 629 zone of the device will be used."; 630 } 632 typedef ipv6-address { 633 type string { 634 pattern 635 /* full */ 636 '((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})' 637 + '(%[\p{N}\p{L}]+)?)' 638 /* mixed */ 639 + '|((([0-9a-fA-F]{1,4}:){6})(([0-9]{1,3}\.' 640 + '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))' 641 + '(%[\p{N}\p{L}]+)?)' 642 /* shortened */ 643 + '|((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)' 644 + '(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*' 645 + '(%[\p{N}\p{L}]+)?)' 646 /* shortened mixed */ 647 + '|((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)' 648 + '(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*' 649 + '(([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))' 650 + '(%[\p{N}\p{L}]+)?)'; 651 } 652 description 653 "The ipv6-address type represents an IPv6 address in full, 654 mixed, shortened and shortened mixed notation. The IPv6 655 address may include a zone index, separated by a % sign. 657 The zone index is used to disambiguate identical address 658 values. For link-local addresses, the zone index will 659 typically be the interface index number or the name of an 660 interface. If the zone index is not present, the default 661 zone of the device will be used."; 662 reference 663 "RFC 4007: IPv6 Scoped Address Architecture"; 664 } 666 // [TODO: The pattern needs to be checked; once YANG supports 667 // multiple pattern, we can perhaps be more precise.] 669 typedef ip-prefix { 670 type union { 671 type inet:ipv4-prefix; 672 type inet:ipv6-prefix; 674 } 675 description 676 "The ip-prefix type represents an IP prefix and is IP 677 version neutral. The format of the textual representations 678 implies the IP version."; 679 } 681 typedef ipv4-prefix { 682 type string { 683 pattern '(([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])\.){3}' 684 + '([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])' 685 + '/\d+'; 686 } 687 description 688 "The ipv4-prefix type represents an IPv4 address prefix. 689 The prefix length is given by the number following the 690 slash character and must be less than or equal to 32. 692 A prefix length value of n corresponds to an IP address 693 mask which has n contiguous 1-bits from the most 694 significant bit (MSB) and all other bits set to 0. 696 The IPv4 address represented in dotted quad notation 697 should have all bits that do not belong to the prefix 698 set to zero."; 699 } 701 typedef ipv6-prefix { 702 type string { 703 pattern 704 /* full */ 705 '((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})' 706 + '/\d+)' 707 /* mixed */ 708 + '|((([0-9a-fA-F]{1,4}:){6})(([0-9]{1,3}\.' 709 + '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))' 710 + '/\d+)' 711 /* shortened */ 712 + '|((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)' 713 + '(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*' 714 + '/\d+)' 715 /* shortened mixed */ 716 + '|((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)' 717 + '(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*' 718 + '(([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))' 719 + '/\d+)'; 720 } 721 description 722 "The ipv6-prefix type represents an IPv6 address prefix. 723 The prefix length is given by the number following the 724 slash character and must be less than or equal 128. 726 A prefix length value of n corresponds to an IP address 727 mask which has n contiguous 1-bits from the most 728 significant bit (MSB) and all other bits set to 0. 730 The IPv6 address should have all bits that do not belong 731 to the prefix set to zero."; 732 } 734 // [TODO: The pattern needs to be checked; once YANG supports 735 // multiple pattern, we can perhaps be more precise.] 737 /*** collection of domain name and URI types ***/ 739 typedef domain-name { 740 type string { 741 pattern '([a-zA-Z0-9][a-zA-Z0-9\-]*[a-zA-Z0-9]\.)*' 742 + '[a-zA-Z0-9][a-zA-Z0-9\-]*[a-zA-Z0-9]'; 743 } 744 description 745 "The domain-name type represents a DNS domain name. The 746 name SHOULD be fully qualified whenever possible. 748 The description clause of objects using the domain-name 749 type MUST describe how (and when) these names are 750 resolved to IP addresses. 752 Note that the resolution of a domain-name value may 753 require to query multiple DNS records (e.g., A for IPv4 754 and AAAA for IPv6). The order of the resolution process 755 and which DNS record takes precedence depends on the 756 configuration of the resolver."; 757 reference 758 "RFC 1034: Domain Names - Concepts and Facilities 759 RFC 1123: Requirements for Internet Hosts -- Application 760 and Support"; 761 } 763 // [TODO: RFC 2181 says there are no restrictions on DNS 764 // labels. Need to check whether the pattern is too 765 // restrictive.] 767 typedef host { 768 type union { 769 type inet:ip-address; 770 type inet:domain-name; 771 } 772 description 773 "The host type represents either an IP address or a DNS 774 domain name."; 775 } 777 typedef uri { 778 type string; // [TODO: add the regex from RFC 3986 here?] 779 description 780 "The uri type represents a Uniform Resource Identifier 781 (URI) as defined by STD 66. 783 Objects using the uri type must be in US-ASCII encoding, 784 and MUST be normalized as described by RFC 3986 Sections 785 6.2.1, 6.2.2.1, and 6.2.2.2. All unnecessary 786 percent-encoding is removed, and all case-insensitive 787 characters are set to lowercase except for hexadecimal 788 digits, which are normalized to uppercase as described in 789 Section 6.2.2.1. 791 The purpose of this normalization is to help provide 792 unique URIs. Note that this normalization is not 793 sufficient to provide uniqueness. Two URIs that are 794 textually distinct after this normalization may still be 795 equivalent. 797 Objects using the uri type may restrict the schemes that 798 they permit. For example, 'data:' and 'urn:' schemes 799 might not be appropriate. 801 A zero-length URI is not a valid URI. This can be used to 802 express 'URI absent' where required 804 This type is in the value set and its semantics equivalent 805 to the Uri textual convention of the SMIv2."; 806 reference 807 "RFC 3986: Uniform Resource Identifier (URI): Generic Syntax 808 RFC 3305: Report from the Joint W3C/IETF URI Planning Interest 809 Group: Uniform Resource Identifiers (URIs), URLs, 810 and Uniform Resource Names (URNs): Clarifications 811 and Recommendations 812 RFC 5017: MIB Textual Conventions for Uniform Resource 813 Identifiers (URIs)"; 814 } 816 } 818 4. IEEE Specific Derived Types 820 module ieee-types { 822 namespace "urn:ietf:params:xml:ns:yang:ieee-types"; 823 prefix "ieee"; 825 import yang-types { prefix yang; } 827 organization 828 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 830 contact 831 "WG Web: 832 WG List: 834 WG Chair: David Partain 835 837 WG Chair: David Harrington 838 840 Editor: Juergen Schoenwaelder 841 "; 843 description 844 "This module contains a collection of generally useful derived 845 YANG data types for IEEE 802 addresses and related things. 847 Copyright (C) The IETF Trust (2008). This version of this 848 YANG module is part of RFC XXXX; see the RFC itself for full 849 legal notices."; 850 // RFC Ed.: replace XXXX with actual RFC number and remove this note 852 revision 2008-08-22 { 853 description 854 "Initial revision, published as RFC XXXX"; 855 } 856 // RFC Ed.: replace XXXX with actual RFC number and remove this note 858 /*** collection of IEEE address type definitions ***/ 860 typedef mac-address { 861 type string { 862 pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}'; 863 } 864 description 865 "The mac-address type represents an 802 MAC address represented 866 in the `canonical' order defined by IEEE 802.1a, i.e., as if it 867 were transmitted least significant bit first, even though 802.5 868 (in contrast to other 802.x protocols) requires MAC addresses 869 to be transmitted most significant bit first. 871 This type is in the value set and its semantics equivalent to 872 the MacAddress textual convention of the SMIv2."; 873 reference 874 "RFC 2579: Textual Conventions for SMIv2"; 875 } 877 /*** collection of IEEE 802 related identifier types ***/ 879 typedef bridgeid { 880 type string { 881 pattern '[0-9a-fA-F]{4}(:[0-9a-fA-F]{2}){6}'; 882 } 883 description 884 "The bridgeid type represents identifiers that uniquely 885 identify a bridge. Its first four hexadecimal digits 886 contain a priority value followed by a colon. The 887 remaining characters contain the MAC address used to 888 refer to a bridge in a unique fashion (typically, the 889 numerically smallest MAC address of all ports on the 890 bridge). 892 This type is in the value set and its semantics equivalent 893 to the BridgeId textual convention of the SMIv2. However, 894 since the BridgeId textual convention does not prescribe 895 a lexical representation, the appearance might be different."; 896 reference 897 "RFC 4188: Definitions of Managed Objects for Bridges"; 898 } 900 typedef vlanid { 901 type uint16 { 902 range "1..4094"; 903 } 904 description 905 "The vlanid type uniquely identifies a VLAN. This is the 906 12-bit VLAN-ID used in the VLAN Tag header. The range is 907 defined by the referenced specification. 909 This type is in the value set and its semantics equivalent to 910 the VlanId textual convention of the SMIv2."; 911 reference 912 "IEEE Std 802.1Q 2003 Edition: Virtual Bridged Local 913 Area Networks 915 RFC 4363: Definitions of Managed Objects for Bridges with 916 Traffic Classes, Multicast Filtering, and Virtual 917 LAN Extensions"; 918 } 920 } 922 5. IANA Considerations 924 A registry for standard YANG modules shall be set up. The name of 925 the registry is "IETF YANG Modules" and the registry shall record for 926 each entry the unique name of a YANG module, the assigned XML 927 namespace from the YANG URI Scheme, and a reference to the module's 928 documentation (typically and RFC). Allocations require IETF Review 929 as defined in [RFC5226]. The initial assignements are: 931 YANG Module XML namespace Reference 932 ----------- -------------------------------------- --------- 933 yang-types urn:ietf:params:xml:ns:yang:yang-types RFC XXXX 934 inet-types urn:ietf:params:xml:ns:yang:inet-types RFC XXXX 935 ieee-types urn:ietf:params:xml:ns:yang:ieee-types RFC XXXX 937 RFC Ed.: replace XXXX with actual RFC number and remove this note 939 This document registers three URIs1 in the IETF XML registry 940 [RFC3688]. Following the format in RFC 3688, the following 941 registration is requested. 943 URI: urn:ietf:params:xml:ns:yang:yang-types 944 URI: urn:ietf:params:xml:ns:yang:inet-types 945 URI: urn:ietf:params:xml:ns:yang:ieee-types 947 Registrant Contact: The NETMOD WG of the IETF. 949 XML: N/A, the requested URI is an XML namespace. 951 6. Security Considerations 953 This document defines common data types using the YANG data modeling 954 language. The definitions themselves have no security impact on the 955 Internet but the usage of these definitions in concrete YANG modules 956 might have. The security considerations spelled out in the YANG 957 specification [YANG] apply for this document as well. 959 7. Contributors 961 The following people all contributed significantly to the initial 962 version of this draft: 964 - Andy Bierman (andybierman.com) 965 - Martin Bjorklund (Tail-f Systems) 966 - Balazs Lengyel (Ericsson) 967 - David Partain (Ericsson) 968 - Phil Shafer (Juniper Networks) 970 8. References 972 8.1. Normative References 974 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 975 Requirement Levels", BCP 14, RFC 2119, March 1997. 977 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 978 January 2004. 980 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 981 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 982 May 2008. 984 [YANG] Bjorklund, M., Ed., "YANG - A data modeling language for 985 NETCONF", draft-ietf-netmod-yang-01 (work in progress). 987 8.2. Informative References 989 [802.1Q] ANSI/IEEE Standard 802.1Q, "IEEE Standards for Local and 990 Metropolitan Area Networks: Virtual Bridged Local Area 991 Networks", 2003. 993 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 994 August 1980. 996 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 997 September 1981. 999 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1000 RFC 793, September 1981. 1002 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1003 STD 13, RFC 1034, November 1987. 1005 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 1006 and Support", STD 3, RFC 1123, October 1989. 1008 [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, 1009 selection, and registration of an Autonomous System (AS)", 1010 BCP 6, RFC 1930, March 1996. 1012 [RFC2021] Waldbusser, S., "Remote Network Monitoring Management 1013 Information Base Version 2 using SMIv2", RFC 2021, 1014 January 1997. 1016 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1017 (IPv6) Specification", RFC 2460, December 1998. 1019 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1020 "Definition of the Differentiated Services Field (DS 1021 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1022 December 1998. 1024 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1025 Schoenwaelder, Ed., "Structure of Management Information 1026 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 1028 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1029 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 1030 STD 58, RFC 2579, April 1999. 1032 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 1033 Values In the Internet Protocol and Related Headers", 1034 BCP 37, RFC 2780, March 2000. 1036 [RFC2856] Bierman, A., McCloghrie, K., and R. Presuhn, "Textual 1037 Conventions for Additional High Capacity Data Types", 1038 RFC 2856, June 2000. 1040 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 1041 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 1042 Zhang, L., and V. Paxson, "Stream Control Transmission 1043 Protocol", RFC 2960, October 2000. 1045 [RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information 1046 Base for the Differentiated Services Architecture", 1047 RFC 3289, May 2002. 1049 [RFC3305] Mealling, M. and R. Denenberg, "Report from the Joint W3C/ 1050 IETF URI Planning Interest Group: Uniform Resource 1051 Identifiers (URIs), URLs, and Uniform Resource Names 1052 (URNs): Clarifications and Recommendations", RFC 3305, 1053 August 2002. 1055 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 1056 Internet: Timestamps", RFC 3339, July 2002. 1058 [RFC3595] Wijnen, B., "Textual Conventions for IPv6 Flow Label", 1059 RFC 3595, September 2003. 1061 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1062 Resource Identifier (URI): Generic Syntax", STD 66, 1063 RFC 3986, January 2005. 1065 [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. 1066 Schoenwaelder, "Textual Conventions for Internet Network 1067 Addresses", RFC 4001, February 2005. 1069 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 1070 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 1071 March 2005. 1073 [RFC4188] Norseth, K. and E. Bell, "Definitions of Managed Objects 1074 for Bridges", RFC 4188, September 2005. 1076 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1077 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1079 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1080 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 1082 [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, 1083 December 2006. 1085 [RFC5017] McWalter, D., "MIB Textual Conventions for Uniform 1086 Resource Identifiers (URIs)", RFC 5017, September 2007. 1088 Appendix A. XSD Translations 1090 This appendix provides XML Schema (XSD) translations of the types 1091 defined in this document. This appendix is informative and not 1092 normative. 1094 A.1. XSD of Core YANG Derived Types 1096 1097 1106 1107 1108 This schema was generated from the YANG module yang-types 1109 by pyang version 0.9.1. 1111 The schema describes an instance document consisting of 1112 the entire configuration data store and operational 1113 data. This schema can thus NOT be used as-is to 1114 validate NETCONF PDUs. 1115 1116 1118 1119 1120 This module contains a collection of generally useful derived 1121 YANG data types. 1123 Copyright (C) The IETF Trust (2008). This version of this 1124 YANG module is part of RFC XXXX; see the RFC itself for full 1125 legal notices. 1126 1127 1128 1130 1131 1132 1133 The counter32 type represents a non-negative integer 1134 which monotonically increases until it reaches a 1135 maximum value of 2^32-1 (4294967295 decimal), when it 1136 wraps around and starts increasing again from zero. 1138 Counters have no defined `initial' value, and thus, a 1139 single value of a counter has (in general) no information 1140 content. Discontinuities in the monotonically increasing 1141 value normally occur at re-initialization of the 1142 management system, and at other times as specified in the 1143 description of an object instance using this type. If 1144 such other times can occur, for example, the creation of 1145 an object instance of type counter32 at times other than 1146 re-initialization, then a corresponding object should be 1147 defined, with an appropriate type, to indicate the last 1148 discontinuity. 1150 The counter32 type should not be used for configuration 1151 objects. A default statement should not be used for 1152 attributes with a type value of counter32. 1154 This type is in the value set and its semantics equivalent 1155 to the Counter32 type of the SMIv2. 1156 1157 1159 1160 1161 1163 1164 1165 1166 The zero-based-counter32 type represents a counter32 1167 which has the defined `initial' value zero. 1169 Objects of this type will be set to zero(0) on creation 1170 and will thereafter count appropriate events, wrapping 1171 back to zero(0) when the value 2^32 is reached. 1173 Provided that an application discovers the new object within 1174 the minimum time to wrap it can use the initial value as a 1175 delta since it last polled the table of which this object is 1176 part. It is important for a management station to be aware 1177 of this minimum time and the actual time between polls, and 1178 to discard data if the actual time is too long or there is 1179 no defined minimum time. 1181 This type is in the value set and its semantics equivalent 1182 to the ZeroBasedCounter32 textual convention of the SMIv2. 1183 1185 1187 1188 1189 1191 1192 1193 1194 The counter64 type represents a non-negative integer 1195 which monotonically increases until it reaches a 1196 maximum value of 2^64-1 (18446744073709551615), when 1197 it wraps around and starts increasing again from zero. 1199 Counters have no defined `initial' value, and thus, a 1200 single value of a counter has (in general) no information 1201 content. Discontinuities in the monotonically increasing 1202 value normally occur at re-initialization of the 1203 management system, and at other times as specified in the 1204 description of an object instance using this type. If 1205 such other times can occur, for example, the creation of 1206 an object instance of type counter64 at times other than 1207 re-initialization, then a corresponding object should be 1208 defined, with an appropriate type, to indicate the last 1209 discontinuity. 1211 The counter64 type should not be used for configuration 1212 objects. A default statement should not be used for 1213 attributes with a type value of counter64. 1215 This type is in the value set and its semantics equivalent 1216 to the Counter64 type of the SMIv2. 1217 1218 1220 1221 1222 1224 1225 1226 1227 The zero-based-counter64 type represents a counter64 which 1228 has the defined `initial' value zero. 1230 Objects of this type will be set to zero(0) on creation 1231 and will thereafter count appropriate events, wrapping 1232 back to zero(0) when the value 2^64 is reached. 1234 Provided that an application discovers the new object within 1235 the minimum time to wrap it can use the initial value as a 1236 delta since it last polled the table of which this object is 1237 part. It is important for a management station to be aware 1238 of this minimum time and the actual time between polls, and 1239 to discard data if the actual time is too long or there is 1240 no defined minimum time. 1242 This type is in the value set and its semantics equivalent 1243 to the ZeroBasedCounter64 textual convention of the SMIv2. 1244 1245 1247 1248 1249 1251 1252 1253 1254 The gauge32 type represents a non-negative integer, which 1255 may increase or decrease, but shall never exceed a maximum 1256 value, nor fall below a minimum value. The maximum value 1257 can not be greater than 2^32-1 (4294967295 decimal), and 1258 the minimum value can not be smaller than 0. The value of 1259 a gauge32 has its maximum value whenever the information 1260 being modeled is greater than or equal to its maximum 1261 value, and has its minimum value whenever the information 1262 being modeled is smaller than or equal to its minimum value. 1263 If the information being modeled subsequently decreases 1264 below (increases above) the maximum (minimum) value, the 1265 gauge32 also decreases (increases). 1267 This type is in the value set and its semantics equivalent 1268 to the Counter32 type of the SMIv2. 1269 1270 1272 1273 1274 1276 1277 1278 1279 The gauge64 type represents a non-negative integer, which 1280 may increase or decrease, but shall never exceed a maximum 1281 value, nor fall below a minimum value. The maximum value 1282 can not be greater than 2^64-1 (18446744073709551615), and 1283 the minimum value can not be smaller than 0. The value of 1284 a gauge64 has its maximum value whenever the information 1285 being modeled is greater than or equal to its maximum 1286 value, and has its minimum value whenever the information 1287 being modeled is smaller than or equal to its minimum value. 1288 If the information being modeled subsequently decreases 1289 below (increases above) the maximum (minimum) value, the 1290 gauge64 also decreases (increases). 1292 This type is in the value set and its semantics equivalent 1293 to the CounterBasedGauge64 SMIv2 textual convention defined 1294 in RFC 2856 1295 1296 1298 1299 1300 1302 1303 1304 1305 The object-identifier type represents administratively 1306 assigned names in a registration-hierarchical-name tree. 1308 Values of this type are denoted as a sequence of numerical 1309 non-negative sub-identifier values. Each sub-identifier 1310 value MUST NOT exceed 2^32-1 (4294967295). Sub-identifiers 1311 are separated by single dots and without any intermediate 1312 white space. 1314 Although the number of sub-identifiers is not limited, 1315 module designers should realize that there may be 1316 implementations that stick with the SMIv2 limit of 128 1317 sub-identifiers. 1319 This type is a superset of the SMIv2 OBJECT IDENTIFIER type 1320 since it is not restricted to 128 sub-identifiers. 1321 1322 1324 1325 1327 1328 1329 1330 1331 1332 This type represents object-identifiers restricted to 128 1333 sub-identifiers. 1335 This type is in the value set and its semantics equivalent to 1336 the OBJECT IDENTIFIER type of the SMIv2. 1337 1338 1340 1341 1342 1343 1345 1346 1347 1348 The date-and-time type is a profile of the ISO 8601 1349 standard for representation of dates and times using the 1350 Gregorian calendar. The format is most easily described 1351 using the following ABFN (see RFC 3339): 1353 date-fullyear = 4DIGIT 1354 date-month = 2DIGIT ; 01-12 1355 date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 1356 time-hour = 2DIGIT ; 00-23 1357 time-minute = 2DIGIT ; 00-59 1358 time-second = 2DIGIT ; 00-58, 00-59, 00-60 1359 time-secfrac = "." 1*DIGIT 1360 time-numoffset = ("+" / "-") time-hour ":" time-minute 1361 time-offset = "Z" / time-numoffset 1363 partial-time = time-hour ":" time-minute ":" time-second 1364 [time-secfrac] 1365 full-date = date-fullyear "-" date-month "-" date-mday 1366 full-time = partial-time time-offset 1368 date-time = full-date "T" full-time 1370 The date-and-time type is compatible with the dateTime XML 1371 schema type except that dateTime allows negative years 1372 which are not allowed by RFC 3339. 1374 This type is not equivalent to the DateAndTime textual 1375 convention of the SMIv2 since RFC 3339 uses a different 1376 separator between full-date and full-time and provides 1377 higher resolution of time-secfrac. 1378 1379 1381 1382 1384 1385 1387 1388 1389 1390 The timeticks type represents a non-negative integer which 1391 represents the time, modulo 2^32 (4294967296 decimal), in 1392 hundredths of a second between two epochs. When objects 1393 are defined which use this type, the description of the 1394 object identifies both of the reference epochs. 1396 This type is in the value set and its semantics equivalent to 1397 the TimeStamp textual convention of the SMIv2. 1398 1399 1401 1402 1403 1405 1406 1407 1408 The timestamp type represents the value of an associated 1409 timeticks object at which a specific occurrence happened. 1410 The specific occurrence must be defined in the description 1411 of any object defined using this type. When the specific 1412 occurrence occurred prior to the last time the associated 1413 timeticks attribute was zero, then the timestamp value is 1414 zero. Note that this requires all timestamp values to be 1415 reset to zero when the value of the associated timeticks 1416 attribute reaches 497+ days and wraps around to zero. 1418 The associated timeticks object must be specified 1419 in the description of any object using this type. 1421 This type is in the value set and its semantics equivalent to 1422 the TimeStamp textual convention of the SMIv2. 1423 1424 1425 1426 1427 1429 1430 1431 1432 Represents media- or physical-level addresses represented 1433 as a sequence octets, each octet represented by two hexadecimal 1434 numbers. Octets are separated by colons. 1436 This type is in the value set and its semantics equivalent to 1437 the PhysAddress textual convention of the SMIv2. 1438 1439 1441 1442 1443 1444 1446 1448 A.2. XSD of Internet Specific Derived Types 1450 1451 1460 1461 1462 This schema was generated from the YANG module inet-types 1463 by pyang version 0.9.1. 1465 The schema describes an instance document consisting of 1466 the entire configuration data store and operational 1467 data. This schema can thus NOT be used as-is to 1468 validate NETCONF PDUs. 1469 1470 1471 1472 1473 This module contains a collection of generally useful derived 1474 YANG data types for Internet addresses and related things. 1476 Copyright (C) The IETF Trust (2008). This version of this 1477 YANG module is part of RFC XXXX; see the RFC itself for full 1478 legal notices. 1479 1480 1481 1483 1484 1485 1486 This value represents the version of the IP protocol. 1488 This type is in the value set and its semantics equivalent 1489 to the InetVersion textual convention of the SMIv2. However, 1490 the lexical appearance is different from the InetVersion 1491 textual convention. 1492 1493 1495 1496 1497 1498 1499 1500 1502 1503 1504 1505 The dscp type represents a Differentiated Services Code-Point 1506 that may be used for marking a traffic stream. 1508 This type is in the value set and its semantics equivalent 1509 to the Dscp textual convention of the SMIv2. 1510 1511 1513 1514 1515 1516 1517 1518 1519 1520 1521 The flow-label type represents flow identifier or Flow Label 1522 in an IPv6 packet header that may be used to discriminate 1523 traffic flows. 1525 This type is in the value set and its semantics equivalent 1526 to the IPv6FlowLabel textual convention of the SMIv2. 1527 1528 1530 1531 1532 1533 1534 1536 1537 1538 1539 The port-number type represents a 16-bit port number of an 1540 Internet transport layer protocol such as UDP, TCP, DCCP or 1541 SCTP. Port numbers are assigned by IANA. A current list of 1542 all assignments is available from <http://www.iana.org/>. 1544 Note that the value zero is not a valid port number. A union 1545 type might be used in situations where the value zero is 1546 meaningful. 1548 This type is in the value set and its semantics equivalent 1549 to the InetPortNumber textual convention of the SMIv2. 1550 1551 1553 1554 1555 1556 1557 1559 1560 1561 1562 The as-number type represents autonomous system numbers 1563 which identify an Autonomous System (AS). An AS is a set 1564 of routers under a single technical administration, using 1565 an interior gateway protocol and common metrics to route 1566 packets within the AS, and using an exterior gateway 1567 protocol to route packets to other ASs'. IANA maintains 1568 ; the AS number space and has delegated large parts to the 1569 regional registries. 1571 Autonomous system numbers are currently limited to 16 bits 1572 (0..65535). There is however work in progress to enlarge 1573 the autonomous system number space to 32 bits. This 1574 textual convention therefore uses an uint32 base type 1575 without a range restriction in order to support a larger 1576 autonomous system number space. 1578 This type is in the value set and its semantics equivalent 1579 to the InetAutonomousSystemNumber textual convention of 1580 the SMIv2. 1581 1582 1584 1585 1586 1588 1589 1590 1591 The ip-address type represents an IP address and is IP 1592 version neutral. The format of the textual representations 1593 implies the IP version. 1594 1595 1597 1598 1599 1600 1601 1602 1603 1604 1605 1606 1607 1609 1610 1611 1612 The ipv4-address type represents an IPv4 address in 1613 dotted-quad notation. The IPv4 address may include a zone 1614 index, separated by a % sign. 1616 The zone index is used to disambiguate identical address 1617 values. For link-local addresses, the zone index will 1618 typically be the interface index number or the name of an 1619 interface. If the zone index is not present, the default 1620 zone of the device will be used. 1621 1622 1624 1625 1629 1630 1632 1633 1634 1635 The ipv6-address type represents an IPv6 address in full, 1636 mixed, shortened and shortened mixed notation. The IPv6 1637 address may include a zone index, separated by a % sign. 1639 The zone index is used to disambiguate identical address 1640 values. For link-local addresses, the zone index will 1641 typically be the interface index number or the name of an 1642 interface. If the zone index is not present, the default 1643 zone of the device will be used. 1644 1645 1647 1648 1658 1659 1661 1662 1663 1664 The ip-prefix type represents an IP prefix and is IP 1665 version neutral. The format of the textual representations 1666 implies the IP version. 1667 1668 1670 1671 1672 1673 1674 1675 1676 1677 1678 1679 1680 1682 1683 1684 1685 The ipv4-prefix type represents an IPv4 address prefix. 1686 The prefix length is given by the number following the 1687 slash character and must be less than or equal to 32. 1689 A prefix length value of n corresponds to an IP address 1690 mask which has n contiguous 1-bits from the most 1691 significant bit (MSB) and all other bits set to 0. 1693 The IPv4 address represented in dotted quad notation 1694 should have all bits that do not belong to the prefix 1695 set to zero. 1696 1697 1699 1700 1702 1703 1705 1706 1707 1708 The ipv6-prefix type represents an IPv6 address prefix. 1709 The prefix length is given by the number following the 1710 slash character and must be less than or equal 128. 1712 A prefix length value of n corresponds to an IP address 1713 mask which has n contiguous 1-bits from the most 1714 significant bit (MSB) and all other bits set to 0. 1716 The IPv6 address should have all bits that do not belong 1717 to the prefix set to zero. 1718 1719 1721 1722 1730 1731 1733 1734 1735 1736 The domain-name type represents a DNS domain name. The 1737 name SHOULD be fully qualified whenever possible. 1739 The description clause of objects using the domain-name 1740 type MUST describe how (and when) these names are 1741 resolved to IP addresses. 1743 Note that the resolution of a domain-name value may 1744 require to query multiple DNS records (e.g., A for IPv4 1745 and AAAA for IPv6). The order of the resolution process 1746 and which DNS record takes precedence depends on the 1747 configuration of the resolver. 1748 1749 1751 1752 1754 1755 1757 1758 1759 1760 The host type represents either an IP address or a DNS 1761 domain name. 1762 1763 1765 1766 1767 1768 1769 1770 1771 1772 1773 1774 1775 1777 1778 1779 1780 The uri type represents a Uniform Resource Identifier 1781 (URI) as defined by STD 66. 1783 Objects using the uri type must be in US-ASCII encoding, 1784 and MUST be normalized as described by RFC 3986 Sections 1785 6.2.1, 6.2.2.1, and 6.2.2.2. All unnecessary 1786 percent-encoding is removed, and all case-insensitive 1787 characters are set to lowercase except for hexadecimal 1788 digits, which are normalized to uppercase as described in 1789 Section 6.2.2.1. 1791 The purpose of this normalization is to help provide 1792 unique URIs. Note that this normalization is not 1793 sufficient to provide uniqueness. Two URIs that are 1794 textually distinct after this normalization may still be 1795 equivalent. 1797 Objects using the uri type may restrict the schemes that 1798 they permit. For example, 'data:' and 'urn:' schemes 1799 might not be appropriate. 1801 A zero-length URI is not a valid URI. This can be used to 1802 express 'URI absent' where required 1804 This type is in the value set and its semantics equivalent 1805 to the Uri textual convention of the SMIv2. 1807 1808 1810 1811 1812 1814 1816 A.3. XSD of IEEE Specific Derived Types 1818 1819 1829 1832 1833 1834 This schema was generated from the YANG module ieee-types 1835 by pyang version 0.9.1. 1837 The schema describes an instance document consisting of 1838 the entire configuration data store and operational 1839 data. This schema can thus NOT be used as-is to 1840 validate NETCONF PDUs. 1841 1842 1844 1845 1846 This module contains a collection of generally useful derived 1847 YANG data types for IEEE 802 addresses and related things. 1849 Copyright (C) The IETF Trust (2008). This version of this 1850 YANG module is part of RFC XXXX; see the RFC itself for full 1851 legal notices. 1852 1853 1854 1856 1857 1858 1859 The mac-address type represents an 802 MAC address represented 1860 in the `canonical' order defined by IEEE 802.1a, i.e., as if it 1861 were transmitted least significant bit first, even though 802.5 1862 (in contrast to other 802.x protocols) requires MAC addresses 1863 to be transmitted most significant bit first. 1865 This type is in the value set and its semantics equivalent to 1866 the MacAddress textual convention of the SMIv2. 1867 1868 1870 1871 1872 1873 1875 1876 1877 1878 The bridgeid type represents identifiers that uniquely 1879 identify a bridge. Its first four hexadecimal digits 1880 contain a priority value followed by a colon. The 1881 remaining characters contain the MAC address used to 1882 refer to a bridge in a unique fashion (typically, the 1883 numerically smallest MAC address of all ports on the 1884 bridge). 1886 This type is in the value set and its semantics equivalent 1887 to the BridgeId textual convention of the SMIv2. However, 1888 since the BridgeId textual convention does not prescribe 1889 a lexical representation, the appearance might be different. 1890 1891 1893 1894 1895 1896 1898 1899 1900 1901 The vlanid type uniquely identifies a VLAN. This is the 1902 12-bit VLAN-ID used in the VLAN Tag header. The range is 1903 defined by the referenced specification. 1905 This type is in the value set and its semantics equivalent to 1906 the VlanId textual convention of the SMIv2. 1907 1908 1910 1911 1912 1913 1914 1916 1918 Appendix B. RelaxNG Translations 1920 This appendix provides RelaxNG translations of the types defined in 1921 this document. This appendix is informative and not normative. 1923 B.1. RelaxNG of Core YANG Derived Types 1925 namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" 1926 namespace dc = "http://purl.org/dc/terms" 1927 namespace dsrl = "http://purl.oclc.org/dsdl/dsrl" 1928 namespace nm = "urn:ietf:params:xml:ns:netmod:dsdl-attrib:1" 1929 namespace sch = "http://purl.oclc.org/dsdl/schematron" 1931 dc:creator [ 1932 "IETF NETMOD (NETCONF Data Modeling Language) Working Group" 1933 ] 1934 dc:description [ 1935 "This module contains a collection of generally useful derived\x{a}" ~ 1936 "YANG data types.\x{a}" ~ 1937 "\x{a}" ~ 1938 "Copyright (C) The IETF Trust (2008). This version of this\x{a}" ~ 1939 "YANG module is part of RFC XXXX; see the RFC itself for full\x{a}" ~ 1940 "legal notices." 1941 ] 1942 dc:issued [ "2008-08-26" ] 1943 dc:source [ "YANG module 'yang-types' (automatic translation)" ] 1944 dc:contributor [ 1945 "WG Web: \x{a}" ~ 1946 "WG List: \x{a}" ~ 1947 "\x{a}" ~ 1948 "WG Chair: David Partain\x{a}" ~ 1949 " \x{a}" ~ 1950 "\x{a}" ~ 1951 "WG Chair: David Harrington\x{a}" ~ 1952 " \x{a}" ~ 1953 "\x{a}" ~ 1954 "Editor: Juergen Schoenwaelder\x{a}" ~ 1955 " " 1956 ] 1958 ## The counter32 type represents a non-negative integer 1959 ## which monotonically increases until it reaches a 1960 ## maximum value of 2^32-1 (4294967295 decimal), when it 1961 ## wraps around and starts increasing again from zero. 1962 ## 1963 ## Counters have no defined `initial' value, and thus, a 1964 ## single value of a counter has (in general) no information 1965 ## content. Discontinuities in the monotonically increasing 1966 ## value normally occur at re-initialization of the 1967 ## management system, and at other times as specified in the 1968 ## description of an object instance using this type. If 1969 ## such other times can occur, for example, the creation of 1970 ## an object instance of type counter32 at times other than 1971 ## re-initialization, then a corresponding object should be 1972 ## defined, with an appropriate type, to indicate the last 1973 ## discontinuity. 1974 ## 1975 ## The counter32 type should not be used for configuration 1976 ## objects. A default statement should not be used for 1977 ## attributes with a type value of counter32. 1978 ## 1979 ## This type is in the value set and its semantics equivalent 1980 ## to the Counter32 type of the SMIv2. 1982 ## See: RFC 2578: Structure of Management Information Version 2 (SMIv2) 1983 __counter32 = xsd:unsignedInt 1985 ## The zero-based-counter32 type represents a counter32 1986 ## which has the defined `initial' value zero. 1987 ## 1988 ## Objects of this type will be set to zero(0) on creation 1989 ## and will thereafter count appropriate events, wrapping 1990 ## back to zero(0) when the value 2^32 is reached. 1991 ## 1992 ## Provided that an application discovers the new object within 1993 ## the minimum time to wrap it can use the initial value as a 1994 ## delta since it last polled the table of which this object is 1995 ## part. It is important for a management station to be aware 1996 ## of this minimum time and the actual time between polls, and 1997 ## to discard data if the actual time is too long or there is 1998 ## no defined minimum time. 1999 ## 2000 ## This type is in the value set and its semantics equivalent 2001 ## to the ZeroBasedCounter32 textual convention of the SMIv2. 2003 ## See: RFC 2021: Remote Network Monitoring Management Information 2004 ## Base Version 2 using SMIv2 2005 __zero-based-counter32 = __counter32 >> dsrl:default-content [ "0" ] 2007 ## The counter64 type represents a non-negative integer 2008 ## which monotonically increases until it reaches a 2009 ## maximum value of 2^64-1 (18446744073709551615), when 2010 ## it wraps around and starts increasing again from zero. 2011 ## 2012 ## Counters have no defined `initial' value, and thus, a 2013 ## single value of a counter has (in general) no information 2014 ## content. Discontinuities in the monotonically increasing 2015 ## value normally occur at re-initialization of the 2016 ## management system, and at other times as specified in the 2017 ## description of an object instance using this type. If 2018 ## such other times can occur, for example, the creation of 2019 ## an object instance of type counter64 at times other than 2020 ## re-initialization, then a corresponding object should be 2021 ## defined, with an appropriate type, to indicate the last 2022 ## discontinuity. 2023 ## 2024 ## The counter64 type should not be used for configuration 2025 ## objects. A default statement should not be used for 2026 ## attributes with a type value of counter64. 2027 ## 2028 ## This type is in the value set and its semantics equivalent 2029 ## to the Counter64 type of the SMIv2. 2031 ## See: RFC 2578: Structure of Management Information Version 2 (SMIv2) 2032 __counter64 = xsd:unsignedLong 2034 ## The zero-based-counter64 type represents a counter64 which 2035 ## has the defined `initial' value zero. 2036 ## 2037 ## Objects of this type will be set to zero(0) on creation 2038 ## and will thereafter count appropriate events, wrapping 2039 ## back to zero(0) when the value 2^64 is reached. 2040 ## 2041 ## Provided that an application discovers the new object within 2042 ## the minimum time to wrap it can use the initial value as a 2043 ## delta since it last polled the table of which this object is 2044 ## part. It is important for a management station to be aware 2045 ## of this minimum time and the actual time between polls, and 2046 ## to discard data if the actual time is too long or there is 2047 ## no defined minimum time. 2048 ## 2049 ## This type is in the value set and its semantics equivalent 2050 ## to the ZeroBasedCounter64 textual convention of the SMIv2. 2052 ## See: RFC 2856: Textual Conventions for Additional High Capacity 2053 ## Data Types 2054 __zero-based-counter64 = __counter64 >> dsrl:default-content [ "0" ] 2056 ## The gauge32 type represents a non-negative integer, which 2057 ## may increase or decrease, but shall never exceed a maximum 2058 ## value, nor fall below a minimum value. The maximum value 2059 ## can not be greater than 2^32-1 (4294967295 decimal), and 2060 ## the minimum value can not be smaller than 0. The value of 2061 ## a gauge32 has its maximum value whenever the information 2062 ## being modeled is greater than or equal to its maximum 2063 ## value, and has its minimum value whenever the information 2064 ## being modeled is smaller than or equal to its minimum value. 2065 ## If the information being modeled subsequently decreases 2066 ## below (increases above) the maximum (minimum) value, the 2067 ## gauge32 also decreases (increases). 2068 ## 2069 ## This type is in the value set and its semantics equivalent 2070 ## to the Counter32 type of the SMIv2. 2072 ## See: RFC 2578: Structure of Management Information Version 2 (SMIv2) 2073 __gauge32 = xsd:unsignedInt 2075 ## The gauge64 type represents a non-negative integer, which 2076 ## may increase or decrease, but shall never exceed a maximum 2077 ## value, nor fall below a minimum value. The maximum value 2078 ## can not be greater than 2^64-1 (18446744073709551615), and 2079 ## the minimum value can not be smaller than 0. The value of 2080 ## a gauge64 has its maximum value whenever the information 2081 ## being modeled is greater than or equal to its maximum 2082 ## value, and has its minimum value whenever the information 2083 ## being modeled is smaller than or equal to its minimum value. 2084 ## If the information being modeled subsequently decreases 2085 ## below (increases above) the maximum (minimum) value, the 2086 ## gauge64 also decreases (increases). 2087 ## 2088 ## This type is in the value set and its semantics equivalent 2089 ## to the CounterBasedGauge64 SMIv2 textual convention defined 2090 ## in RFC 2856 2092 ## See: RFC 2856: Textual Conventions for Additional High Capacity 2093 ## Data Types 2094 __gauge64 = xsd:unsignedLong 2096 ## The object-identifier type represents administratively 2097 ## assigned names in a registration-hierarchical-name tree. 2098 ## 2099 ## Values of this type are denoted as a sequence of numerical 2100 ## non-negative sub-identifier values. Each sub-identifier 2101 ## value MUST NOT exceed 2^32-1 (4294967295). Sub-identifiers 2102 ## are separated by single dots and without any intermediate 2103 ## white space. 2104 ## 2105 ## Although the number of sub-identifiers is not limited, 2106 ## module designers should realize that there may be 2107 ## implementations that stick with the SMIv2 limit of 128 2108 ## sub-identifiers. 2109 ## 2110 ## This type is a superset of the SMIv2 OBJECT IDENTIFIER type 2111 ## since it is not restricted to 128 sub-identifiers. 2113 ## See: ISO/IEC 9834-1: Information technology -- Open Systems 2114 ## Interconnection -- Procedures for the operation of OSI 2115 ## Registration Authorities: General procedures and top 2116 ## arcs of the ASN.1 Object Identifier tree 2117 __object-identifier = 2118 xsd:string { 2119 pattern = 2120 "(([0-1](\.[1-3]?[0-9]))|(2.(0|([1-9]\d*))))(\.(0|([1-9]\d*)))*" 2121 } 2123 ## This type represents object-identifiers restricted to 128 2124 ## sub-identifiers. 2125 ## 2126 ## This type is in the value set and its semantics equivalent to 2127 ## the OBJECT IDENTIFIER type of the SMIv2. 2129 ## See: RFC 2578: Structure of Management Information Version 2 (SMIv2) 2130 __object-identifier-128 = __object-identifier 2132 ## The date-and-time type is a profile of the ISO 8601 2133 ## standard for representation of dates and times using the 2134 ## Gregorian calendar. The format is most easily described 2135 ## using the following ABFN (see RFC 3339): 2136 ## 2137 ## date-fullyear = 4DIGIT 2138 ## date-month = 2DIGIT ; 01-12 2139 ## date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 2140 ## time-hour = 2DIGIT ; 00-23 2141 ## time-minute = 2DIGIT ; 00-59 2142 ## time-second = 2DIGIT ; 00-58, 00-59, 00-60 2143 ## time-secfrac = "." 1*DIGIT 2144 ## time-numoffset = ("+" / "-") time-hour ":" time-minute 2145 ## time-offset = "Z" / time-numoffset 2146 ## 2147 ## partial-time = time-hour ":" time-minute ":" time-second 2148 ## [time-secfrac] 2149 ## full-date = date-fullyear "-" date-month "-" date-mday 2150 ## full-time = partial-time time-offset 2151 ## 2152 ## date-time = full-date "T" full-time 2153 ## 2154 ## The date-and-time type is compatible with the dateTime XML 2155 ## schema type except that dateTime allows negative years 2156 ## which are not allowed by RFC 3339. 2157 ## 2158 ## This type is not equivalent to the DateAndTime textual 2159 ## convention of the SMIv2 since RFC 3339 uses a different 2160 ## separator between full-date and full-time and provides 2161 ## higher resolution of time-secfrac. 2163 ## See: RFC 3339: Date and Time on the Internet: Timestamps 2164 ## RFC 2579: Textual Conventions for SMIv2 2165 __date-and-time = 2166 xsd:string { 2167 pattern = 2168 "\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?(Z|(\+|-)\d{2}:\d{2})" 2169 } 2171 ## The timeticks type represents a non-negative integer which 2172 ## represents the time, modulo 2^32 (4294967296 decimal), in 2173 ## hundredths of a second between two epochs. When objects 2174 ## are defined which use this type, the description of the 2175 ## object identifies both of the reference epochs. 2176 ## 2177 ## This type is in the value set and its semantics equivalent to 2178 ## the TimeStamp textual convention of the SMIv2. 2180 ## See: RFC 2579: Textual Conventions for SMIv2 2181 __timeticks = xsd:unsignedInt 2183 ## The timestamp type represents the value of an associated 2184 ## timeticks object at which a specific occurrence happened. 2185 ## The specific occurrence must be defined in the description 2186 ## of any object defined using this type. When the specific 2187 ## occurrence occurred prior to the last time the associated 2188 ## timeticks attribute was zero, then the timestamp value is 2189 ## zero. Note that this requires all timestamp values to be 2190 ## reset to zero when the value of the associated timeticks 2191 ## attribute reaches 497+ days and wraps around to zero. 2192 ## 2193 ## The associated timeticks object must be specified 2194 ## in the description of any object using this type. 2195 ## 2196 ## This type is in the value set and its semantics equivalent to 2197 ## the TimeStamp textual convention of the SMIv2. 2199 ## See: RFC 2579: Textual Conventions for SMIv2 2200 __timestamp = __timeticks 2202 ## Represents media- or physical-level addresses represented 2203 ## as a sequence octets, each octet represented by two hexadecimal 2204 ## numbers. Octets are separated by colons. 2205 ## 2206 ## This type is in the value set and its semantics equivalent to 2207 ## the PhysAddress textual convention of the SMIv2. 2209 ## See: RFC 2579: Textual Conventions for SMIv2 2210 __phys-address = 2211 xsd:string { pattern = "([0-9a0-fA-F]{2}(:[0-9a0-fA-F]{2})*)?" } 2213 B.2. RelaxNG of Internet Specific Derived Types 2215 namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" 2216 namespace dc = "http://purl.org/dc/terms" 2217 namespace dsrl = "http://purl.oclc.org/dsdl/dsrl" 2218 namespace nm = "urn:ietf:params:xml:ns:netmod:dsdl-attrib:1" 2219 namespace sch = "http://purl.oclc.org/dsdl/schematron" 2221 dc:creator [ 2222 "IETF NETMOD (NETCONF Data Modeling Language) Working Group" 2223 ] 2224 dc:description [ 2225 "This module contains a collection of generally useful derived\x{a}" ~ 2226 "YANG data types for Internet addresses and related things.\x{a}" ~ 2227 "\x{a}" ~ 2228 "Copyright (C) The IETF Trust (2008). This version of this\x{a}" ~ 2229 "YANG module is part of RFC XXXX; see the RFC itself for full\x{a}" ~ 2230 "legal notices." 2231 ] 2232 dc:issued [ "2008-08-26" ] 2233 dc:source [ "YANG module 'inet-types' (automatic translation)" ] 2234 dc:contributor [ 2235 "WG Web: \x{a}" ~ 2236 "WG List: \x{a}" ~ 2237 "\x{a}" ~ 2238 "WG Chair: David Partain\x{a}" ~ 2239 " \x{a}" ~ 2240 "\x{a}" ~ 2241 "WG Chair: David Harrington\x{a}" ~ 2242 " \x{a}" ~ 2243 "\x{a}" ~ 2244 "Editor: Juergen Schoenwaelder\x{a}" ~ 2245 " " 2246 ] 2248 ## This value represents the version of the IP protocol. 2249 ## 2250 ## This type is in the value set and its semantics equivalent 2251 ## to the InetVersion textual convention of the SMIv2. However, 2252 ## the lexical appearance is different from the InetVersion 2253 ## textual convention. 2255 ## See: RFC 791: Internet Protocol 2256 ## RFC 2460: Internet Protocol, Version 6 (IPv6) Specification 2257 ## RFC 4001: Textual Conventions for Internet Network Addresses 2258 __ip-version = "unknown" | "ipv4" | "ipv6" 2260 ## The dscp type represents a Differentiated Services Code-Point 2261 ## that may be used for marking a traffic stream. 2262 ## 2263 ## This type is in the value set and its semantics equivalent 2264 ## to the Dscp textual convention of the SMIv2. 2266 ## See: RFC 3289: Management Information Base for the Differentiated 2267 ## Services Architecture 2268 ## RFC 2474: Definition of the Differentiated Services Field 2269 ## (DS Field) in the IPv4 and IPv6 Headers 2270 ## RFC 2780: IANA Allocation Guidelines For Values In 2271 ## the Internet Protocol and Related Headers 2272 __dscp = xsd:unsignedByte { minInclusive = "0" maxInclusive = "63" } 2274 ## The flow-label type represents flow identifier or Flow Label 2275 ## in an IPv6 packet header that may be used to discriminate 2276 ## traffic flows. 2277 ## 2278 ## This type is in the value set and its semantics equivalent 2279 ## to the IPv6FlowLabel textual convention of the SMIv2. 2281 ## See: RFC 3595: Textual Conventions for IPv6 Flow Label 2282 ## RFC 2460: Internet Protocol, Version 6 (IPv6) Specification 2283 __flow-label = 2284 xsd:unsignedInt { minInclusive = "0" maxInclusive = "1048575" } 2286 ## The port-number type represents a 16-bit port number of an 2287 ## Internet transport layer protocol such as UDP, TCP, DCCP or 2288 ## SCTP. Port numbers are assigned by IANA. A current list of 2289 ## all assignments is available from . 2290 ## 2291 ## Note that the value zero is not a valid port number. A union 2292 ## type might be used in situations where the value zero is 2293 ## meaningful. 2294 ## 2295 ## This type is in the value set and its semantics equivalent 2296 ## to the InetPortNumber textual convention of the SMIv2. 2298 ## See: RFC 768: User Datagram Protocol 2299 ## RFC 793: Transmission Control Protocol 2300 ## RFC 2960: Stream Control Transmission Protocol 2301 ## RFC 4340: Datagram Congestion Control Protocol (DCCP) 2302 ## RFC 4001: Textual Conventions for Internet Network Addresses 2303 __port-number = 2304 xsd:unsignedShort { minInclusive = "1" maxInclusive = "65535" } 2306 ## The as-number type represents autonomous system numbers 2307 ## which identify an Autonomous System (AS). An AS is a set 2308 ## of routers under a single technical administration, using 2309 ## an interior gateway protocol and common metrics to route 2310 ## packets within the AS, and using an exterior gateway 2311 ## protocol to route packets to other ASs'. IANA maintains 2312 ## ; the AS number space and has delegated large parts to the 2313 ## regional registries. 2314 ## 2315 ## Autonomous system numbers are currently limited to 16 bits 2316 ## (0..65535). There is however work in progress to enlarge 2317 ## the autonomous system number space to 32 bits. This 2318 ## textual convention therefore uses an uint32 base type 2319 ## without a range restriction in order to support a larger 2320 ## autonomous system number space. 2321 ## 2322 ## This type is in the value set and its semantics equivalent 2323 ## to the InetAutonomousSystemNumber textual convention of 2324 ## the SMIv2. 2326 ## See: RFC 1930: Guidelines for creation, selection, and registration 2327 ## of an Autonomous System (AS) 2328 ## RFC 4271: A Border Gateway Protocol 4 (BGP-4) 2329 ## RFC 4001: Textual Conventions for Internet Network Addresses 2330 __autonomous-system-number = xsd:unsignedInt 2332 ## The ip-address type represents an IP address and is IP 2333 ## version neutral. The format of the textual representations 2334 ## implies the IP version. 2335 __ip-address = __ipv4-address | __ipv6-address 2337 ## The ipv4-address type represents an IPv4 address in 2338 ## dotted-quad notation. The IPv4 address may include a zone 2339 ## index, separated by a % sign. 2340 ## 2341 ## The zone index is used to disambiguate identical address 2342 ## values. For link-local addresses, the zone index will 2343 ## typically be the interface index number or the name of an 2344 ## interface. If the zone index is not present, the default 2345 ## zone of the device will be used. 2346 __ipv4-address = 2347 xsd:string { 2348 pattern = 2349 "((0|(1[0-9]{0,2})|(2(([0-4][0-9]?)|(5[0-5]?)|([6-9]?)" 2350 ~ "))|([3-9][0-9]?))\.){3}(0|(1[0-9]{0,2})|(2(([0-4][0-9]?)|(5[" 2351 ~ "0-5]?)|([6-9]?)))|([3-9][0-9]?))(%[\p{N}\p{L}]+)?" 2352 } 2354 ## The ipv6-address type represents an IPv6 address in full, 2355 ## mixed, shortened and shortened mixed notation. The IPv6 2356 ## address may include a zone index, separated by a % sign. 2357 ## 2358 ## The zone index is used to disambiguate identical address 2359 ## values. For link-local addresses, the zone index will 2360 ## typically be the interface index number or the name of an 2361 ## interface. If the zone index is not present, the default 2362 ## zone of the device will be used. 2364 ## See: RFC 4007: IPv6 Scoped Address Architecture 2365 __ipv6-address = 2366 xsd:string { 2367 pattern = 2368 "((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})(%[\p{N}\p" 2369 ~ "{L}]+)?)|((([0-9a-fA-F]{1,4}:){6})(([0-9]{1,3}\.[0-9]{1,3}\." 2370 ~ "[0-9]{1,3}\.[0-9]{1,3}))(%[\p{N}\p{L}]+)?)|((([0-9a-fA-F]{1," 2371 ~ "4}:)*([0-9a-fA-F]{1,4}))*(::)(([0-9a-fA-F]{1,4}:)*([0-9a-fA-" 2372 ~ "F]{1,4}))*(%[\p{N}\p{L}]+)?)|((([0-9a-fA-F]{1,4}:)*([0-9a-fA" 2373 ~ "-F]{1,4}))*(::)(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(([0" 2374 ~ "-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))(%[\p{N}\p{L}]" 2375 ~ "+)?)" 2376 } 2378 ## The ip-prefix type represents an IP prefix and is IP 2379 ## version neutral. The format of the textual representations 2380 ## implies the IP version. 2381 __ip-prefix = __ipv4-prefix | __ipv6-prefix 2383 ## The ipv4-prefix type represents an IPv4 address prefix. 2384 ## The prefix length is given by the number following the 2385 ## slash character and must be less than or equal to 32. 2386 ## 2387 ## A prefix length value of n corresponds to an IP address 2388 ## mask which has n contiguous 1-bits from the most 2389 ## significant bit (MSB) and all other bits set to 0. 2390 ## 2391 ## The IPv4 address represented in dotted quad notation 2392 ## should have all bits that do not belong to the prefix 2393 ## set to zero. 2394 __ipv4-prefix = 2395 xsd:string { 2396 pattern = 2397 "(([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])\.){3}([0-1]?" 2398 ~ "[0-9]?[0-9]|2[0-4][0-9]|25[0-5])/\d+" 2400 } 2402 ## The ipv6-prefix type represents an IPv6 address prefix. 2403 ## The prefix length is given by the number following the 2404 ## slash character and must be less than or equal 128. 2405 ## 2406 ## A prefix length value of n corresponds to an IP address 2407 ## mask which has n contiguous 1-bits from the most 2408 ## significant bit (MSB) and all other bits set to 0. 2409 ## 2410 ## The IPv6 address should have all bits that do not belong 2411 ## to the prefix set to zero. 2412 __ipv6-prefix = 2413 xsd:string { 2414 pattern = 2415 "((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})/\d+)|((([" 2416 ~ "0-9a-fA-F]{1,4}:){6})(([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[" 2417 ~ "0-9]{1,3}))/\d+)|((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(" 2418 ~ "::)(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*/\d+)|((([0-9a-f" 2419 ~ "A-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)(([0-9a-fA-F]{1,4}:)*([0" 2420 ~ "-9a-fA-F]{1,4}))*(([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]" 2421 ~ "{1,3}))/\d+)" 2422 } 2424 ## The domain-name type represents a DNS domain name. The 2425 ## name SHOULD be fully qualified whenever possible. 2426 ## 2427 ## The description clause of objects using the domain-name 2428 ## type MUST describe how (and when) these names are 2429 ## resolved to IP addresses. 2430 ## 2431 ## Note that the resolution of a domain-name value may 2432 ## require to query multiple DNS records (e.g., A for IPv4 2433 ## and AAAA for IPv6). The order of the resolution process 2434 ## and which DNS record takes precedence depends on the 2435 ## configuration of the resolver. 2437 ## See: RFC 1034: Domain Names - Concepts and Facilities 2438 ## RFC 1123: Requirements for Internet Hosts -- Application 2439 ## and Support 2440 __domain-name = 2441 xsd:string { 2442 pattern = 2443 "([a-zA-Z0-9][a-zA-Z0-9\-]*[a-zA-Z0-9]\.)*[a-zA-Z0-9][" 2444 ~ "a-zA-Z0-9\-]*[a-zA-Z0-9]" 2445 } 2447 ## The host type represents either an IP address or a DNS 2448 ## domain name. 2449 __host = __ip-address | __domain-name 2451 ## The uri type represents a Uniform Resource Identifier 2452 ## (URI) as defined by STD 66. 2453 ## 2454 ## Objects using the uri type must be in US-ASCII encoding, 2455 ## and MUST be normalized as described by RFC 3986 Sections 2456 ## 6.2.1, 6.2.2.1, and 6.2.2.2. All unnecessary 2457 ## percent-encoding is removed, and all case-insensitive 2458 ## characters are set to lowercase except for hexadecimal 2459 ## digits, which are normalized to uppercase as described in 2460 ## Section 6.2.2.1. 2461 ## 2462 ## The purpose of this normalization is to help provide 2463 ## unique URIs. Note that this normalization is not 2464 ## sufficient to provide uniqueness. Two URIs that are 2465 ## textually distinct after this normalization may still be 2466 ## equivalent. 2467 ## 2468 ## Objects using the uri type may restrict the schemes that 2469 ## they permit. For example, 'data:' and 'urn:' schemes 2470 ## might not be appropriate. 2471 ## 2472 ## A zero-length URI is not a valid URI. This can be used to 2473 ## express 'URI absent' where required 2474 ## 2475 ## This type is in the value set and its semantics equivalent 2476 ## to the Uri textual convention of the SMIv2. 2478 ## See: RFC 3986: Uniform Resource Identifier (URI): Generic Syntax 2479 ## RFC 3305: Report from the Joint W3C/IETF URI Planning Interest 2480 ## Group: Uniform Resource Identifiers (URIs), URLs, 2481 ## and Uniform Resource Names (URNs): Clarifications 2482 ## and Recommendations 2483 ## RFC 5017: MIB Textual Conventions for Uniform Resource 2484 ## Identifiers (URIs) 2485 __uri = xsd:string 2487 B.3. RelaxNG of IEEE Specific Derived Types 2489 namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" 2490 namespace dc = "http://purl.org/dc/terms" 2491 namespace dsrl = "http://purl.oclc.org/dsdl/dsrl" 2492 namespace nm = "urn:ietf:params:xml:ns:netmod:dsdl-attrib:1" 2493 namespace sch = "http://purl.oclc.org/dsdl/schematron" 2495 dc:creator [ 2496 "IETF NETMOD (NETCONF Data Modeling Language) Working Group" 2497 ] 2498 dc:description [ 2499 "This module contains a collection of generally useful derived\x{a}" ~ 2500 "YANG data types for IEEE 802 addresses and related things.\x{a}" ~ 2501 "\x{a}" ~ 2502 "Copyright (C) The IETF Trust (2008). This version of this\x{a}" ~ 2503 "YANG module is part of RFC XXXX; see the RFC itself for full\x{a}" ~ 2504 "legal notices." 2505 ] 2506 dc:issued [ "2008-08-22" ] 2507 dc:source [ "YANG module 'ieee-types' (automatic translation)" ] 2508 dc:contributor [ 2509 "WG Web: \x{a}" ~ 2510 "WG List: \x{a}" ~ 2511 "\x{a}" ~ 2512 "WG Chair: David Partain\x{a}" ~ 2513 " \x{a}" ~ 2514 "\x{a}" ~ 2515 "WG Chair: David Harrington\x{a}" ~ 2516 " \x{a}" ~ 2517 "\x{a}" ~ 2518 "Editor: Juergen Schoenwaelder\x{a}" ~ 2519 " " 2520 ] 2522 ## The mac-address type represents an 802 MAC address represented 2523 ## in the `canonical' order defined by IEEE 802.1a, i.e., as if it 2524 ## were transmitted least significant bit first, even though 802.5 2525 ## (in contrast to other 802.x protocols) requires MAC addresses 2526 ## to be transmitted most significant bit first. 2527 ## 2528 ## This type is in the value set and its semantics equivalent to 2529 ## the MacAddress textual convention of the SMIv2. 2531 ## See: RFC 2579: Textual Conventions for SMIv2 2532 __mac-address = 2533 xsd:string { pattern = "[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}" } 2535 ## The bridgeid type represents identifiers that uniquely 2536 ## identify a bridge. Its first four hexadecimal digits 2537 ## contain a priority value followed by a colon. The 2538 ## remaining characters contain the MAC address used to 2539 ## refer to a bridge in a unique fashion (typically, the 2540 ## numerically smallest MAC address of all ports on the 2541 ## bridge). 2542 ## 2543 ## This type is in the value set and its semantics equivalent 2544 ## to the BridgeId textual convention of the SMIv2. However, 2545 ## since the BridgeId textual convention does not prescribe 2546 ## a lexical representation, the appearance might be different. 2548 ## See: RFC 4188: Definitions of Managed Objects for Bridges 2549 __bridgeid = 2550 xsd:string { pattern = "[0-9a-fA-F]{4}(:[0-9a-fA-F]{2}){6}" } 2552 ## The vlanid type uniquely identifies a VLAN. This is the 2553 ## 12-bit VLAN-ID used in the VLAN Tag header. The range is 2554 ## defined by the referenced specification. 2555 ## 2556 ## This type is in the value set and its semantics equivalent to 2557 ## the VlanId textual convention of the SMIv2. 2559 ## See: IEEE Std 802.1Q 2003 Edition: Virtual Bridged Local 2560 ## Area Networks 2561 ## RFC 4363: Definitions of Managed Objects for Bridges with 2562 ## Traffic Classes, Multicast Filtering, and Virtual 2563 ## LAN Extensions 2564 __vlanid = 2565 xsd:unsignedShort { minInclusive = "1" maxInclusive = "4094" } 2567 Author's Address 2569 Juergen Schoenwaelder (editor) 2570 Jacobs University 2572 Email: j.schoenwaelder@jacobs-university.de 2574 Full Copyright Statement 2576 Copyright (C) The IETF Trust (2008). 2578 This document is subject to the rights, licenses and restrictions 2579 contained in BCP 78, and except as set forth therein, the authors 2580 retain all their rights. 2582 This document and the information contained herein are provided on an 2583 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2584 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2585 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2586 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2587 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2588 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2590 Intellectual Property 2592 The IETF takes no position regarding the validity or scope of any 2593 Intellectual Property Rights or other rights that might be claimed to 2594 pertain to the implementation or use of the technology described in 2595 this document or the extent to which any license under such rights 2596 might or might not be available; nor does it represent that it has 2597 made any independent effort to identify any such rights. Information 2598 on the procedures with respect to rights in RFC documents can be 2599 found in BCP 78 and BCP 79. 2601 Copies of IPR disclosures made to the IETF Secretariat and any 2602 assurances of licenses to be made available, or the result of an 2603 attempt made to obtain a general license or permission for the use of 2604 such proprietary rights by implementers or users of this 2605 specification can be obtained from the IETF on-line IPR repository at 2606 http://www.ietf.org/ipr. 2608 The IETF invites any interested party to bring to its attention any 2609 copyrights, patents or patent applications, or other proprietary 2610 rights that may cover technology that may be required to implement 2611 this standard. Please address the information to the IETF at 2612 ietf-ipr@ietf.org. 2614 Acknowledgment 2616 Funding for the RFC Editor function is provided by the IETF 2617 Administrative Support Activity (IASA).