idnits 2.17.1 draft-ietf-netmod-yang-types-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors Copyright Line does not match the current year == Line 992 has weird spacing: '...g-types urn...' == Line 993 has weird spacing: '...t-types urn...' == Line 994 has weird spacing: '...e-types urn...' -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 9, 2009) is 5527 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 2509, but not defined == Missing Reference: '1-3' is mentioned on line 2198, but not defined == Missing Reference: '0-9' is mentioned on line 2510, but not defined == Missing Reference: '1-9' is mentioned on line 2198, but not defined == Missing Reference: 'TODO' is mentioned on line 840, but not defined == Missing Reference: '0-4' is mentioned on line 2510, but not defined == Missing Reference: '0-5' is mentioned on line 2510, but not defined == Missing Reference: '6-9' is mentioned on line 2455, but not defined == Missing Reference: '3-9' is mentioned on line 2455, but not defined == Unused Reference: 'RFC0768' is defined on line 1048, but no explicit reference was found in the text == Unused Reference: 'RFC0791' is defined on line 1051, but no explicit reference was found in the text == Unused Reference: 'RFC0793' is defined on line 1054, but no explicit reference was found in the text == Unused Reference: 'RFC1034' is defined on line 1057, but no explicit reference was found in the text == Unused Reference: 'RFC1123' is defined on line 1060, but no explicit reference was found in the text == Unused Reference: 'RFC1930' is defined on line 1063, but no explicit reference was found in the text == Unused Reference: 'RFC2021' is defined on line 1067, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 1071, but no explicit reference was found in the text == Unused Reference: 'RFC2474' is defined on line 1074, but no explicit reference was found in the text == Unused Reference: 'RFC2578' is defined on line 1079, but no explicit reference was found in the text == Unused Reference: 'RFC2579' is defined on line 1083, but no explicit reference was found in the text == Unused Reference: 'RFC2780' is defined on line 1087, but no explicit reference was found in the text == Unused Reference: 'RFC2856' is defined on line 1091, but no explicit reference was found in the text == Unused Reference: 'RFC2960' is defined on line 1095, but no explicit reference was found in the text == Unused Reference: 'RFC3289' is defined on line 1100, but no explicit reference was found in the text == Unused Reference: 'RFC3305' is defined on line 1104, but no explicit reference was found in the text == Unused Reference: 'RFC3339' is defined on line 1110, but no explicit reference was found in the text == Unused Reference: 'RFC3595' is defined on line 1113, but no explicit reference was found in the text == Unused Reference: 'RFC3986' is defined on line 1116, but no explicit reference was found in the text == Unused Reference: 'RFC4001' is defined on line 1120, but no explicit reference was found in the text == Unused Reference: 'RFC4007' is defined on line 1124, but no explicit reference was found in the text == Unused Reference: 'RFC4188' is defined on line 1128, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 1131, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 1134, but no explicit reference was found in the text == Unused Reference: 'RFC4340' is defined on line 1137, but no explicit reference was found in the text == Unused Reference: 'RFC4893' is defined on line 1143, but no explicit reference was found in the text == Unused Reference: 'RFC5017' is defined on line 1146, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-netmod-yang-04 -- 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) -- Obsolete informational reference (is this intentional?): RFC 4893 (Obsoleted by RFC 6793) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 42 warnings (==), 10 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 March 9, 2009 5 Expires: September 10, 2009 7 Common YANG Data Types 8 draft-ietf-netmod-yang-types-02 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may contain material 14 from IETF Documents or IETF Contributions published or made publicly 15 available before November 10, 2008. The person(s) controlling the 16 copyright in some of this material may not have granted the IETF 17 Trust the right to allow modifications of such material outside the 18 IETF Standards Process. Without obtaining an adequate license from 19 the person(s) controlling the copyright in such materials, this 20 document may not be modified outside the IETF Standards Process, and 21 derivative works of it may not be created outside the IETF Standards 22 Process, except to format it for publication as an RFC or to 23 translate it into languages other than English. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on September 10, 2009. 43 Copyright Notice 45 Copyright (c) 2009 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents in effect on the date of 50 publication of this document (http://trustee.ietf.org/license-info). 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. 54 Abstract 56 This document introduces a collection of common data types to be used 57 with the YANG data modeling language. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Core YANG Derived Types . . . . . . . . . . . . . . . . . . . 5 63 3. Internet Specific Derived Types . . . . . . . . . . . . . . . 13 64 4. IEEE Specific Derived Types . . . . . . . . . . . . . . . . . 22 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 67 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 69 8.1. Normative References . . . . . . . . . . . . . . . . . . . 28 70 8.2. Informative References . . . . . . . . . . . . . . . . . . 28 71 Appendix A. XSD Translations . . . . . . . . . . . . . . . . . . 31 72 A.1. XSD of Core YANG Derived Types . . . . . . . . . . . . . . 31 73 A.2. XSD of Internet Specific Derived Types . . . . . . . . . . 38 74 A.3. XSD of IEEE Specific Derived Types . . . . . . . . . . . . 46 75 Appendix B. RelaxNG Translations . . . . . . . . . . . . . . . . 49 76 B.1. RelaxNG of Core YANG Derived Types . . . . . . . . . . . . 49 77 B.2. RelaxNG of Internet Specific Derived Types . . . . . . . . 55 78 B.3. RelaxNG of IEEE Specific Derived Types . . . . . . . . . . 61 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 64 81 1. Introduction 83 YANG [YANG] is a data modeling language used to model configuration 84 and state data manipulated by the NETCONF [RFC4741] protocol. The 85 YANG language supports a small set of built-in data types and 86 provides mechanisms to derive other types from the built-in types. 88 This document introduces a collection of common data types derived 89 from the built-in YANG data types. The definitions are organized in 90 several YANG modules. The "ietf-yang-types" module contains 91 generally useful data types. The "ietf-inet-types" module contains 92 definitions that are relevant for the Internet protocol suite while 93 the "ietf-ieee-types" module contains definitions that are relevant 94 for IEEE 802 protocols. 96 Their derived types are generally designed to be applicable for 97 modeling all areas of management information. 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 101 "OPTIONAL" in this document are to be interpreted as described in BCP 102 14, [RFC2119]. 104 2. Core YANG Derived Types 106 module ietf-yang-types { 108 namespace "urn:ietf:params:xml:ns:yang:yang-types"; 109 prefix "yang"; 111 organization 112 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 114 contact 115 "WG Web: 116 WG List: 118 WG Chair: David Partain 119 121 WG Chair: David Kessens 122 124 Editor: Juergen Schoenwaelder 125 "; 127 description 128 "This module contains a collection of generally useful derived 129 YANG data types. 131 Copyright (C) 2009 The IETF Trust and the persons identified as 132 the document authors. This version of this YANG module is part 133 of RFC XXXX; see the RFC itself for full legal notices."; 134 // RFC Ed.: replace XXXX with actual RFC number and remove this note 136 revision 2009-03-09 { 137 description 138 "Initial revision, published as RFC XXXX."; 139 } 140 // RFC Ed.: replace XXXX with actual RFC number and remove this note 142 /*** collection of counter and gauge types ***/ 144 typedef counter32 { 145 type uint32; 146 description 147 "The counter32 type represents a non-negative integer 148 which monotonically increases until it reaches a 149 maximum value of 2^32-1 (4294967295 decimal), when it 150 wraps around and starts increasing again from zero. 152 Counters have no defined `initial' value, and thus, a 153 single value of a counter has (in general) no information 154 content. Discontinuities in the monotonically increasing 155 value normally occur at re-initialization of the 156 management system, and at other times as specified in the 157 description of an object instance using this type. If 158 such other times can occur, for example, the creation of 159 an object instance of type counter32 at times other than 160 re-initialization, then a corresponding object should be 161 defined, with an appropriate type, to indicate the last 162 discontinuity. 164 The counter32 type should not be used for configuration 165 objects. A default statement should not be used for 166 attributes with a type value of counter32. 168 This type is in the value set and its semantics equivalent 169 to the Counter32 type of the SMIv2."; 170 reference 171 "RFC 2578: Structure of Management Information Version 2 (SMIv2)"; 172 } 174 typedef zero-based-counter32 { 175 type yang:counter32; 176 default "0"; 177 description 178 "The zero-based-counter32 type represents a counter32 179 which has the defined `initial' value zero. 181 Objects of this type will be set to zero(0) on creation 182 and will thereafter count appropriate events, wrapping 183 back to zero(0) when the value 2^32 is reached. 185 Provided that an application discovers the new object within 186 the minimum time to wrap it can use the initial value as a 187 delta since it last polled the table of which this object is 188 part. It is important for a management station to be aware 189 of this minimum time and the actual time between polls, and 190 to discard data if the actual time is too long or there is 191 no defined minimum time. 193 This type is in the value set and its semantics equivalent 194 to the ZeroBasedCounter32 textual convention of the SMIv2."; 195 reference 196 "RFC 2021: Remote Network Monitoring Management Information 197 Base Version 2 using SMIv2"; 198 } 199 typedef counter64 { 200 type uint64; 201 description 202 "The counter64 type represents a non-negative integer 203 which monotonically increases until it reaches a 204 maximum value of 2^64-1 (18446744073709551615), when 205 it wraps around and starts increasing again from zero. 207 Counters have no defined `initial' value, and thus, a 208 single value of a counter has (in general) no information 209 content. Discontinuities in the monotonically increasing 210 value normally occur at re-initialization of the 211 management system, and at other times as specified in the 212 description of an object instance using this type. If 213 such other times can occur, for example, the creation of 214 an object instance of type counter64 at times other than 215 re-initialization, then a corresponding object should be 216 defined, with an appropriate type, to indicate the last 217 discontinuity. 219 The counter64 type should not be used for configuration 220 objects. A default statement should not be used for 221 attributes with a type value of counter64. 223 This type is in the value set and its semantics equivalent 224 to the Counter64 type of the SMIv2."; 225 reference 226 "RFC 2578: Structure of Management Information Version 2 (SMIv2)"; 227 } 229 typedef zero-based-counter64 { 230 type yang:counter64; 231 default "0"; 232 description 233 "The zero-based-counter64 type represents a counter64 which 234 has the defined `initial' value zero. 236 Objects of this type will be set to zero(0) on creation 237 and will thereafter count appropriate events, wrapping 238 back to zero(0) when the value 2^64 is reached. 240 Provided that an application discovers the new object within 241 the minimum time to wrap it can use the initial value as a 242 delta since it last polled the table of which this object is 243 part. It is important for a management station to be aware 244 of this minimum time and the actual time between polls, and 245 to discard data if the actual time is too long or there is 246 no defined minimum time. 248 This type is in the value set and its semantics equivalent 249 to the ZeroBasedCounter64 textual convention of the SMIv2."; 250 reference 251 "RFC 2856: Textual Conventions for Additional High Capacity 252 Data Types"; 253 } 255 typedef gauge32 { 256 type uint32; 257 description 258 "The gauge32 type represents a non-negative integer, which 259 may increase or decrease, but shall never exceed a maximum 260 value, nor fall below a minimum value. The maximum value 261 can not be greater than 2^32-1 (4294967295 decimal), and 262 the minimum value can not be smaller than 0. The value of 263 a gauge32 has its maximum value whenever the information 264 being modeled is greater than or equal to its maximum 265 value, and has its minimum value whenever the information 266 being modeled is smaller than or equal to its minimum value. 267 If the information being modeled subsequently decreases 268 below (increases above) the maximum (minimum) value, the 269 gauge32 also decreases (increases). 271 This type is in the value set and its semantics equivalent 272 to the Counter32 type of the SMIv2."; 273 reference 274 "RFC 2578: Structure of Management Information Version 2 (SMIv2)"; 275 } 277 typedef gauge64 { 278 type uint64; 279 description 280 "The gauge64 type represents a non-negative integer, which 281 may increase or decrease, but shall never exceed a maximum 282 value, nor fall below a minimum value. The maximum value 283 can not be greater than 2^64-1 (18446744073709551615), and 284 the minimum value can not be smaller than 0. The value of 285 a gauge64 has its maximum value whenever the information 286 being modeled is greater than or equal to its maximum 287 value, and has its minimum value whenever the information 288 being modeled is smaller than or equal to its minimum value. 289 If the information being modeled subsequently decreases 290 below (increases above) the maximum (minimum) value, the 291 gauge64 also decreases (increases). 293 This type is in the value set and its semantics equivalent 294 to the CounterBasedGauge64 SMIv2 textual convention defined 295 in RFC 2856"; 297 reference 298 "RFC 2856: Textual Conventions for Additional High Capacity 299 Data Types"; 300 } 302 /*** collection of identifier related types ***/ 304 typedef object-identifier { 305 type string { 306 pattern '(([0-1](\.[1-3]?[0-9]))|(2\.(0|([1-9]\d*))))' 307 + '(\.(0|([1-9]\d*)))*'; 308 } 309 description 310 "The object-identifier type represents administratively 311 assigned names in a registration-hierarchical-name tree. 313 Values of this type are denoted as a sequence of numerical 314 non-negative sub-identifier values. Each sub-identifier 315 value MUST NOT exceed 2^32-1 (4294967295). Sub-identifiers 316 are separated by single dots and without any intermediate 317 white space. 319 Although the number of sub-identifiers is not limited, 320 module designers should realize that there may be 321 implementations that stick with the SMIv2 limit of 128 322 sub-identifiers. 324 This type is a superset of the SMIv2 OBJECT IDENTIFIER type 325 since it is not restricted to 128 sub-identifiers."; 326 reference 327 "ISO/IEC 9834-1: Information technology -- Open Systems 328 Interconnection -- Procedures for the operation of OSI 329 Registration Authorities: General procedures and top 330 arcs of the ASN.1 Object Identifier tree"; 331 } 333 typedef object-identifier-128 { 334 type object-identifier { 335 pattern '\d*(.\d*){1,127}'; 336 } 337 description 338 "This type represents object-identifiers restricted to 128 339 sub-identifiers. 341 This type is in the value set and its semantics equivalent 342 to the OBJECT IDENTIFIER type of the SMIv2."; 343 reference 344 "RFC 2578: Structure of Management Information Version 2 (SMIv2)"; 346 } 348 /*** collection of date and time related types ***/ 350 typedef date-and-time { 351 type string { 352 pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?' 353 + '(Z|(\+|-)\d{2}:\d{2})'; 354 } 355 description 356 'The date-and-time type is a profile of the ISO 8601 357 standard for representation of dates and times using the 358 Gregorian calendar. The format is most easily described 359 using the following ABFN (see RFC 3339): 361 date-fullyear = 4DIGIT 362 date-month = 2DIGIT ; 01-12 363 date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 364 time-hour = 2DIGIT ; 00-23 365 time-minute = 2DIGIT ; 00-59 366 time-second = 2DIGIT ; 00-58, 00-59, 00-60 367 time-secfrac = "." 1*DIGIT 368 time-numoffset = ("+" / "-") time-hour ":" time-minute 369 time-offset = "Z" / time-numoffset 371 partial-time = time-hour ":" time-minute ":" time-second 372 [time-secfrac] 373 full-date = date-fullyear "-" date-month "-" date-mday 374 full-time = partial-time time-offset 376 date-time = full-date "T" full-time 378 The date-and-time type is consistent with the semantics defined 379 in RFC 3339. The data-and-time type is compatible with the 380 dateTime XML schema type with the following two notable 381 exceptions: 383 (a) The data-and-time type does not allow negative years. 385 (b) The data-and-time time-offset -00:00 indicates an unknown 386 time zone (see RFC 3339) while -00:00 and +00:00 and Z all 387 represent the same time zone in dateTime. 389 This type is not equivalent to the DateAndTime textual 390 convention of the SMIv2 since RFC 3339 uses a different 391 separator between full-date and full-time and provides 392 higher resolution of time-secfrac. 394 The canonical format for date-and-time values mandates the UTC 395 time format with the time-offset is indicated by the letter "Z". 396 This is consistent with the canonical format used by the 397 dateTime XML schema type.'; 398 reference 399 "RFC 3339: Date and Time on the Internet: Timestamps 400 RFC 2579: Textual Conventions for SMIv2 401 W3C REC-xmlschema-2-20041028: XML Schema Part 2: Datatypes 402 Second Edition"; 403 } 405 typedef timeticks { 406 type uint32; 407 description 408 "The timeticks type represents a non-negative integer which 409 represents the time, modulo 2^32 (4294967296 decimal), in 410 hundredths of a second between two epochs. When objects 411 are defined which use this type, the description of the 412 object identifies both of the reference epochs. 414 This type is in the value set and its semantics equivalent 415 to the TimeTicks type of the SMIv2."; 416 reference 417 "RFC 2578: Structure of Management Information Version 2 (SMIv2)"; 418 } 420 typedef timestamp { 421 type yang:timeticks; 422 description 423 "The timestamp type represents the value of an associated 424 timeticks object at which a specific occurrence happened. 425 The specific occurrence must be defined in the description 426 of any object defined using this type. When the specific 427 occurrence occurred prior to the last time the associated 428 timeticks attribute was zero, then the timestamp value is 429 zero. Note that this requires all timestamp values to be 430 reset to zero when the value of the associated timeticks 431 attribute reaches 497+ days and wraps around to zero. 433 The associated timeticks object must be specified 434 in the description of any object using this type. 436 This type is in the value set and its semantics equivalent 437 to the TimeStamp textual convention of the SMIv2."; 438 reference 439 "RFC 2579: Textual Conventions for SMIv2"; 440 } 441 /*** collection of generic address types ***/ 443 typedef phys-address { 444 type string { 445 pattern '([0-9a0-fA-F]{2}(:[0-9a0-fA-F]{2})*)?'; 446 } 447 description 448 "Represents media- or physical-level addresses represented 449 as a sequence octets, each octet represented by two hexadecimal 450 numbers. Octets are separated by colons. 452 This type is in the value set and its semantics equivalent 453 to the PhysAddress textual convention of the SMIv2."; 454 reference 455 "RFC 2579: Textual Conventions for SMIv2"; 456 } 458 /*** collection of XML specific types ***/ 460 typedef xpath { // [TODO] call this xpath1-0? 461 type string; 462 description 463 "This type represents an XPATH 1.0 expression."; 464 // [TODO] Normalization needed due to abbreviated syntax and the 465 // unabbreviated syntax? Whitespace stuff to take care of? 466 reference 467 "W3C REC-xpath-19991116: XML Path Language (XPath) Version 1.0"; 468 } 470 } 472 3. Internet Specific Derived Types 474 module ietf-inet-types { 476 namespace "urn:ietf:params:xml:ns:yang:inet-types"; 477 prefix "inet"; 479 organization 480 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 482 contact 483 "WG Web: 484 WG List: 486 WG Chair: David Partain 487 489 WG Chair: David Kessens 490 492 Editor: Juergen Schoenwaelder 493 "; 495 description 496 "This module contains a collection of generally useful derived 497 YANG data types for Internet addresses and related things. 499 Copyright (C) 2009 The IETF Trust and the persons identified as 500 the document authors. This version of this YANG module is part 501 of RFC XXXX; see the RFC itself for full legal notices."; 502 // RFC Ed.: replace XXXX with actual RFC number and remove this note 504 revision 2009-03-09 { 505 description 506 "Initial revision, published as RFC XXXX."; 507 } 508 // RFC Ed.: replace XXXX with actual RFC number and remove this note 510 /*** collection of protocol field related types ***/ 512 typedef ip-version { 513 type enumeration { 514 enum unknown { 515 value "0"; 516 description 517 "An unknown or unspecified version of the Internet protocol."; 518 } 519 enum ipv4 { 520 value "1"; 521 description 522 "The IPv4 protocol as defined in RFC 791."; 523 } 524 enum ipv6 { 525 value "2"; 526 description 527 "The IPv6 protocol as defined in RFC 2460."; 528 } 529 } 530 description 531 "This value represents the version of the IP protocol. 533 This type is in the value set and its semantics equivalent 534 to the InetVersion textual convention of the SMIv2. However, 535 the lexical appearance is different from the InetVersion 536 textual convention."; 537 reference 538 "RFC 791: Internet Protocol 539 RFC 2460: Internet Protocol, Version 6 (IPv6) Specification 540 RFC 4001: Textual Conventions for Internet Network Addresses"; 541 } 543 typedef dscp { 544 type uint8 { 545 range "0..63"; 546 } 547 description 548 "The dscp type represents a Differentiated Services Code-Point 549 that may be used for marking packets in a traffic stream. 551 This type is in the value set and its semantics equivalent 552 to the Dscp textual convention of the SMIv2."; 553 reference 554 "RFC 3289: Management Information Base for the Differentiated 555 Services Architecture 556 RFC 2474: Definition of the Differentiated Services Field 557 (DS Field) in the IPv4 and IPv6 Headers 558 RFC 2780: IANA Allocation Guidelines For Values In 559 the Internet Protocol and Related Headers"; 560 } 562 typedef flow-label { 563 type uint32 { 564 range "0..1048575"; 565 } 566 description 567 "The flow-label type represents flow identifier or Flow Label 568 in an IPv6 packet header that may be used to discriminate 569 traffic flows. 571 This type is in the value set and its semantics equivalent 572 to the IPv6FlowLabel textual convention of the SMIv2."; 573 reference 574 "RFC 3595: Textual Conventions for IPv6 Flow Label 575 RFC 2460: Internet Protocol, Version 6 (IPv6) Specification"; 576 } 578 typedef port-number { 579 type uint16 { 580 range "1..65535"; 581 } 582 description 583 "The port-number type represents a 16-bit port number of an 584 Internet transport layer protocol such as UDP, TCP, DCCP or 585 SCTP. Port numbers are assigned by IANA. A current list of 586 all assignments is available from . 588 Note that the value zero is not a valid port number. A union 589 type might be used in situations where the value zero is 590 meaningful. 592 This type is in the value set and its semantics equivalent 593 to the InetPortNumber textual convention of the SMIv2."; 594 reference 595 "RFC 768: User Datagram Protocol 596 RFC 793: Transmission Control Protocol 597 RFC 2960: Stream Control Transmission Protocol 598 RFC 4340: Datagram Congestion Control Protocol (DCCP) 599 RFC 4001: Textual Conventions for Internet Network Addresses"; 600 } 602 /*** collection of autonomous system related types ***/ 604 typedef as-number { 605 type uint32; 606 description 607 "The as-number type represents autonomous system numbers 608 which identify an Autonomous System (AS). An AS is a set 609 of routers under a single technical administration, using 610 an interior gateway protocol and common metrics to route 611 packets within the AS, and using an exterior gateway 612 protocol to route packets to other ASs'. IANA maintains 613 the AS number space and has delegated large parts to the 614 regional registries. 616 Autonomous system numbers were originally limited to 16 617 bits. BGP extensions have enlarged the autonomous system 618 number space to 32 bits. This type therefore uses an uint32 619 base type without a range restriction in order to support 620 a larger autonomous system number space. 622 This type is in the value set and its semantics equivalent 623 to the InetAutonomousSystemNumber textual convention of 624 the SMIv2."; 625 reference 626 "RFC 1930: Guidelines for creation, selection, and registration 627 of an Autonomous System (AS) 628 RFC 4271: A Border Gateway Protocol 4 (BGP-4) 629 RFC 4893: BGP Support for Four-octet AS Number Space 630 RFC 4001: Textual Conventions for Internet Network Addresses"; 631 } 633 /*** collection of IP address and hostname related types ***/ 635 typedef ip-address { 636 type union { 637 type inet:ipv4-address; 638 type inet:ipv6-address; 639 } 640 description 641 "The ip-address type represents an IP address and is IP 642 version neutral. The format of the textual representations 643 implies the IP version."; 644 } 646 typedef ipv4-address { 647 type string { 648 pattern '((0' 649 + '|(1[0-9]{0,2})' 650 + '|(2(([0-4][0-9]?)|(5[0-5]?)|([6-9]?)))' 651 + '|([3-9][0-9]?)' 652 + ')' 653 + '\.){3}' 654 + '(0' 655 + '|(1[0-9]{0,2})' 656 + '|(2(([0-4][0-9]?)|(5[0-5]?)|([6-9]?)))' 657 + '|([3-9][0-9]?)' 658 + ')(%[\p{N}\p{L}]+)?'; 659 } 660 description 661 "The ipv4-address type represents an IPv4 address in 662 dotted-quad notation. The IPv4 address may include a zone 663 index, separated by a % sign. 665 The zone index is used to disambiguate identical address 666 values. For link-local addresses, the zone index will 667 typically be the interface index number or the name of an 668 interface. If the zone index is not present, the default 669 zone of the device will be used. 671 The canonical format for the zone index is the numerical 672 format"; 673 } 675 typedef ipv6-address { 676 type string { 677 pattern 678 /* full */ 679 '((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})' 680 + '(%[\p{N}\p{L}]+)?)' 681 /* mixed */ 682 + '|((([0-9a-fA-F]{1,4}:){6})(([0-9]{1,3}\.' 683 + '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))' 684 + '(%[\p{N}\p{L}]+)?)' 685 /* shortened */ 686 + '|((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)' 687 + '(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*' 688 + '(%[\p{N}\p{L}]+)?)' 689 /* shortened mixed */ 690 + '|((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)' 691 + '(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*' 692 + '(([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))' 693 + '(%[\p{N}\p{L}]+)?)'; 694 } 695 description 696 "The ipv6-address type represents an IPv6 address in full, 697 mixed, shortened and shortened mixed notation. The IPv6 698 address may include a zone index, separated by a % sign. 700 The zone index is used to disambiguate identical address 701 values. For link-local addresses, the zone index will 702 typically be the interface index number or the name of an 703 interface. If the zone index is not present, the default 704 zone of the device will be used. 706 The canonical format of IPv6 addresses must match the 707 pattern '((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})' 708 with leading zeros suppressed as described in RFC 4291 709 section 2.2 item 1. The canonical format for the zone 710 index is the numerical format as described in RFC 4007 711 section 11.2."; 712 reference 713 "RFC 4291: IP Version 6 Addressing Architecture 714 RFC 4007: IPv6 Scoped Address Architecture"; 715 } 717 // [TODO] The pattern needs to be checked; once YANG supports 718 // multiple pattern, we can perhaps be more precise. 720 typedef ip-prefix { 721 type union { 722 type inet:ipv4-prefix; 723 type inet:ipv6-prefix; 724 } 725 description 726 "The ip-prefix type represents an IP prefix and is IP 727 version neutral. The format of the textual representations 728 implies the IP version."; 729 } 731 typedef ipv4-prefix { 732 type string { 733 pattern '(([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])\.){3}' 734 + '([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])' 735 + '/\d+'; 736 } 737 description 738 "The ipv4-prefix type represents an IPv4 address prefix. 739 The prefix length is given by the number following the 740 slash character and must be less than or equal to 32. 742 A prefix length value of n corresponds to an IP address 743 mask which has n contiguous 1-bits from the most 744 significant bit (MSB) and all other bits set to 0. 746 The canonical format of an IPv4 prefix has all bits of 747 the IPv4 address set to zero that are not part of the 748 IPv4 prefix."; 749 } 751 typedef ipv6-prefix { 752 type string { 753 pattern 754 /* full */ 755 '((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})' 756 + '/\d+)' 757 /* mixed */ 758 + '|((([0-9a-fA-F]{1,4}:){6})(([0-9]{1,3}\.' 759 + '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))' 760 + '/\d+)' 761 /* shortened */ 762 + '|((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)' 763 + '(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*' 764 + '/\d+)' 765 /* shortened mixed */ 766 + '|((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)' 767 + '(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*' 768 + '(([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))' 769 + '/\d+)'; 770 } 771 description 772 "The ipv6-prefix type represents an IPv6 address prefix. 773 The prefix length is given by the number following the 774 slash character and must be less than or equal 128. 776 A prefix length value of n corresponds to an IP address 777 mask which has n contiguous 1-bits from the most 778 significant bit (MSB) and all other bits set to 0. 780 The IPv6 address should have all bits that do not belong 781 to the prefix set to zero. 783 The canonical format of an IPv6 prefix has all bits of 784 the IPv6 address set to zero that are not part of the 785 IPv6 prefix. Furthermore, the IPv6 address must match the 786 pattern '((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})' 787 with leading zeros suppressed as described in RFC 4291 788 section 2.2 item 1."; 789 reference 790 "RFC 4291: IP Version 6 Addressing Architecture"; 791 } 793 // [TODO] The pattern needs to be checked; once YANG supports 794 // multiple pattern, we can perhaps be more precise. 796 /*** collection of domain name and URI types ***/ 798 typedef domain-name { 799 type string { 800 pattern '([a-zA-Z0-9][a-zA-Z0-9\-]*[a-zA-Z0-9]\.)*' 801 + '[a-zA-Z0-9][a-zA-Z0-9\-]*[a-zA-Z0-9]'; 802 } 803 description 804 "The domain-name type represents a DNS domain name. The 805 name SHOULD be fully qualified whenever possible. 807 The description clause of objects using the domain-name 808 type MUST describe how (and when) these names are 809 resolved to IP addresses. 811 Note that the resolution of a domain-name value may 812 require to query multiple DNS records (e.g., A for IPv4 813 and AAAA for IPv6). The order of the resolution process 814 and which DNS record takes precedence depends on the 815 configuration of the resolver. 817 The canonical format for domain-name values uses the US-ASCII 818 encoding and case-insensitive characters are set to lowercase."; 819 reference 820 "RFC 1034: Domain Names - Concepts and Facilities 821 RFC 1123: Requirements for Internet Hosts -- Application 822 and Support"; 823 } 825 // [TODO] RFC 2181 says there are no restrictions on DNS 826 // labels. Need to check whether the pattern above is too 827 // restrictive. We probably need advice from DNS experts. 829 typedef host { 830 type union { 831 type inet:ip-address; 832 type inet:domain-name; 833 } 834 description 835 "The host type represents either an IP address or a DNS 836 domain name."; 837 } 839 typedef uri { 840 type string; // [TODO] add the regex from RFC 3986 here? 841 description 842 "The uri type represents a Uniform Resource Identifier 843 (URI) as defined by STD 66. 845 Objects using the uri type must be in US-ASCII encoding, 846 and MUST be normalized as described by RFC 3986 Sections 847 6.2.1, 6.2.2.1, and 6.2.2.2. All unnecessary 848 percent-encoding is removed, and all case-insensitive 849 characters are set to lowercase except for hexadecimal 850 digits, which are normalized to uppercase as described in 851 Section 6.2.2.1. 853 The purpose of this normalization is to help provide 854 unique URIs. Note that this normalization is not 855 sufficient to provide uniqueness. Two URIs that are 856 textually distinct after this normalization may still be 857 equivalent. 859 Objects using the uri type may restrict the schemes that 860 they permit. For example, 'data:' and 'urn:' schemes 861 might not be appropriate. 863 A zero-length URI is not a valid URI. This can be used to 864 express 'URI absent' where required 866 This type is in the value set and its semantics equivalent 867 to the Uri textual convention of the SMIv2."; 868 reference 869 "RFC 3986: Uniform Resource Identifier (URI): Generic Syntax 870 RFC 3305: Report from the Joint W3C/IETF URI Planning Interest 871 Group: Uniform Resource Identifiers (URIs), URLs, 872 and Uniform Resource Names (URNs): Clarifications 873 and Recommendations 874 RFC 5017: MIB Textual Conventions for Uniform Resource 875 Identifiers (URIs)"; 876 } 878 } 880 4. IEEE Specific Derived Types 882 module ietf-ieee-types { 884 namespace "urn:ietf:params:xml:ns:yang:ieee-types"; 885 prefix "ieee"; 887 organization 888 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 890 contact 891 "WG Web: 892 WG List: 894 WG Chair: David Partain 895 897 WG Chair: David Kessens 898 900 Editor: Juergen Schoenwaelder 901 "; 903 description 904 "This module contains a collection of generally useful derived 905 YANG data types for IEEE 802 addresses and related things. 907 Copyright (C) 2009 The IETF Trust and the persons identified as 908 the document authors. This version of this YANG module is part 909 of RFC XXXX; see the RFC itself for full legal notices."; 910 // RFC Ed.: replace XXXX with actual RFC number and remove this note 912 revision 2009-03-09 { 913 description 914 "Initial revision, published as RFC XXXX"; 915 } 916 // RFC Ed.: replace XXXX with actual RFC number and remove this note 918 /*** collection of IEEE address type definitions ***/ 920 typedef mac-address { 921 type string { 922 pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}'; 923 } 924 description 925 "The mac-address type represents an 802 MAC address represented 926 in the `canonical' order defined by IEEE 802.1a, i.e., as if it 927 were transmitted least significant bit first, even though 802.5 928 (in contrast to other 802.x protocols) requires MAC addresses 929 to be transmitted most significant bit first. 931 This type is in the value set and its semantics equivalent to 932 the MacAddress textual convention of the SMIv2."; 933 reference 934 "RFC 2579: Textual Conventions for SMIv2"; 935 } 937 /*** collection of IEEE 802 related identifier types ***/ 939 typedef bridgeid { 940 type string { 941 pattern '[0-9a-fA-F]{4}(:[0-9a-fA-F]{2}){6}'; 942 } 943 description 944 "The bridgeid type represents identifiers that uniquely 945 identify a bridge. Its first four hexadecimal digits 946 contain a priority value followed by a colon. The 947 remaining characters contain the MAC address used to 948 refer to a bridge in a unique fashion (typically, the 949 numerically smallest MAC address of all ports on the 950 bridge). 952 This type is in the value set and its semantics equivalent 953 to the BridgeId textual convention of the SMIv2. However, 954 since the BridgeId textual convention does not prescribe 955 a lexical representation, the appearance might be different."; 956 reference 957 "RFC 4188: Definitions of Managed Objects for Bridges"; 958 } 960 typedef vlanid { 961 type uint16 { 962 range "1..4094"; 963 } 964 description 965 "The vlanid type uniquely identifies a VLAN. This is the 966 12-bit VLAN-ID used in the VLAN Tag header. The range is 967 defined by the referenced specification. 969 This type is in the value set and its semantics equivalent to 970 the VlanId textual convention of the SMIv2."; 971 reference 972 "IEEE Std 802.1Q 2003 Edition: Virtual Bridged Local 973 Area Networks 974 RFC 4363: Definitions of Managed Objects for Bridges with 975 Traffic Classes, Multicast Filtering, and Virtual 976 LAN Extensions"; 977 } 979 } 981 5. IANA Considerations 983 A registry for standard YANG modules shall be set up. The name of 984 the registry is "IETF YANG Modules" and the registry shall record for 985 each entry the unique name of a YANG module, the assigned XML 986 namespace from the YANG URI Scheme, and a reference to the module's 987 documentation (typically and RFC). Allocations require IETF Review 988 as defined in [RFC5226]. The initial assignments are: 990 YANG Module XML namespace Reference 991 ----------- -------------------------------------- --------- 992 yang-types urn:ietf:params:xml:ns:yang:yang-types RFC XXXX 993 inet-types urn:ietf:params:xml:ns:yang:inet-types RFC XXXX 994 ieee-types urn:ietf:params:xml:ns:yang:ieee-types RFC XXXX 996 RFC Ed.: replace XXXX with actual RFC number and remove this note 998 This document registers three URIs in the IETF XML registry 999 [RFC3688]. Following the format in RFC 3688, the following 1000 registration is requested. 1002 URI: urn:ietf:params:xml:ns:yang:yang-types 1003 URI: urn:ietf:params:xml:ns:yang:inet-types 1004 URI: urn:ietf:params:xml:ns:yang:ieee-types 1006 Registrant Contact: The NETMOD WG of the IETF. 1008 XML: N/A, the requested URI is an XML namespace. 1010 6. Security Considerations 1012 This document defines common data types using the YANG data modeling 1013 language. The definitions themselves have no security impact on the 1014 Internet but the usage of these definitions in concrete YANG modules 1015 might have. The security considerations spelled out in the YANG 1016 specification [YANG] apply for this document as well. 1018 7. Contributors 1020 The following people all contributed significantly to the initial 1021 version of this draft: 1023 - Andy Bierman (andybierman.com) 1024 - Martin Bjorklund (Tail-f Systems) 1025 - Balazs Lengyel (Ericsson) 1026 - David Partain (Ericsson) 1027 - Phil Shafer (Juniper Networks) 1029 8. References 1031 8.1. Normative References 1033 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1034 Requirement Levels", BCP 14, RFC 2119, March 1997. 1036 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1037 January 2004. 1039 [YANG] Bjorklund, M., Ed., "YANG - A data modeling language for 1040 NETCONF", draft-ietf-netmod-yang-04 (work in progress). 1042 8.2. Informative References 1044 [802.1Q] ANSI/IEEE Standard 802.1Q, "IEEE Standards for Local and 1045 Metropolitan Area Networks: Virtual Bridged Local Area 1046 Networks", 2003. 1048 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1049 August 1980. 1051 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1052 September 1981. 1054 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1055 RFC 793, September 1981. 1057 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1058 STD 13, RFC 1034, November 1987. 1060 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 1061 and Support", STD 3, RFC 1123, October 1989. 1063 [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, 1064 selection, and registration of an Autonomous System (AS)", 1065 BCP 6, RFC 1930, March 1996. 1067 [RFC2021] Waldbusser, S., "Remote Network Monitoring Management 1068 Information Base Version 2 using SMIv2", RFC 2021, 1069 January 1997. 1071 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1072 (IPv6) Specification", RFC 2460, December 1998. 1074 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1075 "Definition of the Differentiated Services Field (DS 1076 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1077 December 1998. 1079 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1080 Schoenwaelder, Ed., "Structure of Management Information 1081 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 1083 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1084 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 1085 STD 58, RFC 2579, April 1999. 1087 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 1088 Values In the Internet Protocol and Related Headers", 1089 BCP 37, RFC 2780, March 2000. 1091 [RFC2856] Bierman, A., McCloghrie, K., and R. Presuhn, "Textual 1092 Conventions for Additional High Capacity Data Types", 1093 RFC 2856, June 2000. 1095 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 1096 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 1097 Zhang, L., and V. Paxson, "Stream Control Transmission 1098 Protocol", RFC 2960, October 2000. 1100 [RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information 1101 Base for the Differentiated Services Architecture", 1102 RFC 3289, May 2002. 1104 [RFC3305] Mealling, M. and R. Denenberg, "Report from the Joint W3C/ 1105 IETF URI Planning Interest Group: Uniform Resource 1106 Identifiers (URIs), URLs, and Uniform Resource Names 1107 (URNs): Clarifications and Recommendations", RFC 3305, 1108 August 2002. 1110 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 1111 Internet: Timestamps", RFC 3339, July 2002. 1113 [RFC3595] Wijnen, B., "Textual Conventions for IPv6 Flow Label", 1114 RFC 3595, September 2003. 1116 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1117 Resource Identifier (URI): Generic Syntax", STD 66, 1118 RFC 3986, January 2005. 1120 [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. 1121 Schoenwaelder, "Textual Conventions for Internet Network 1122 Addresses", RFC 4001, February 2005. 1124 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 1125 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 1126 March 2005. 1128 [RFC4188] Norseth, K. and E. Bell, "Definitions of Managed Objects 1129 for Bridges", RFC 4188, September 2005. 1131 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1132 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1134 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1135 Architecture", RFC 4291, February 2006. 1137 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1138 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 1140 [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, 1141 December 2006. 1143 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 1144 Number Space", RFC 4893, May 2007. 1146 [RFC5017] McWalter, D., "MIB Textual Conventions for Uniform 1147 Resource Identifiers (URIs)", RFC 5017, September 2007. 1149 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1150 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1151 May 2008. 1153 Appendix A. XSD Translations 1155 This appendix provides XML Schema (XSD) translations of the types 1156 defined in this document. This appendix is informative and not 1157 normative. 1159 A.1. XSD of Core YANG Derived Types 1161 1162 1171 1172 1173 This module contains a collection of generally useful derived 1174 YANG data types. 1176 Copyright (C) 2009 The IETF Trust and the persons identified as 1177 the document authors. This version of this YANG module is part 1178 of RFC XXXX; see the RFC itself for full legal notices. 1179 1180 1182 1184 1185 1186 1187 The counter32 type represents a non-negative integer 1188 which monotonically increases until it reaches a 1189 maximum value of 2^32-1 (4294967295 decimal), when it 1190 wraps around and starts increasing again from zero. 1192 Counters have no defined `initial' value, and thus, a 1193 single value of a counter has (in general) no information 1194 content. Discontinuities in the monotonically increasing 1195 value normally occur at re-initialization of the 1196 management system, and at other times as specified in the 1197 description of an object instance using this type. If 1198 such other times can occur, for example, the creation of 1199 an object instance of type counter32 at times other than 1200 re-initialization, then a corresponding object should be 1201 defined, with an appropriate type, to indicate the last 1202 discontinuity. 1204 The counter32 type should not be used for configuration 1205 objects. A default statement should not be used for 1206 attributes with a type value of counter32. 1208 This type is in the value set and its semantics equivalent 1209 to the Counter32 type of the SMIv2. 1210 1211 1213 1214 1215 1217 1218 1219 1220 The zero-based-counter32 type represents a counter32 1221 which has the defined `initial' value zero. 1223 Objects of this type will be set to zero(0) on creation 1224 and will thereafter count appropriate events, wrapping 1225 back to zero(0) when the value 2^32 is reached. 1227 Provided that an application discovers the new object within 1228 the minimum time to wrap it can use the initial value as a 1229 delta since it last polled the table of which this object is 1230 part. It is important for a management station to be aware 1231 of this minimum time and the actual time between polls, and 1232 to discard data if the actual time is too long or there is 1233 no defined minimum time. 1235 This type is in the value set and its semantics equivalent 1236 to the ZeroBasedCounter32 textual convention of the SMIv2. 1237 1238 1240 1241 1242 1244 1245 1246 1247 The counter64 type represents a non-negative integer 1248 which monotonically increases until it reaches a 1249 maximum value of 2^64-1 (18446744073709551615), when 1250 it wraps around and starts increasing again from zero. 1252 Counters have no defined `initial' value, and thus, a 1253 single value of a counter has (in general) no information 1254 content. Discontinuities in the monotonically increasing 1255 value normally occur at re-initialization of the 1256 management system, and at other times as specified in the 1257 description of an object instance using this type. If 1258 such other times can occur, for example, the creation of 1259 an object instance of type counter64 at times other than 1260 re-initialization, then a corresponding object should be 1261 defined, with an appropriate type, to indicate the last 1262 discontinuity. 1264 The counter64 type should not be used for configuration 1265 objects. A default statement should not be used for 1266 attributes with a type value of counter64. 1268 This type is in the value set and its semantics equivalent 1269 to the Counter64 type of the SMIv2. 1270 1271 1273 1274 1275 1277 1278 1279 1280 The zero-based-counter64 type represents a counter64 which 1281 has the defined `initial' value zero. 1283 Objects of this type will be set to zero(0) on creation 1284 and will thereafter count appropriate events, wrapping 1285 back to zero(0) when the value 2^64 is reached. 1287 Provided that an application discovers the new object within 1288 the minimum time to wrap it can use the initial value as a 1289 delta since it last polled the table of which this object is 1290 part. It is important for a management station to be aware 1291 of this minimum time and the actual time between polls, and 1292 to discard data if the actual time is too long or there is 1293 no defined minimum time. 1295 This type is in the value set and its semantics equivalent 1296 to the ZeroBasedCounter64 textual convention of the SMIv2. 1298 1299 1301 1302 1303 1305 1306 1307 1308 The gauge32 type represents a non-negative integer, which 1309 may increase or decrease, but shall never exceed a maximum 1310 value, nor fall below a minimum value. The maximum value 1311 can not be greater than 2^32-1 (4294967295 decimal), and 1312 the minimum value can not be smaller than 0. The value of 1313 a gauge32 has its maximum value whenever the information 1314 being modeled is greater than or equal to its maximum 1315 value, and has its minimum value whenever the information 1316 being modeled is smaller than or equal to its minimum value. 1317 If the information being modeled subsequently decreases 1318 below (increases above) the maximum (minimum) value, the 1319 gauge32 also decreases (increases). 1321 This type is in the value set and its semantics equivalent 1322 to the Counter32 type of the SMIv2. 1323 1324 1326 1327 1328 1330 1331 1332 1333 The gauge64 type represents a non-negative integer, which 1334 may increase or decrease, but shall never exceed a maximum 1335 value, nor fall below a minimum value. The maximum value 1336 can not be greater than 2^64-1 (18446744073709551615), and 1337 the minimum value can not be smaller than 0. The value of 1338 a gauge64 has its maximum value whenever the information 1339 being modeled is greater than or equal to its maximum 1340 value, and has its minimum value whenever the information 1341 being modeled is smaller than or equal to its minimum value. 1342 If the information being modeled subsequently decreases 1343 below (increases above) the maximum (minimum) value, the 1344 gauge64 also decreases (increases). 1346 This type is in the value set and its semantics equivalent 1347 to the CounterBasedGauge64 SMIv2 textual convention defined 1348 in RFC 2856 1349 1350 1352 1353 1354 1356 1357 1358 1359 The object-identifier type represents administratively 1360 assigned names in a registration-hierarchical-name tree. 1362 Values of this type are denoted as a sequence of numerical 1363 non-negative sub-identifier values. Each sub-identifier 1364 value MUST NOT exceed 2^32-1 (4294967295). Sub-identifiers 1365 are separated by single dots and without any intermediate 1366 white space. 1368 Although the number of sub-identifiers is not limited, 1369 module designers should realize that there may be 1370 implementations that stick with the SMIv2 limit of 128 1371 sub-identifiers. 1373 This type is a superset of the SMIv2 OBJECT IDENTIFIER type 1374 since it is not restricted to 128 sub-identifiers. 1375 1376 1378 1379 1381 1382 1384 1385 1386 1387 This type represents object-identifiers restricted to 128 1388 sub-identifiers. 1390 This type is in the value set and its semantics equivalent 1391 to the OBJECT IDENTIFIER type of the SMIv2. 1392 1393 1394 1395 1396 1397 1399 1400 1401 1402 The date-and-time type is a profile of the ISO 8601 1403 standard for representation of dates and times using the 1404 Gregorian calendar. The format is most easily described 1405 using the following ABFN (see RFC 3339): 1407 date-fullyear = 4DIGIT 1408 date-month = 2DIGIT ; 01-12 1409 date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 1410 time-hour = 2DIGIT ; 00-23 1411 time-minute = 2DIGIT ; 00-59 1412 time-second = 2DIGIT ; 00-58, 00-59, 00-60 1413 time-secfrac = "." 1*DIGIT 1414 time-numoffset = ("+" / "-") time-hour ":" time-minute 1415 time-offset = "Z" / time-numoffset 1417 partial-time = time-hour ":" time-minute ":" time-second 1418 [time-secfrac] 1419 full-date = date-fullyear "-" date-month "-" date-mday 1420 full-time = partial-time time-offset 1422 date-time = full-date "T" full-time 1424 The date-and-time type is consistent with the semantics defined 1425 in RFC 3339. The data-and-time type is compatible with the 1426 dateTime XML schema type with the following two notable 1427 exceptions: 1429 (a) The data-and-time type does not allow negative years. 1431 (b) The data-and-time time-offset -00:00 indicates an unknown 1432 time zone (see RFC 3339) while -00:00 and +00:00 and Z all 1433 represent the same time zone in dateTime. 1435 This type is not equivalent to the DateAndTime textual 1436 convention of the SMIv2 since RFC 3339 uses a different 1437 separator between full-date and full-time and provides 1438 higher resolution of time-secfrac. 1440 The canonical format for date-and-time values mandates the UTC 1441 time format with the time-offset is indicated by the letter "Z". 1443 This is consistent with the canonical format used by the 1444 dateTime XML schema type. 1445 1446 1448 1449 1451 1452 1454 1455 1456 1457 The timeticks type represents a non-negative integer which 1458 represents the time, modulo 2^32 (4294967296 decimal), in 1459 hundredths of a second between two epochs. When objects 1460 are defined which use this type, the description of the 1461 object identifies both of the reference epochs. 1463 This type is in the value set and its semantics equivalent 1464 to the TimeTicks type of the SMIv2. 1465 1466 1468 1469 1470 1472 1473 1474 1475 The timestamp type represents the value of an associated 1476 timeticks object at which a specific occurrence happened. 1477 The specific occurrence must be defined in the description 1478 of any object defined using this type. When the specific 1479 occurrence occurred prior to the last time the associated 1480 timeticks attribute was zero, then the timestamp value is 1481 zero. Note that this requires all timestamp values to be 1482 reset to zero when the value of the associated timeticks 1483 attribute reaches 497+ days and wraps around to zero. 1485 The associated timeticks object must be specified 1486 in the description of any object using this type. 1488 This type is in the value set and its semantics equivalent 1489 to the TimeStamp textual convention of the SMIv2. 1490 1492 1494 1495 1496 1498 1499 1500 1501 Represents media- or physical-level addresses represented 1502 as a sequence octets, each octet represented by two hexadecimal 1503 numbers. Octets are separated by colons. 1505 This type is in the value set and its semantics equivalent 1506 to the PhysAddress textual convention of the SMIv2. 1507 1508 1510 1511 1512 1513 1515 1516 1517 1518 This type represents an XPATH 1.0 expression. 1519 1520 1522 1523 1524 1526 1528 A.2. XSD of Internet Specific Derived Types 1530 1531 1540 1541 1542 This module contains a collection of generally useful derived 1543 YANG data types for Internet addresses and related things. 1545 Copyright (C) 2009 The IETF Trust and the persons identified as 1546 the document authors. This version of this YANG module is part 1547 of RFC XXXX; see the RFC itself for full legal notices. 1548 1549 1551 1553 1554 1555 1556 This value represents the version of the IP protocol. 1558 This type is in the value set and its semantics equivalent 1559 to the InetVersion textual convention of the SMIv2. However, 1560 the lexical appearance is different from the InetVersion 1561 textual convention. 1562 1563 1565 1566 1567 1568 1569 1570 1572 1573 1574 1575 The dscp type represents a Differentiated Services Code-Point 1576 that may be used for marking packets in a traffic stream. 1578 This type is in the value set and its semantics equivalent 1579 to the Dscp textual convention of the SMIv2. 1580 1581 1583 1584 1585 1586 1587 1588 1589 1590 1591 The flow-label type represents flow identifier or Flow Label 1592 in an IPv6 packet header that may be used to discriminate 1593 traffic flows. 1595 This type is in the value set and its semantics equivalent 1596 to the IPv6FlowLabel textual convention of the SMIv2. 1597 1598 1600 1601 1602 1603 1604 1606 1607 1608 1609 The port-number type represents a 16-bit port number of an 1610 Internet transport layer protocol such as UDP, TCP, DCCP or 1611 SCTP. Port numbers are assigned by IANA. A current list of 1612 all assignments is available from <http://www.iana.org/>. 1614 Note that the value zero is not a valid port number. A union 1615 type might be used in situations where the value zero is 1616 meaningful. 1618 This type is in the value set and its semantics equivalent 1619 to the InetPortNumber textual convention of the SMIv2. 1620 1621 1623 1624 1625 1626 1627 1629 1630 1631 1632 The as-number type represents autonomous system numbers 1633 which identify an Autonomous System (AS). An AS is a set 1634 of routers under a single technical administration, using 1635 an interior gateway protocol and common metrics to route 1636 packets within the AS, and using an exterior gateway 1637 protocol to route packets to other ASs'. IANA maintains 1638 the AS number space and has delegated large parts to the 1639 regional registries. 1641 Autonomous system numbers were originally limited to 16 1642 bits. BGP extensions have enlarged the autonomous system 1643 number space to 32 bits. This type therefore uses an uint32 1644 base type without a range restriction in order to support 1645 a larger autonomous system number space. 1647 This type is in the value set and its semantics equivalent 1648 to the InetAutonomousSystemNumber textual convention of 1649 the SMIv2. 1650 1651 1653 1654 1655 1657 1658 1659 1660 The ip-address type represents an IP address and is IP 1661 version neutral. The format of the textual representations 1662 implies the IP version. 1663 1664 1666 1667 1668 1669 1670 1671 1672 1673 1674 1675 1676 1678 1679 1680 1681 The ipv4-address type represents an IPv4 address in 1682 dotted-quad notation. The IPv4 address may include a zone 1683 index, separated by a % sign. 1685 The zone index is used to disambiguate identical address 1686 values. For link-local addresses, the zone index will 1687 typically be the interface index number or the name of an 1688 interface. If the zone index is not present, the default 1689 zone of the device will be used. 1691 The canonical format for the zone index is the numerical 1692 format 1693 1694 1696 1697 1701 1702 1704 1705 1706 1707 The ipv6-address type represents an IPv6 address in full, 1708 mixed, shortened and shortened mixed notation. The IPv6 1709 address may include a zone index, separated by a % sign. 1711 The zone index is used to disambiguate identical address 1712 values. For link-local addresses, the zone index will 1713 typically be the interface index number or the name of an 1714 interface. If the zone index is not present, the default 1715 zone of the device will be used. 1717 The canonical format of IPv6 addresses must match the 1718 pattern '((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})' 1719 with leading zeros suppressed as described in RFC 4291 1720 section 2.2 item 1. The canonical format for the zone 1721 index is the numerical format as described in RFC 4007 1722 section 11.2. 1723 1724 1726 1727 1737 1738 1740 1741 1742 1743 The ip-prefix type represents an IP prefix and is IP 1744 version neutral. The format of the textual representations 1745 implies the IP version. 1746 1747 1749 1750 1751 1752 1753 1754 1755 1756 1757 1758 1759 1761 1762 1763 1764 The ipv4-prefix type represents an IPv4 address prefix. 1765 The prefix length is given by the number following the 1766 slash character and must be less than or equal to 32. 1768 A prefix length value of n corresponds to an IP address 1769 mask which has n contiguous 1-bits from the most 1770 significant bit (MSB) and all other bits set to 0. 1772 The canonical format of an IPv4 prefix has all bits of 1773 the IPv4 address set to zero that are not part of the 1774 IPv4 prefix. 1775 1776 1778 1779 1782 1783 1785 1786 1787 1788 The ipv6-prefix type represents an IPv6 address prefix. 1789 The prefix length is given by the number following the 1790 slash character and must be less than or equal 128. 1792 A prefix length value of n corresponds to an IP address 1793 mask which has n contiguous 1-bits from the most 1794 significant bit (MSB) and all other bits set to 0. 1796 The IPv6 address should have all bits that do not belong 1797 to the prefix set to zero. 1799 The canonical format of an IPv6 prefix has all bits of 1800 the IPv6 address set to zero that are not part of the 1801 IPv6 prefix. Furthermore, the IPv6 address must match the 1802 pattern '((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})' 1803 with leading zeros suppressed as described in RFC 4291 1804 section 2.2 item 1. 1805 1806 1808 1809 1818 1819 1821 1822 1823 1824 The domain-name type represents a DNS domain name. The 1825 name SHOULD be fully qualified whenever possible. 1827 The description clause of objects using the domain-name 1828 type MUST describe how (and when) these names are 1829 resolved to IP addresses. 1831 Note that the resolution of a domain-name value may 1832 require to query multiple DNS records (e.g., A for IPv4 1833 and AAAA for IPv6). The order of the resolution process 1834 and which DNS record takes precedence depends on the 1835 configuration of the resolver. 1837 The canonical format for domain-name values uses the US-ASCII 1838 encoding and case-insensitive characters are set to lowercase. 1839 1840 1842 1843 1845 1846 1848 1849 1850 1851 The host type represents either an IP address or a DNS 1852 domain name. 1853 1854 1856 1857 1858 1859 1860 1861 1862 1863 1864 1865 1866 1868 1869 1870 1871 The uri type represents a Uniform Resource Identifier 1872 (URI) as defined by STD 66. 1874 Objects using the uri type must be in US-ASCII encoding, 1875 and MUST be normalized as described by RFC 3986 Sections 1876 6.2.1, 6.2.2.1, and 6.2.2.2. All unnecessary 1877 percent-encoding is removed, and all case-insensitive 1878 characters are set to lowercase except for hexadecimal 1879 digits, which are normalized to uppercase as described in 1880 Section 6.2.2.1. 1882 The purpose of this normalization is to help provide 1883 unique URIs. Note that this normalization is not 1884 sufficient to provide uniqueness. Two URIs that are 1885 textually distinct after this normalization may still be 1886 equivalent. 1888 Objects using the uri type may restrict the schemes that 1889 they permit. For example, 'data:' and 'urn:' schemes 1890 might not be appropriate. 1892 A zero-length URI is not a valid URI. This can be used to 1893 express 'URI absent' where required 1895 This type is in the value set and its semantics equivalent 1896 to the Uri textual convention of the SMIv2. 1897 1898 1900 1901 1902 1904 1906 A.3. XSD of IEEE Specific Derived Types 1908 1909 1918 1919 1920 This module contains a collection of generally useful derived 1921 YANG data types for IEEE 802 addresses and related things. 1923 Copyright (C) 2009 The IETF Trust and the persons identified as 1924 the document authors. This version of this YANG module is part 1925 of RFC XXXX; see the RFC itself for full legal notices. 1926 1927 1929 1931 1932 1933 1934 The mac-address type represents an 802 MAC address represented 1935 in the `canonical' order defined by IEEE 802.1a, i.e., as if it 1936 were transmitted least significant bit first, even though 802.5 1937 (in contrast to other 802.x protocols) requires MAC addresses 1938 to be transmitted most significant bit first. 1940 This type is in the value set and its semantics equivalent to 1941 the MacAddress textual convention of the SMIv2. 1942 1943 1945 1946 1947 1948 1950 1951 1952 1953 The bridgeid type represents identifiers that uniquely 1954 identify a bridge. Its first four hexadecimal digits 1955 contain a priority value followed by a colon. The 1956 remaining characters contain the MAC address used to 1957 refer to a bridge in a unique fashion (typically, the 1958 numerically smallest MAC address of all ports on the 1959 bridge). 1961 This type is in the value set and its semantics equivalent 1962 to the BridgeId textual convention of the SMIv2. However, 1963 since the BridgeId textual convention does not prescribe 1964 a lexical representation, the appearance might be different. 1965 1966 1968 1969 1970 1971 1972 1973 1974 1975 The vlanid type uniquely identifies a VLAN. This is the 1976 12-bit VLAN-ID used in the VLAN Tag header. The range is 1977 defined by the referenced specification. 1979 This type is in the value set and its semantics equivalent to 1980 the VlanId textual convention of the SMIv2. 1981 1982 1984 1985 1986 1987 1988 1990 1992 Appendix B. RelaxNG Translations 1994 This appendix provides RelaxNG translations of the types defined in 1995 this document. This appendix is informative and not normative. 1997 B.1. RelaxNG of Core YANG Derived Types 1999 namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" 2000 namespace dc = "http://purl.org/dc/terms" 2001 namespace dsrl = "http://purl.oclc.org/dsdl/dsrl" 2002 namespace nm = "urn:ietf:params:xml:ns:netmod:dsdl-attrib:1" 2003 namespace sch = "http://purl.oclc.org/dsdl/schematron" 2004 namespace yang = "urn:ietf:params:xml:ns:yang:yang-types" 2006 dc:creator [ 2007 "IETF NETMOD (NETCONF Data Modeling Language) Working Group" 2008 ] 2009 dc:description [ 2010 "This module contains a collection of generally useful derived\x{a}" ~ 2011 "YANG data types.\x{a}" ~ 2012 "\x{a}" ~ 2013 "Copyright (C) 2009 The IETF Trust and the persons identif" 2014 ~ "ied as\x{a}" ~ 2015 "the document authors. This version of this YANG module i" 2016 ~ "s part\x{a}" ~ 2017 "of RFC XXXX; see the RFC itself for full legal notices." 2018 ] 2019 dc:issued [ "2009-03-09" ] 2020 dc:source [ "YANG module 'ietf-yang-types' (automatic translation)" ] 2021 dc:contributor [ 2022 "WG Web: \x{a}" ~ 2023 "WG List: \x{a}" ~ 2024 "\x{a}" ~ 2025 "WG Chair: David Partain\x{a}" ~ 2026 " \x{a}" ~ 2027 "\x{a}" ~ 2028 "WG Chair: David Kessens\x{a}" ~ 2029 " \x{a}" ~ 2030 "\x{a}" ~ 2031 "Editor: Juergen Schoenwaelder\x{a}" ~ 2032 " " 2033 ] 2035 ## The counter32 type represents a non-negative integer 2036 ## which monotonically increases until it reaches a 2037 ## maximum value of 2^32-1 (4294967295 decimal), when it 2038 ## wraps around and starts increasing again from zero. 2039 ## 2040 ## Counters have no defined `initial' value, and thus, a 2041 ## single value of a counter has (in general) no information 2042 ## content. Discontinuities in the monotonically increasing 2043 ## value normally occur at re-initialization of the 2044 ## management system, and at other times as specified in the 2045 ## description of an object instance using this type. If 2046 ## such other times can occur, for example, the creation of 2047 ## an object instance of type counter32 at times other than 2048 ## re-initialization, then a corresponding object should be 2049 ## defined, with an appropriate type, to indicate the last 2050 ## discontinuity. 2051 ## 2052 ## The counter32 type should not be used for configuration 2053 ## objects. A default statement should not be used for 2054 ## attributes with a type value of counter32. 2055 ## 2056 ## This type is in the value set and its semantics equivalent 2057 ## to the Counter32 type of the SMIv2. 2059 ## See: RFC 2578: Structure of Management Information Version 2 (SMIv2) 2060 counter32 = xsd:unsignedInt 2062 ## The zero-based-counter32 type represents a counter32 2063 ## which has the defined `initial' value zero. 2064 ## 2065 ## Objects of this type will be set to zero(0) on creation 2066 ## and will thereafter count appropriate events, wrapping 2067 ## back to zero(0) when the value 2^32 is reached. 2068 ## 2069 ## Provided that an application discovers the new object within 2070 ## the minimum time to wrap it can use the initial value as a 2071 ## delta since it last polled the table of which this object is 2072 ## part. It is important for a management station to be aware 2073 ## of this minimum time and the actual time between polls, and 2074 ## to discard data if the actual time is too long or there is 2075 ## no defined minimum time. 2076 ## 2077 ## This type is in the value set and its semantics equivalent 2078 ## to the ZeroBasedCounter32 textual convention of the SMIv2. 2080 ## See: RFC 2021: Remote Network Monitoring Management Information 2081 ## Base Version 2 using SMIv2 2082 zero-based-counter32 = counter32 >> dsrl:default-content [ "0" ] 2084 ## The counter64 type represents a non-negative integer 2085 ## which monotonically increases until it reaches a 2086 ## maximum value of 2^64-1 (18446744073709551615), when 2087 ## it wraps around and starts increasing again from zero. 2089 ## 2090 ## Counters have no defined `initial' value, and thus, a 2091 ## single value of a counter has (in general) no information 2092 ## content. Discontinuities in the monotonically increasing 2093 ## value normally occur at re-initialization of the 2094 ## management system, and at other times as specified in the 2095 ## description of an object instance using this type. If 2096 ## such other times can occur, for example, the creation of 2097 ## an object instance of type counter64 at times other than 2098 ## re-initialization, then a corresponding object should be 2099 ## defined, with an appropriate type, to indicate the last 2100 ## discontinuity. 2101 ## 2102 ## The counter64 type should not be used for configuration 2103 ## objects. A default statement should not be used for 2104 ## attributes with a type value of counter64. 2105 ## 2106 ## This type is in the value set and its semantics equivalent 2107 ## to the Counter64 type of the SMIv2. 2109 ## See: RFC 2578: Structure of Management Information Version 2 (SMIv2) 2110 counter64 = xsd:unsignedLong 2112 ## The zero-based-counter64 type represents a counter64 which 2113 ## has the defined `initial' value zero. 2114 ## 2115 ## Objects of this type will be set to zero(0) on creation 2116 ## and will thereafter count appropriate events, wrapping 2117 ## back to zero(0) when the value 2^64 is reached. 2118 ## 2119 ## Provided that an application discovers the new object within 2120 ## the minimum time to wrap it can use the initial value as a 2121 ## delta since it last polled the table of which this object is 2122 ## part. It is important for a management station to be aware 2123 ## of this minimum time and the actual time between polls, and 2124 ## to discard data if the actual time is too long or there is 2125 ## no defined minimum time. 2126 ## 2127 ## This type is in the value set and its semantics equivalent 2128 ## to the ZeroBasedCounter64 textual convention of the SMIv2. 2130 ## See: RFC 2856: Textual Conventions for Additional High Capacity 2131 ## Data Types 2132 zero-based-counter64 = counter64 >> dsrl:default-content [ "0" ] 2134 ## The gauge32 type represents a non-negative integer, which 2135 ## may increase or decrease, but shall never exceed a maximum 2136 ## value, nor fall below a minimum value. The maximum value 2137 ## can not be greater than 2^32-1 (4294967295 decimal), and 2138 ## the minimum value can not be smaller than 0. The value of 2139 ## a gauge32 has its maximum value whenever the information 2140 ## being modeled is greater than or equal to its maximum 2141 ## value, and has its minimum value whenever the information 2142 ## being modeled is smaller than or equal to its minimum value. 2143 ## If the information being modeled subsequently decreases 2144 ## below (increases above) the maximum (minimum) value, the 2145 ## gauge32 also decreases (increases). 2146 ## 2147 ## This type is in the value set and its semantics equivalent 2148 ## to the Counter32 type of the SMIv2. 2150 ## See: RFC 2578: Structure of Management Information Version 2 (SMIv2) 2151 gauge32 = xsd:unsignedInt 2153 ## The gauge64 type represents a non-negative integer, which 2154 ## may increase or decrease, but shall never exceed a maximum 2155 ## value, nor fall below a minimum value. The maximum value 2156 ## can not be greater than 2^64-1 (18446744073709551615), and 2157 ## the minimum value can not be smaller than 0. The value of 2158 ## a gauge64 has its maximum value whenever the information 2159 ## being modeled is greater than or equal to its maximum 2160 ## value, and has its minimum value whenever the information 2161 ## being modeled is smaller than or equal to its minimum value. 2162 ## If the information being modeled subsequently decreases 2163 ## below (increases above) the maximum (minimum) value, the 2164 ## gauge64 also decreases (increases). 2165 ## 2166 ## This type is in the value set and its semantics equivalent 2167 ## to the CounterBasedGauge64 SMIv2 textual convention defined 2168 ## in RFC 2856 2170 ## See: RFC 2856: Textual Conventions for Additional High Capacity 2171 ## Data Types 2172 gauge64 = xsd:unsignedLong 2174 ## The object-identifier type represents administratively 2175 ## assigned names in a registration-hierarchical-name tree. 2176 ## 2177 ## Values of this type are denoted as a sequence of numerical 2178 ## non-negative sub-identifier values. Each sub-identifier 2179 ## value MUST NOT exceed 2^32-1 (4294967295). Sub-identifiers 2180 ## are separated by single dots and without any intermediate 2181 ## white space. 2182 ## 2183 ## Although the number of sub-identifiers is not limited, 2184 ## module designers should realize that there may be 2185 ## implementations that stick with the SMIv2 limit of 128 2186 ## sub-identifiers. 2187 ## 2188 ## This type is a superset of the SMIv2 OBJECT IDENTIFIER type 2189 ## since it is not restricted to 128 sub-identifiers. 2191 ## See: ISO/IEC 9834-1: Information technology -- Open Systems 2192 ## Interconnection -- Procedures for the operation of OSI 2193 ## Registration Authorities: General procedures and top 2194 ## arcs of the ASN.1 Object Identifier tree 2195 object-identifier = 2196 xsd:string { 2197 pattern = 2198 "(([0-1](\.[1-3]?[0-9]))|(2\.(0|([1-9]\d*))))(\.(0|([1-9]\d*)))*" 2199 } 2201 ## This type represents object-identifiers restricted to 128 2202 ## sub-identifiers. 2203 ## 2204 ## This type is in the value set and its semantics equivalent 2205 ## to the OBJECT IDENTIFIER type of the SMIv2. 2207 ## See: RFC 2578: Structure of Management Information Version 2 (SMIv2) 2208 object-identifier-128 = object-identifier 2210 ## The date-and-time type is a profile of the ISO 8601 2211 ## standard for representation of dates and times using the 2212 ## Gregorian calendar. The format is most easily described 2213 ## using the following ABFN (see RFC 3339): 2214 ## 2215 ## date-fullyear = 4DIGIT 2216 ## date-month = 2DIGIT ; 01-12 2217 ## date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 2218 ## time-hour = 2DIGIT ; 00-23 2219 ## time-minute = 2DIGIT ; 00-59 2220 ## time-second = 2DIGIT ; 00-58, 00-59, 00-60 2221 ## time-secfrac = "." 1*DIGIT 2222 ## time-numoffset = ("+" / "-") time-hour ":" time-minute 2223 ## time-offset = "Z" / time-numoffset 2224 ## 2225 ## partial-time = time-hour ":" time-minute ":" time-second 2226 ## [time-secfrac] 2227 ## full-date = date-fullyear "-" date-month "-" date-mday 2228 ## full-time = partial-time time-offset 2229 ## 2230 ## date-time = full-date "T" full-time 2231 ## 2232 ## The date-and-time type is consistent with the semantics defined 2233 ## in RFC 3339. The data-and-time type is compatible with the 2234 ## dateTime XML schema type with the following two notable 2235 ## exceptions: 2236 ## 2237 ## (a) The data-and-time type does not allow negative years. 2238 ## 2239 ## (b) The data-and-time time-offset -00:00 indicates an unknown 2240 ## time zone (see RFC 3339) while -00:00 and +00:00 and Z all 2241 ## represent the same time zone in dateTime. 2242 ## 2243 ## This type is not equivalent to the DateAndTime textual 2244 ## convention of the SMIv2 since RFC 3339 uses a different 2245 ## separator between full-date and full-time and provides 2246 ## higher resolution of time-secfrac. 2247 ## 2248 ## The canonical format for date-and-time values mandates the UTC 2249 ## time format with the time-offset is indicated by the letter "Z". 2250 ## This is consistent with the canonical format used by the 2251 ## dateTime XML schema type. 2253 ## See: RFC 3339: Date and Time on the Internet: Timestamps 2254 ## RFC 2579: Textual Conventions for SMIv2 2255 ## W3C REC-xmlschema-2-20041028: XML Schema Part 2: Datatypes 2256 ## Second Edition 2257 date-and-time = 2258 xsd:string { 2259 pattern = 2260 "\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?(Z|(\+|-)\d{2}:\d{2})" 2261 } 2263 ## The timeticks type represents a non-negative integer which 2264 ## represents the time, modulo 2^32 (4294967296 decimal), in 2265 ## hundredths of a second between two epochs. When objects 2266 ## are defined which use this type, the description of the 2267 ## object identifies both of the reference epochs. 2268 ## 2269 ## This type is in the value set and its semantics equivalent 2270 ## to the TimeTicks type of the SMIv2. 2272 ## See: RFC 2578: Structure of Management Information Version 2 (SMIv2) 2273 timeticks = xsd:unsignedInt 2275 ## The timestamp type represents the value of an associated 2276 ## timeticks object at which a specific occurrence happened. 2277 ## The specific occurrence must be defined in the description 2278 ## of any object defined using this type. When the specific 2279 ## occurrence occurred prior to the last time the associated 2280 ## timeticks attribute was zero, then the timestamp value is 2281 ## zero. Note that this requires all timestamp values to be 2282 ## reset to zero when the value of the associated timeticks 2283 ## attribute reaches 497+ days and wraps around to zero. 2284 ## 2285 ## The associated timeticks object must be specified 2286 ## in the description of any object using this type. 2287 ## 2288 ## This type is in the value set and its semantics equivalent 2289 ## to the TimeStamp textual convention of the SMIv2. 2291 ## See: RFC 2579: Textual Conventions for SMIv2 2292 timestamp = timeticks 2294 ## Represents media- or physical-level addresses represented 2295 ## as a sequence octets, each octet represented by two hexadecimal 2296 ## numbers. Octets are separated by colons. 2297 ## 2298 ## This type is in the value set and its semantics equivalent 2299 ## to the PhysAddress textual convention of the SMIv2. 2301 ## See: RFC 2579: Textual Conventions for SMIv2 2302 phys-address = 2303 xsd:string { pattern = "([0-9a0-fA-F]{2}(:[0-9a0-fA-F]{2})*)?" } 2305 ## This type represents an XPATH 1.0 expression. 2307 ## See: W3C REC-xpath-19991116: XML Path Language (XPath) Version 1.0 2308 xpath = xsd:string 2310 B.2. RelaxNG of Internet Specific Derived Types 2312 namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" 2313 namespace dc = "http://purl.org/dc/terms" 2314 namespace dsrl = "http://purl.oclc.org/dsdl/dsrl" 2315 namespace inet = "urn:ietf:params:xml:ns:yang:inet-types" 2316 namespace nm = "urn:ietf:params:xml:ns:netmod:dsdl-attrib:1" 2317 namespace sch = "http://purl.oclc.org/dsdl/schematron" 2319 dc:creator [ 2320 "IETF NETMOD (NETCONF Data Modeling Language) Working Group" 2321 ] 2322 dc:description [ 2323 "This module contains a collection of generally useful derived\x{a}" ~ 2324 "YANG data types for Internet addresses and related things.\x{a}" ~ 2325 "\x{a}" ~ 2326 "Copyright (C) 2009 The IETF Trust and the persons identif" 2327 ~ "ied as\x{a}" ~ 2328 "the document authors. This version of this YANG module i" 2329 ~ "s part\x{a}" ~ 2330 "of RFC XXXX; see the RFC itself for full legal notices." 2331 ] 2332 dc:issued [ "2009-03-09" ] 2333 dc:source [ "YANG module 'ietf-inet-types' (automatic translation)" ] 2334 dc:contributor [ 2335 "WG Web: \x{a}" ~ 2336 "WG List: \x{a}" ~ 2337 "\x{a}" ~ 2338 "WG Chair: David Partain\x{a}" ~ 2339 " \x{a}" ~ 2340 "\x{a}" ~ 2341 "WG Chair: David Kessens\x{a}" ~ 2342 " \x{a}" ~ 2343 "\x{a}" ~ 2344 "Editor: Juergen Schoenwaelder\x{a}" ~ 2345 " " 2346 ] 2348 ## This value represents the version of the IP protocol. 2349 ## 2350 ## This type is in the value set and its semantics equivalent 2351 ## to the InetVersion textual convention of the SMIv2. However, 2352 ## the lexical appearance is different from the InetVersion 2353 ## textual convention. 2355 ## See: RFC 791: Internet Protocol 2356 ## RFC 2460: Internet Protocol, Version 6 (IPv6) Specification 2357 ## RFC 4001: Textual Conventions for Internet Network Addresses 2358 ip-version = "unknown" | "ipv4" | "ipv6" 2360 ## The dscp type represents a Differentiated Services Code-Point 2361 ## that may be used for marking packets in a traffic stream. 2362 ## 2363 ## This type is in the value set and its semantics equivalent 2364 ## to the Dscp textual convention of the SMIv2. 2366 ## See: RFC 3289: Management Information Base for the Differentiated 2367 ## Services Architecture 2368 ## RFC 2474: Definition of the Differentiated Services Field 2369 ## (DS Field) in the IPv4 and IPv6 Headers 2370 ## RFC 2780: IANA Allocation Guidelines For Values In 2371 ## the Internet Protocol and Related Headers 2372 dscp = xsd:unsignedByte { minInclusive = "0" maxInclusive = "63" } 2374 ## The flow-label type represents flow identifier or Flow Label 2375 ## in an IPv6 packet header that may be used to discriminate 2376 ## traffic flows. 2378 ## 2379 ## This type is in the value set and its semantics equivalent 2380 ## to the IPv6FlowLabel textual convention of the SMIv2. 2382 ## See: RFC 3595: Textual Conventions for IPv6 Flow Label 2383 ## RFC 2460: Internet Protocol, Version 6 (IPv6) Specification 2384 flow-label = 2385 xsd:unsignedInt { minInclusive = "0" maxInclusive = "1048575" } 2387 ## The port-number type represents a 16-bit port number of an 2388 ## Internet transport layer protocol such as UDP, TCP, DCCP or 2389 ## SCTP. Port numbers are assigned by IANA. A current list of 2390 ## all assignments is available from . 2391 ## 2392 ## Note that the value zero is not a valid port number. A union 2393 ## type might be used in situations where the value zero is 2394 ## meaningful. 2395 ## 2396 ## This type is in the value set and its semantics equivalent 2397 ## to the InetPortNumber textual convention of the SMIv2. 2399 ## See: RFC 768: User Datagram Protocol 2400 ## RFC 793: Transmission Control Protocol 2401 ## RFC 2960: Stream Control Transmission Protocol 2402 ## RFC 4340: Datagram Congestion Control Protocol (DCCP) 2403 ## RFC 4001: Textual Conventions for Internet Network Addresses 2404 port-number = 2405 xsd:unsignedShort { minInclusive = "1" maxInclusive = "65535" } 2407 ## The as-number type represents autonomous system numbers 2408 ## which identify an Autonomous System (AS). An AS is a set 2409 ## of routers under a single technical administration, using 2410 ## an interior gateway protocol and common metrics to route 2411 ## packets within the AS, and using an exterior gateway 2412 ## protocol to route packets to other ASs'. IANA maintains 2413 ## the AS number space and has delegated large parts to the 2414 ## regional registries. 2415 ## 2416 ## Autonomous system numbers were originally limited to 16 2417 ## bits. BGP extensions have enlarged the autonomous system 2418 ## number space to 32 bits. This type therefore uses an uint32 2419 ## base type without a range restriction in order to support 2420 ## a larger autonomous system number space. 2421 ## 2422 ## This type is in the value set and its semantics equivalent 2423 ## to the InetAutonomousSystemNumber textual convention of 2424 ## the SMIv2. 2426 ## See: RFC 1930: Guidelines for creation, selection, and registration 2427 ## of an Autonomous System (AS) 2428 ## RFC 4271: A Border Gateway Protocol 4 (BGP-4) 2429 ## RFC 4893: BGP Support for Four-octet AS Number Space 2430 ## RFC 4001: Textual Conventions for Internet Network Addresses 2431 as-number = xsd:unsignedInt 2433 ## The ip-address type represents an IP address and is IP 2434 ## version neutral. The format of the textual representations 2435 ## implies the IP version. 2436 ip-address = ipv4-address | ipv6-address 2438 ## The ipv4-address type represents an IPv4 address in 2439 ## dotted-quad notation. The IPv4 address may include a zone 2440 ## index, separated by a % sign. 2441 ## 2442 ## The zone index is used to disambiguate identical address 2443 ## values. For link-local addresses, the zone index will 2444 ## typically be the interface index number or the name of an 2445 ## interface. If the zone index is not present, the default 2446 ## zone of the device will be used. 2447 ## 2448 ## The canonical format for the zone index is the numerical 2449 ## format 2450 ipv4-address = 2451 xsd:string { 2452 pattern = 2453 "((0|(1[0-9]{0,2})|(2(([0-4][0-9]?)|(5[0-5]?)|([6-9]?)" 2454 ~ "))|([3-9][0-9]?))\.){3}(0|(1[0-9]{0,2})|(2(([0-4][0-9]?)|(5[" 2455 ~ "0-5]?)|([6-9]?)))|([3-9][0-9]?))(%[\p{N}\p{L}]+)?" 2456 } 2458 ## The ipv6-address type represents an IPv6 address in full, 2459 ## mixed, shortened and shortened mixed notation. The IPv6 2460 ## address may include a zone index, separated by a % sign. 2461 ## 2462 ## The zone index is used to disambiguate identical address 2463 ## values. For link-local addresses, the zone index will 2464 ## typically be the interface index number or the name of an 2465 ## interface. If the zone index is not present, the default 2466 ## zone of the device will be used. 2467 ## 2468 ## The canonical format of IPv6 addresses must match the 2469 ## pattern '((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})' 2470 ## with leading zeros suppressed as described in RFC 4291 2471 ## section 2.2 item 1. The canonical format for the zone 2472 ## index is the numerical format as described in RFC 4007 2473 ## section 11.2. 2475 ## See: RFC 4291: IP Version 6 Addressing Architecture 2476 ## RFC 4007: IPv6 Scoped Address Architecture 2477 ipv6-address = 2478 xsd:string { 2479 pattern = 2480 "((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})(%[\p{N}\p" 2481 ~ "{L}]+)?)|((([0-9a-fA-F]{1,4}:){6})(([0-9]{1,3}\.[0-9]{1,3}\." 2482 ~ "[0-9]{1,3}\.[0-9]{1,3}))(%[\p{N}\p{L}]+)?)|((([0-9a-fA-F]{1," 2483 ~ "4}:)*([0-9a-fA-F]{1,4}))*(::)(([0-9a-fA-F]{1,4}:)*([0-9a-fA-" 2484 ~ "F]{1,4}))*(%[\p{N}\p{L}]+)?)|((([0-9a-fA-F]{1,4}:)*([0-9a-fA" 2485 ~ "-F]{1,4}))*(::)(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(([0" 2486 ~ "-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))(%[\p{N}\p{L}]" 2487 ~ "+)?)" 2488 } 2490 ## The ip-prefix type represents an IP prefix and is IP 2491 ## version neutral. The format of the textual representations 2492 ## implies the IP version. 2493 ip-prefix = ipv4-prefix | ipv6-prefix 2495 ## The ipv4-prefix type represents an IPv4 address prefix. 2496 ## The prefix length is given by the number following the 2497 ## slash character and must be less than or equal to 32. 2498 ## 2499 ## A prefix length value of n corresponds to an IP address 2500 ## mask which has n contiguous 1-bits from the most 2501 ## significant bit (MSB) and all other bits set to 0. 2502 ## 2503 ## The canonical format of an IPv4 prefix has all bits of 2504 ## the IPv4 address set to zero that are not part of the 2505 ## IPv4 prefix. 2506 ipv4-prefix = 2507 xsd:string { 2508 pattern = 2509 "(([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])\.){3}([0-1]?" 2510 ~ "[0-9]?[0-9]|2[0-4][0-9]|25[0-5])/\d+" 2511 } 2513 ## The ipv6-prefix type represents an IPv6 address prefix. 2514 ## The prefix length is given by the number following the 2515 ## slash character and must be less than or equal 128. 2516 ## 2517 ## A prefix length value of n corresponds to an IP address 2518 ## mask which has n contiguous 1-bits from the most 2519 ## significant bit (MSB) and all other bits set to 0. 2520 ## 2521 ## The IPv6 address should have all bits that do not belong 2522 ## to the prefix set to zero. 2524 ## 2525 ## The canonical format of an IPv6 prefix has all bits of 2526 ## the IPv6 address set to zero that are not part of the 2527 ## IPv6 prefix. Furthermore, the IPv6 address must match the 2528 ## pattern '((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})' 2529 ## with leading zeros suppressed as described in RFC 4291 2530 ## section 2.2 item 1. 2532 ## See: RFC 4291: IP Version 6 Addressing Architecture 2533 ipv6-prefix = 2534 xsd:string { 2535 pattern = 2536 "((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})/\d+)|((([" 2537 ~ "0-9a-fA-F]{1,4}:){6})(([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[" 2538 ~ "0-9]{1,3}))/\d+)|((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(" 2539 ~ "::)(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*/\d+)|((([0-9a-f" 2540 ~ "A-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)(([0-9a-fA-F]{1,4}:)*([0" 2541 ~ "-9a-fA-F]{1,4}))*(([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]" 2542 ~ "{1,3}))/\d+)" 2543 } 2545 ## The domain-name type represents a DNS domain name. The 2546 ## name SHOULD be fully qualified whenever possible. 2547 ## 2548 ## The description clause of objects using the domain-name 2549 ## type MUST describe how (and when) these names are 2550 ## resolved to IP addresses. 2551 ## 2552 ## Note that the resolution of a domain-name value may 2553 ## require to query multiple DNS records (e.g., A for IPv4 2554 ## and AAAA for IPv6). The order of the resolution process 2555 ## and which DNS record takes precedence depends on the 2556 ## configuration of the resolver. 2557 ## 2558 ## The canonical format for domain-name values uses the US-ASCII 2559 ## encoding and case-insensitive characters are set to lowercase. 2561 ## See: RFC 1034: Domain Names - Concepts and Facilities 2562 ## RFC 1123: Requirements for Internet Hosts -- Application 2563 ## and Support 2564 domain-name = 2565 xsd:string { 2566 pattern = 2567 "([a-zA-Z0-9][a-zA-Z0-9\-]*[a-zA-Z0-9]\.)*[a-zA-Z0-9][" 2568 ~ "a-zA-Z0-9\-]*[a-zA-Z0-9]" 2569 } 2571 ## The host type represents either an IP address or a DNS 2572 ## domain name. 2573 host = ip-address | domain-name 2575 ## The uri type represents a Uniform Resource Identifier 2576 ## (URI) as defined by STD 66. 2577 ## 2578 ## Objects using the uri type must be in US-ASCII encoding, 2579 ## and MUST be normalized as described by RFC 3986 Sections 2580 ## 6.2.1, 6.2.2.1, and 6.2.2.2. All unnecessary 2581 ## percent-encoding is removed, and all case-insensitive 2582 ## characters are set to lowercase except for hexadecimal 2583 ## digits, which are normalized to uppercase as described in 2584 ## Section 6.2.2.1. 2585 ## 2586 ## The purpose of this normalization is to help provide 2587 ## unique URIs. Note that this normalization is not 2588 ## sufficient to provide uniqueness. Two URIs that are 2589 ## textually distinct after this normalization may still be 2590 ## equivalent. 2591 ## 2592 ## Objects using the uri type may restrict the schemes that 2593 ## they permit. For example, 'data:' and 'urn:' schemes 2594 ## might not be appropriate. 2595 ## 2596 ## A zero-length URI is not a valid URI. This can be used to 2597 ## express 'URI absent' where required 2598 ## 2599 ## This type is in the value set and its semantics equivalent 2600 ## to the Uri textual convention of the SMIv2. 2602 ## See: RFC 3986: Uniform Resource Identifier (URI): Generic Syntax 2603 ## RFC 3305: Report from the Joint W3C/IETF URI Planning Interest 2604 ## Group: Uniform Resource Identifiers (URIs), URLs, 2605 ## and Uniform Resource Names (URNs): Clarifications 2606 ## and Recommendations 2607 ## RFC 5017: MIB Textual Conventions for Uniform Resource 2608 ## Identifiers (URIs) 2609 uri = xsd:string 2611 B.3. RelaxNG of IEEE Specific Derived Types 2613 namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" 2614 namespace dc = "http://purl.org/dc/terms" 2615 namespace dsrl = "http://purl.oclc.org/dsdl/dsrl" 2616 namespace ieee = "urn:ietf:params:xml:ns:yang:ieee-types" 2617 namespace nm = "urn:ietf:params:xml:ns:netmod:dsdl-attrib:1" 2618 namespace sch = "http://purl.oclc.org/dsdl/schematron" 2619 dc:creator [ 2620 "IETF NETMOD (NETCONF Data Modeling Language) Working Group" 2621 ] 2622 dc:description [ 2623 "This module contains a collection of generally useful derived\x{a}" ~ 2624 "YANG data types for IEEE 802 addresses and related things.\x{a}" ~ 2625 "\x{a}" ~ 2626 "Copyright (C) 2009 The IETF Trust and the persons identif" 2627 ~ "ied as\x{a}" ~ 2628 "the document authors. This version of this YANG module i" 2629 ~ "s part\x{a}" ~ 2630 "of RFC XXXX; see the RFC itself for full legal notices." 2631 ] 2632 dc:issued [ "2009-03-09" ] 2633 dc:source [ "YANG module 'ietf-ieee-types' (automatic translation)" ] 2634 dc:contributor [ 2635 "WG Web: \x{a}" ~ 2636 "WG List: \x{a}" ~ 2637 "\x{a}" ~ 2638 "WG Chair: David Partain\x{a}" ~ 2639 " \x{a}" ~ 2640 "\x{a}" ~ 2641 "WG Chair: David Kessens\x{a}" ~ 2642 " \x{a}" ~ 2643 "\x{a}" ~ 2644 "Editor: Juergen Schoenwaelder\x{a}" ~ 2645 " " 2646 ] 2648 ## The mac-address type represents an 802 MAC address represented 2649 ## in the `canonical' order defined by IEEE 802.1a, i.e., as if it 2650 ## were transmitted least significant bit first, even though 802.5 2651 ## (in contrast to other 802.x protocols) requires MAC addresses 2652 ## to be transmitted most significant bit first. 2653 ## 2654 ## This type is in the value set and its semantics equivalent to 2655 ## the MacAddress textual convention of the SMIv2. 2657 ## See: RFC 2579: Textual Conventions for SMIv2 2658 mac-address = 2659 xsd:string { pattern = "[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}" } 2661 ## The bridgeid type represents identifiers that uniquely 2662 ## identify a bridge. Its first four hexadecimal digits 2663 ## contain a priority value followed by a colon. The 2664 ## remaining characters contain the MAC address used to 2665 ## refer to a bridge in a unique fashion (typically, the 2666 ## numerically smallest MAC address of all ports on the 2667 ## bridge). 2668 ## 2669 ## This type is in the value set and its semantics equivalent 2670 ## to the BridgeId textual convention of the SMIv2. However, 2671 ## since the BridgeId textual convention does not prescribe 2672 ## a lexical representation, the appearance might be different. 2674 ## See: RFC 4188: Definitions of Managed Objects for Bridges 2675 bridgeid = xsd:string { pattern = "[0-9a-fA-F]{4}(:[0-9a-fA-F]{2}){6}" } 2677 ## The vlanid type uniquely identifies a VLAN. This is the 2678 ## 12-bit VLAN-ID used in the VLAN Tag header. The range is 2679 ## defined by the referenced specification. 2680 ## 2681 ## This type is in the value set and its semantics equivalent to 2682 ## the VlanId textual convention of the SMIv2. 2684 ## See: IEEE Std 802.1Q 2003 Edition: Virtual Bridged Local 2685 ## Area Networks 2686 ## RFC 4363: Definitions of Managed Objects for Bridges with 2687 ## Traffic Classes, Multicast Filtering, and Virtual 2688 ## LAN Extensions 2689 vlanid = xsd:unsignedShort { minInclusive = "1" maxInclusive = "4094" } 2690 Author's Address 2692 Juergen Schoenwaelder (editor) 2693 Jacobs University 2695 Email: j.schoenwaelder@jacobs-university.de