idnits 2.17.1 draft-schoenw-netmod-yang-types-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 854. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 865. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 872. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 878. 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 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 14, 2008) is 5766 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 570, but not defined == Missing Reference: '1-3' is mentioned on line 264, but not defined == Missing Reference: '0-9' is mentioned on line 570, but not defined == Missing Reference: '1-9' is mentioned on line 264, but not defined == Missing Reference: '0-4' is mentioned on line 570, but not defined == Missing Reference: '0-5' is mentioned on line 570, but not defined == Outdated reference: A later version (-13) exists of draft-ietf-netmod-yang-00 -- Obsolete informational reference (is this intentional?): RFC 4741 (Obsoleted by RFC 6241) Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 9 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 July 14, 2008 5 Expires: January 15, 2009 7 Common YANG Data Types 8 draft-schoenw-netmod-yang-types-01 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 15, 2009. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This document introduces a collection of common data types to be used 42 with the YANG data modeling language. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 4 48 3. Core YANG Derived Types . . . . . . . . . . . . . . . . . . . 5 49 4. Internet Specific Derived Types . . . . . . . . . . . . . . . 11 50 5. IEEE 802 Specific Derived Types . . . . . . . . . . . . . . . 18 51 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 52 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 53 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22 54 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 23 55 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 56 10.1. Normative References . . . . . . . . . . . . . . . . . . 24 57 10.2. Informative References . . . . . . . . . . . . . . . . . 24 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 59 Intellectual Property and Copyright Statements . . . . . . . . . . 26 61 1. Introduction 63 YANG [YANG] is a data modeling language used to model configuration 64 and state data manipulated by the NETCONF [RFC4741] protocol. The 65 YANG language supports a small set of built-in data types and 66 provides mechanisms to derive other types from the built-in types. 68 This document introduces a collection of common data types derived 69 from the built-in YANG data types. The definitions are organized in 70 several YANG modules. The "yang-types" module contains generally 71 useful data types. The "inet-types" module contains definitions that 72 are relevant for the Internet protocol suite while the "ieee-types" 73 module contains definitions that are relevant for IEEE 802 protocols. 75 Their derived types are generally designed to be applicable for 76 modeling all areas of management information. 78 2. Key Words 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 82 "OPTIONAL" in this document are to be interpreted as described in BCP 83 14, [RFC2119]. 85 3. Core YANG Derived Types 87 module yang-types { 89 // XXX namespace to be allocated by IANA 91 namespace "urn:ietf:params:xml:ns:yang:yang-types"; 92 prefix "yang"; 94 organization 95 "YANG Language Design Team"; 97 contact 98 "Juergen Schoenwaelder (Editor) 99 "; 101 description 102 "This module contains standard derived YANG types."; 104 revision 2009-05-22 { 105 description "Initial revision."; 106 } 108 /* 109 * collection of counter and gauge types 110 */ 112 typedef counter32 { 113 type uint32; 114 description 115 "The counter32 type represents a non-negative integer 116 which monotonically increases until it reaches a 117 maximum value of 2^32-1 (4294967295 decimal), when it 118 wraps around and starts increasing again from zero. 120 Counters have no defined `initial' value, and thus, a 121 single value of a counter has (in general) no information 122 content. Discontinuities in the monotonically increasing 123 value normally occur at re-initialization of the 124 management system, and at other times as specified in the 125 description of an object instance using this type. If 126 such other times can occur, for example, the creation of 127 an object instance of type counter32 at times other than 128 re-initialization, then a corresponding object should be 129 defined, with an appropriate type, to indicate the last 130 discontinuity. 132 The counter32 type should not be used for configuration 133 objects. A default statement should not be used for 134 attributes with a type value of counter32."; 135 reference 136 "RFC 2578 (STD 58)"; 137 } 139 typedef zero-based-counter32 { 140 type yang:counter32; 141 default "0"; 142 description 143 "The zero-based-counter32 type represents a counter32 144 which has the defined `initial' value zero."; 145 reference 146 "RFC 2021"; 147 } 149 typedef counter64 { 150 type uint64; 151 description 152 "The counter64 type represents a non-negative integer 153 which monotonically increases until it reaches a 154 maximum value of 2^64-1 (18446744073709551615), when 155 it wraps around and starts increasing again from zero. 157 Counters have no defined `initial' value, and thus, a 158 single value of a counter has (in general) no information 159 content. Discontinuities in the monotonically increasing 160 value normally occur at re-initialization of the 161 management system, and at other times as specified in the 162 description of an object instance using this type. If 163 such other times can occur, for example, the creation of 164 an object instance of type counter64 at times other than 165 re-initialization, then a corresponding object should be 166 defined, with an appropriate type, to indicate the last 167 discontinuity. 169 The counter64 type should not be used for configuration 170 objects. A default statement should not be used for 171 attributes with a type value of counter64."; 172 reference 173 "RFC 2578 (STD 58)"; 174 } 176 typedef zero-based-counter64 { 177 type yang:counter64; 178 default "0"; 179 description 180 "The zero-based-counter64 type represents a counter64 181 which has the defined `initial' value zero."; 182 reference 183 "RFC 2856"; 184 } 186 typedef gauge32 { 187 type uint32; 188 description 189 "The gauge32 type represents a non-negative integer, 190 which may increase or decrease, but shall never 191 exceed a maximum value, nor fall below a minimum 192 value. The maximum value can not be greater than 193 2^32-1 (4294967295 decimal), and the minimum value 194 can not be smaller than 0. The value of a gauge32 195 has its maximum value whenever the information 196 being modeled is greater than or equal to its 197 maximum value, and has its minimum value whenever 198 the information being modeled is smaller than or 199 equal to its minimum value. If the information 200 being modeled subsequently decreases below 201 (increases above) the maximum (minimum) value, the 202 gauge32 also decreases (increases)."; 203 reference 204 "RFC 2578 (STD 58)"; 205 } 207 typedef gauge64 { 208 type uint64; 209 description 210 "The gauge64 type represents a non-negative integer, 211 which may increase or decrease, but shall never 212 exceed a maximum value, nor fall below a minimum 213 value. The maximum value can not be greater than 214 2^64-1 (18446744073709551615), and the minimum value 215 can not be smaller than 0. The value of a gauge64 216 has its maximum value whenever the information 217 being modeled is greater than or equal to its 218 maximum value, and has its minimum value whenever 219 the information being modeled is smaller than or 220 equal to its minimum value. If the information 221 being modeled subsequently decreases below 222 (increases above) the maximum (minimum) value, the 223 gauge64 also decreases (increases)."; 224 reference 225 "RFC 2856"; 226 } 228 /* 229 * collection of identifier related types 230 */ 232 typedef uri { 233 type string; 234 description 235 "A uri type represents Uniform Resource Identifier (URI) 236 as defined by STD 66. 238 Objects using this type MUST be in US-ASCII encoding, and 239 MUST be normalized as described by RFC 3986 Sections 240 6.2.1, 6.2.2.1, and 6.2.2.2. All unnecessary 241 percent-encoding is removed, and all case-insensitive 242 characters are set to lowercase except for hexadecimal 243 digits, which are normalized to uppercase as described in 244 Section 6.2.2.1. 246 The purpose of this normalization is to help provide unique 247 URIs. Note that this normalization is not sufficient to 248 provide uniqueness. Two URIs that are textually distinct 249 after this normalization may still be equivalent. 251 Objects using this type MAY restrict the schemes that they 252 permit. For example, 'data:' and 'urn:' schemes might not 253 be appropriate. 255 A zero-length URI is not a valid URI. This can be used to 256 express 'URI absent' where required, for example when used 257 as an index field."; 258 reference 259 "RFC 3986 (STD 66), RFC 3305, and RFC 5017"; 260 } 262 typedef object-identifier { 263 type string { 264 pattern '([0-1](\.[1-3]?[0-9]))|(2.(0|([1-9]\d*)))' 265 + '(\.(0|([1-9]\d*)))*'; 266 } 267 description 268 "The object-identifier type represents administratively 269 assigned names in a registration-hierarchical-name tree. 271 Values of this type are denoted as a sequence of numerical 272 non-negative sub-identifier values. Each sub-identifier 273 value MUST NOT exceed 2^32-1 (4294967295). Sub-identifiers 274 are separated by single dots and without any intermediate 275 white space. 277 Although the number of sub-identifiers is not limited, 278 module designers should realize that there may be 279 implementations that stick with the SMIv1/v2 limit of 128 280 sub-identifiers."; 281 reference 282 "ITU-T Recommendation X.660 / ISO/IEC 9834-1"; 283 } 285 /* 286 * collection of date and time related types 287 */ 289 typedef date-and-time { 290 type string { 291 pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.d*)?' 292 + '(Z|(\+|-)\d{2}:\d{2})'; 293 } 294 description 295 'The date-and-time type is a profile of the ISO 8601 296 standard for representation of dates and times using the 297 Gregorian calendar. The format is most easily described 298 using the following ABFN (see RFC 3339): 300 date-fullyear = 4DIGIT 301 date-month = 2DIGIT ; 01-12 302 date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 303 time-hour = 2DIGIT ; 00-23 304 time-minute = 2DIGIT ; 00-59 305 time-second = 2DIGIT ; 00-58, 00-59, 00-60 306 time-secfrac = "." 1*DIGIT 307 time-numoffset = ("+" / "-") time-hour ":" time-minute 308 time-offset = "Z" / time-numoffset 310 partial-time = time-hour ":" time-minute ":" time-second 311 [time-secfrac] 312 full-date = date-fullyear "-" date-month "-" date-mday 313 full-time = partial-time time-offset 315 date-time = full-date "T" full-time'; 316 reference "RFC 3339"; 317 } 319 typedef timeticks { 320 type uint32; 321 description 322 "The timeticks type represents a non-negative integer 323 which represents the time, modulo 2^32 (4294967296 324 decimal), in hundredths of a second between two epochs. 326 When objects are defined which use this type, the 327 description of the object identifies both of the reference 328 epochs."; 329 reference 330 "RFC 2578 (STD 58)"; 331 } 333 typedef timestamp { 334 type yang:timeticks; 335 description 336 "The timestamp type represents the value of an associated 337 timeticks object at which a specific occurrence 338 happened. The specific occurrence must be defined in the 339 description of any object defined using this type. When 340 the specific occurrence occurred prior to the last time 341 the associated timeticks attribute was zero, then the 342 timestamp value is zero. Note that this requires all 343 timestamp values to be reset to zero when the value of 344 the associated timeticks attribute reaches 497+ days and 345 wraps around to zero. 347 The associated timeticks object must be specified 348 in the description of any object using this type."; 349 reference 350 "RFC 2579 (STD 58)"; 351 } 353 /* 354 * collection of generic address types 355 */ 357 typedef phys-address { 358 type string; 359 description 360 "Represents media- or physical-level addresses."; 361 reference 362 "RFC 2579 (STD 58)"; 363 } 364 } 365 4. Internet Specific Derived Types 367 module inet-types { 369 // XXX namespace to be allocated by IANA 371 namespace "urn:ietf:params:xml:ns:yang:inet-types"; 372 prefix "inet"; 374 organization 375 "YANG Language Design Team"; 377 contact 378 "Juergen Schoenwaelder (Editor) 379 "; 381 description 382 "This module contains standard derived YANG types 383 for Internet addresses and related things."; 385 revision 2008-06-07 { 386 description "Initial revision."; 387 } 389 /* 390 * collection of protocol field related types 391 */ 393 typedef ip-version { 394 type enumeration { 395 enum unknown { 396 value 0; 397 description 398 "An unknown or unspecified version of the 399 Internet protocol."; 400 } 401 enum ipv4 { 402 value 1; 403 description 404 "The IPv4 protocol as defined in RFC 791."; 405 } 406 enum ipv6 { 407 value 2; 408 description 409 "The IPv6 protocol as defined in RFC 2460."; 410 } 411 } 412 description 413 "This value represents the version of the IP protocol."; 414 reference 415 "RFC 791 (STD 5), RFC 2460"; 416 } 418 typedef dscp { 419 type uint8 { 420 range "0..63"; 421 } 422 description 423 "The dscp type represents a Differentiated Services 424 Code-Point that may be used for marking a traffic 425 stream."; 426 reference 427 "RFC 3289, RFC 2474, RFC 2780"; 428 } 430 typedef flow-label { 431 type uint32 { 432 range "0..1048575"; 433 } 434 description 435 "The flow-label type represents flow identifier or 436 Flow Label in an IPv6 packet header that may be 437 used to discriminate traffic flows."; 438 reference 439 "RFC 2460"; 440 } 442 typedef port-number { 443 type uint16 { 444 range "1..65535"; 445 } 446 description 447 "The port-number type represents a 16-bit port 448 number of an Internet transport layer protocol 449 such as UDP, TCP, DCCP or SCTP. Port numbers are 450 assigned by IANA. A current list of all 451 assignments is available from 452 . 454 Note that the value zero is not a valid port 455 number. A union type might be used in situations 456 where the value zero is meaningful."; 457 reference 458 "RFC 4001"; 459 } 460 /* 461 * collection of autonomous system related types 462 */ 464 typedef as-number { 465 type uint32; 466 description 467 "The as-number type represents autonomous system numbers 468 which identify an Autonomous System (AS). An AS is a set 469 of routers under a single technical administration, using 470 an interior gateway protocol and common metrics to route 471 packets within the AS, and using an exterior gateway 472 protocol to route packets to other ASs'. IANA maintains 473 the AS number space and has delegated large parts to the 474 regional registries. 476 Autonomous system numbers are currently limited to 16 bits 477 (0..65535). There is however work in progress to enlarge 478 the autonomous system number space to 32 bits. This 479 textual convention therefore uses an uint32 base type 480 without a range restriction in order to support a larger 481 autonomous system number space."; 482 reference 483 "RFC 1771, RFC 1930, RFC 4001"; 484 } 486 /* 487 * collection of IP address and hostname related types 488 */ 490 typedef ip-address { 491 type union { 492 type inet:ipv4-address; 493 type inet:ipv6-address; 494 } 495 description 496 "The ip-address type represents an IP address and 497 is IP version neutral. The format of the textual 498 representations implies the IP version."; 499 } 501 typedef ipv4-address { 502 type string { 503 pattern 504 '(([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])\.){3}' 505 + '([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])' 506 + '(%[\p{N}\p{L}]+)?'; 507 } 508 description 509 "The ipv4-address type represents an IPv4 address in 510 dotted-quad notation. The IPv4 address may include 511 a zone index, separated by a % sign. 513 The zone index is used to disambiguate identical address 514 values. For link-local addresses, the zone index will 515 typically be the interface index number or the name of an 516 interface. If the zone index is not present, the default 517 zone of the device will be used."; 518 } 520 typedef ipv6-address { 521 type string { 522 pattern 523 /* full */ 524 '((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})' 525 + '(%[\p{N}\p{L}]+)?)' 526 /* mixed */ 527 + '|((([0-9a-fA-F]{1,4}:){6})(([0-9]{1,3}\.' 528 + '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))' 529 + '(%[\p{N}\p{L}]+)?)' 530 /* shortened */ 531 + '|((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)' 532 + '(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*' 533 + '(%[\p{N}\p{L}]+)?)' 534 /* shortened mixed */ 535 + '((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)' 536 + '(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*' 537 + '(([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))' 538 + '(%[\p{N}\p{L}]+)?)'; 539 } 540 description 541 "The ipv6-address type represents an IPv6 address in 542 full, mixed, shortened and shortened mixed notation. 543 The IPv6 address may include a zone index, separated 544 by a % sign. 546 The zone index is used to disambiguate identical address 547 values. For link-local addresses, the zone index will 548 typically be the interface index number or the name of an 549 interface. If the zone index is not present, the default 550 zone of the device will be used."; 551 reference 552 "RFC 4007: IPv6 Scoped Address Architecture"; 553 } 555 typedef ip-prefix { 556 type union { 557 type inet:ipv4-prefix; 558 type inet:ipv6-prefix; 559 } 560 description 561 "The ip-prefix type represents an IP prefix and 562 is IP version neutral. The format of the textual 563 representations implies the IP version."; 564 } 566 typedef ipv4-prefix { 567 type string { 568 pattern 569 '(([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])\.){3}' 570 + '([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])' 571 + '/\p{N}+'; 572 } 573 description 574 "The ipv4-prefix type represents an IPv4 address prefix. 575 The prefix length is given by the number following the 576 slash character and must be less than or equal 32. 578 A prefix length value of n corresponds to an IP address 579 mask which has n contiguous 1-bits from the most 580 significant bit (MSB) and all other bits set to 0. 582 The IPv4 address represented in dotted quad notation 583 should have all bits that do not belong to the prefix 584 set to zero."; 585 } 587 typedef ipv6-prefix { 588 type string { 589 pattern 590 /* full */ 591 '((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})' 592 + '/\p{N}+)' 593 /* mixed */ 594 + '|((([0-9a-fA-F]{1,4}:){6})(([0-9]{1,3}\.' 595 + '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))' 596 + '/\p{N}+)' 597 /* shortened */ 598 + '|((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)' 599 + '(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*' 600 + '/\p{N}+)' 601 /* shortened mixed */ 602 + '((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)' 603 + '(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*' 604 + '(([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))' 605 + '/\p{N}+)'; 606 } 607 description 608 "The ipv6-prefix type represents an IPv6 address prefix. 609 The prefix length is given by the number following the 610 slash character and must be less than or equal 128. 612 A prefix length value of n corresponds to an IP address 613 mask which has n contiguous 1-bits from the most 614 significant bit (MSB) and all other bits set to 0. 616 The IPv6 address should have all bits that do not belong 617 to the prefix set to zero."; 618 } 620 /* 621 * Domain name and URI types. 622 */ 624 typedef domain-name { 625 type string { 626 pattern '([a-zA-Z0-9\-]+\.)*[a-zA-Z0-9\-]+'; 627 } 628 description 629 "The domain-name type represents a DNS domain 630 name. The name SHOULD be fully qualified 631 whenever possible. 633 The description clause of objects using the 634 domain-name type MUST describe how (and when) 635 these names are resolved to IP addresses. 637 Note that the resolution of a domain-name value 638 may require to query multiple DNS records (e.g., 639 A for IPv4 and AAAA for IPv6). The order of the 640 resolution process and which DNS record takes 641 precedence depends on the configuration of the 642 resolver."; 643 reference 644 "RFC 1034"; 645 } 647 typedef host { 648 type union { 649 type inet:ip-address; 650 type inet:domain-name; 651 } 652 description 653 "The host type represents either an IP address 654 or a DNS domain name."; 655 } 657 typedef uri { 658 type string; // TBD: add the regex from RFC 3986 here? 659 description 660 "The uri type represents a Uniform Resource Identifier 661 (URI) as defined by STD 66. 663 Objects using the uri type must be in US-ASCII encoding, 664 and MUST be normalized as described by RFC 3986 Sections 665 6.2.1, 6.2.2.1, and 6.2.2.2. All unnecessary 666 percent-encoding is removed, and all case-insensitive 667 characters are set to lowercase except for hexadecimal 668 digits, which are normalized to uppercase as described in 669 Section 6.2.2.1. 671 The purpose of this normalization is to help provide 672 unique URIs. Note that this normalization is not 673 sufficient to provide uniqueness. Two URIs that are 674 textually distinct after this normalization may still be 675 equivalent. 677 Objects using the uri type may restrict the schemes that 678 they permit. For example, 'data:' and 'urn:' schemes 679 might not be appropriate. 681 A zero-length URI is not a valid URI. This can be used to 682 express 'URI absent' where required." 683 reference "RFC 3986 STD 66 and RFC 3305" 684 } 686 } 688 5. IEEE 802 Specific Derived Types 690 module ieee-types { 692 // XXX namespace to be allocated by IANA 694 namespace "urn:ietf:params:xml:ns:yang:ieee-types"; 695 prefix "ieee"; 697 import yang-types { 698 prefix yang; 699 } 701 organization 702 "YANG Language Design Team"; 704 contact 705 "Juergen Schoenwaelder (Editor) 706 "; 708 description 709 "This module contains standard derived YANG types 710 for IEEE 802 addresses and related things."; 712 revision 2008-05-22 { 713 description "Initial revision."; 714 } 716 /* 717 * collection of IEEE address type definitions 718 */ 720 typedef mac-address { 721 type yang:phys-address { 722 pattern '([0-9a-fA-F]{2}:){5}[0-9a-fA-F]{2}'; 723 } 724 description 725 "The mac-address type represents an 802 MAC address 726 represented in the `canonical' order defined by 727 IEEE 802.1a, i.e., as if it were transmitted least 728 significant bit first, even though 802.5 (in contrast 729 to other 802.x protocols) requires MAC addresses to 730 be transmitted most significant bit first."; 731 reference 732 "RFC 2579 STD 58"; 733 } 735 /* 736 * collection of IEEE 802 related identifier types 737 */ 739 typedef bridgeid { 740 type string { 741 pattern '[0-9a-fA-F]{4}:' 742 + '([0-9a-fA-F]{2}:){5}[0-9a-fA-F]{2}'; 743 } 744 description 745 "The bridgeid type represents identifers that uniquely 746 identify a bridge. Its first four hexadecimal digits 747 contain a priority value followed by a colon. The 748 remaining characters contain the MAC address used to 749 refer to a bridge in a unique fashion (typically, the 750 numerically smallest MAC address of all ports on the 751 bridge)."; 752 reference 753 "RFC 4188"; 754 } 756 typedef vlanid { 757 type uint16 { 758 range "1..4094"; 759 } 760 description 761 "The vlanid type uniquely identifies a VLAN. This is 762 the 12-bit VLAN-ID used in the VLAN Tag header. The 763 range is defined by the referenced specification."; 764 reference 765 "IEEE Std 802.1Q 2003 Edition, Virtual Bridged Local 766 Area Networks."; 767 } 768 } 770 6. IANA Considerations 772 A registry for standard YANG modules shall be set up. Each entry 773 shall contain the unique module name, the unique XML namespace from 774 the YANG URI Scheme and some reference to the module's documentation. 776 This document registers three URIs for the YANG XML namespace in the 777 IETF XML registry [RFC3688]. 779 URI: urn:ietf:params:xml:ns:yang:ieee-types 781 URI: urn:ietf:params:xml:ns:yang:inet-types 783 URI: urn:ietf:params:xml:ns:yang:yang-types 785 7. Security Considerations 787 This document defines common data types using the YANG data modeling 788 language. The definitions themselves have no security impact on the 789 Internet but the usage of these definitions in concrete YANG modules 790 might have. The security considerations spelled out in the YANG 791 specification [YANG] apply for this document as well. 793 8. Contributors 795 The following people all contributed significantly to the initial 796 version of this draft: 798 - Andy Bierman (andybierman.com) 799 - Martin Bjorklund (Tail-f Systems) 800 - Balazs Lengyel (Ericsson) 801 - David Partain (Ericsson) 802 - Phil Shafer (Juniper Networks) 804 9. Open Issues 806 - Should YANG allow multiple pattern that get ANDed? This would for 807 example allow to tighten the IPv6 pattern. 809 Message-Id: <1215432618.23783.59.camel@missotis> 811 - Add some common reusable groupings, e.g. a combination of 812 ip-address and port-number? Or should such groupings be a separate 813 document? 815 10. References 817 10.1. Normative References 819 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 820 Requirement Levels", BCP 14, RFC 2119, March 1997. 822 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 823 January 2004. 825 [YANG] Bjorklund, M., Ed., "YANG - A data modeling language for 826 NETCONF", draft-ietf-netmod-yang-00 (work in progress). 828 10.2. Informative References 830 [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, 831 December 2006. 833 Author's Address 835 Juergen Schoenwaelder (editor) 836 Jacobs University 838 Email: j.schoenwaelder@jacobs-university.de 840 Full Copyright Statement 842 Copyright (C) The IETF Trust (2008). 844 This document is subject to the rights, licenses and restrictions 845 contained in BCP 78, and except as set forth therein, the authors 846 retain all their rights. 848 This document and the information contained herein are provided on an 849 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 850 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 851 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 852 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 853 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 854 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 856 Intellectual Property 858 The IETF takes no position regarding the validity or scope of any 859 Intellectual Property Rights or other rights that might be claimed to 860 pertain to the implementation or use of the technology described in 861 this document or the extent to which any license under such rights 862 might or might not be available; nor does it represent that it has 863 made any independent effort to identify any such rights. Information 864 on the procedures with respect to rights in RFC documents can be 865 found in BCP 78 and BCP 79. 867 Copies of IPR disclosures made to the IETF Secretariat and any 868 assurances of licenses to be made available, or the result of an 869 attempt made to obtain a general license or permission for the use of 870 such proprietary rights by implementers or users of this 871 specification can be obtained from the IETF on-line IPR repository at 872 http://www.ietf.org/ipr. 874 The IETF invites any interested party to bring to its attention any 875 copyrights, patents or patent applications, or other proprietary 876 rights that may cover technology that may be required to implement 877 this standard. Please address the information to the IETF at 878 ietf-ipr@ietf.org. 880 Acknowledgment 882 Funding for the RFC Editor function is provided by the IETF 883 Administrative Support Activity (IASA).