idnits 2.17.1 draft-ietf-netmod-yang-types-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to 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 (April 26, 2010) is 5086 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3339' is defined on line 1055, but no explicit reference was found in the text == Unused Reference: 'RFC3492' is defined on line 1058, but no explicit reference was found in the text == Unused Reference: 'RFC3986' is defined on line 1065, but no explicit reference was found in the text == Unused Reference: 'RFC4007' is defined on line 1069, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 1073, but no explicit reference was found in the text == Unused Reference: 'XPATH' is defined on line 1076, but no explicit reference was found in the text == Unused Reference: 'IDv6TREP' is defined on line 1086, but no explicit reference was found in the text == Unused Reference: 'IEEE802' is defined on line 1092, but no explicit reference was found in the text == Unused Reference: 'RFC0768' is defined on line 1095, but no explicit reference was found in the text == Unused Reference: 'RFC0791' is defined on line 1098, but no explicit reference was found in the text == Unused Reference: 'RFC0793' is defined on line 1101, but no explicit reference was found in the text == Unused Reference: 'RFC0952' is defined on line 1104, but no explicit reference was found in the text == Unused Reference: 'RFC1034' is defined on line 1107, but no explicit reference was found in the text == Unused Reference: 'RFC1123' is defined on line 1110, but no explicit reference was found in the text == Unused Reference: 'RFC1930' is defined on line 1113, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 1117, but no explicit reference was found in the text == Unused Reference: 'RFC2474' is defined on line 1120, but no explicit reference was found in the text == Unused Reference: 'RFC2780' is defined on line 1133, but no explicit reference was found in the text == Unused Reference: 'RFC2782' is defined on line 1137, but no explicit reference was found in the text == Unused Reference: 'RFC2856' is defined on line 1141, but no explicit reference was found in the text == Unused Reference: 'RFC3289' is defined on line 1145, but no explicit reference was found in the text == Unused Reference: 'RFC3305' is defined on line 1149, but no explicit reference was found in the text == Unused Reference: 'RFC3490' is defined on line 1155, but no explicit reference was found in the text == Unused Reference: 'RFC3595' is defined on line 1159, but no explicit reference was found in the text == Unused Reference: 'RFC4001' is defined on line 1162, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 1166, but no explicit reference was found in the text == Unused Reference: 'RFC4340' is defined on line 1169, but no explicit reference was found in the text == Unused Reference: 'RFC4502' is defined on line 1172, but no explicit reference was found in the text == Unused Reference: 'RFC4893' is defined on line 1178, but no explicit reference was found in the text == Unused Reference: 'RFC4960' is defined on line 1181, but no explicit reference was found in the text == Unused Reference: 'RFC5017' is defined on line 1184, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 1187, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'XPATH' == Outdated reference: A later version (-13) exists of draft-ietf-netmod-yang-12 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 3490 (Obsoleted by RFC 5890, RFC 5891) -- 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 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 35 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 April 26, 2010 5 Expires: October 28, 2010 7 Common YANG Data Types 8 draft-ietf-netmod-yang-types-09 10 Abstract 12 This document introduces a collection of common data types to be used 13 with the YANG data modeling language. 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on October 28, 2010. 38 Copyright Notice 40 Copyright (c) 2010 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Core YANG Derived Types . . . . . . . . . . . . . . . . . . . 6 70 4. Internet Specific Derived Types . . . . . . . . . . . . . . . 15 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 73 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26 74 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 76 9.1. Normative References . . . . . . . . . . . . . . . . . . . 28 77 9.2. Informative References . . . . . . . . . . . . . . . . . . 28 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31 80 1. Introduction 82 YANG [YANG] is a data modeling language used to model configuration 83 and state data manipulated by the NETCONF [RFC4741] protocol. The 84 YANG language supports a small set of built-in data types and 85 provides mechanisms to derive other types from the built-in types. 87 This document introduces a collection of common data types derived 88 from the built-in YANG data types. The definitions are organized in 89 several YANG modules. The "ietf-yang-types" module contains 90 generally useful data types. The "ietf-inet-types" module contains 91 definitions that are relevant for the Internet protocol suite. 93 The derived types are generally designed to be applicable for 94 modeling all areas of management information. 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 98 "OPTIONAL" in this document are to be interpreted as described in BCP 99 14, [RFC2119]. 101 2. Overview 103 This section provides a short overview of the types defined in 104 subsequent sections and their equivalent Structure of Management 105 Information Version 2 (SMIv2) [RFC2578][RFC2579] data types. A YANG 106 data type is equivalent to an SMIv2 data type if the data types have 107 the same set of values and the semantics of the values are 108 equivalent. 110 Table 1 lists the types defined in the ietf-yang-types YANG module 111 and the corresponding SMIv2 types (- indicates there is no 112 corresponding SMIv2 type). 114 ietf-yang-types 116 +-----------------------+--------------------------------+ 117 | YANG type | Equivalent SMIv2 type (module) | 118 +-----------------------+--------------------------------+ 119 | counter32 | Counter32 (SNMPv2-SMI) | 120 | zero-based-counter32 | ZeroBasedCounter32 (RMON2-MIB) | 121 | counter64 | Counter64 (SNMPv2-SMI) | 122 | zero-based-counter64 | ZeroBasedCounter64 (HCNUM-TC) | 123 | gauge32 | Gauge32 (SNMPv2-SMI) | 124 | gauge64 | CounterBasedGauge64 (HCNUM-TC) | 125 | object-identifier | - | 126 | object-identifier-128 | OBJECT IDENTIFIER | 127 | date-and-time | - | 128 | timeticks | TimeTicks (SNMPv2-SMI) | 129 | timestamp | TimeStamp (SNMPv2-TC) | 130 | phys-address | PhysAddress (SNMPv2-TC) | 131 | mac-address | MacAddress (SNMPv2-TC) | 132 | xpath1.0 | - | 133 +-----------------------+--------------------------------+ 135 Table 1 137 Table 2 lists the types defined in the ietf-inet-types YANG module 138 and the corresponding SMIv2 types (if any). 140 ietf-inet-types 142 +-----------------+-----------------------------------------------+ 143 | YANG type | Equivalent SMIv2 type (module) | 144 +-----------------+-----------------------------------------------+ 145 | ip-version | InetVersion (INET-ADDRESS-MIB) | 146 | dscp | Dscp (DIFFSERV-DSCP-TC) | 147 | ipv6-flow-label | IPv6FlowLabel (IPV6-FLOW-LABEL-MIB) | 148 | port-number | InetPortNumber (INET-ADDRESS-MIB) | 149 | as-number | InetAutonomousSystemNumber (INET-ADDRESS-MIB) | 150 | ip-address | - | 151 | ipv4-address | - | 152 | ipv6-address | - | 153 | ip-prefix | - | 154 | ipv4-prefix | - | 155 | ipv6-prefix | - | 156 | domain-name | - | 157 | host | - | 158 | uri | Uri (URI-TC-MIB) | 159 +-----------------+-----------------------------------------------+ 161 Table 2 163 3. Core YANG Derived Types 165 file "ietf-yang-types@2010-04-24.yang" 167 module ietf-yang-types { 169 namespace "urn:ietf:params:xml:ns:yang:ietf-yang-types"; 170 prefix "yang"; 172 organization 173 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 175 contact 176 "WG Web: 177 WG List: 179 WG Chair: David Partain 180 182 WG Chair: David Kessens 183 185 Editor: Juergen Schoenwaelder 186 "; 188 description 189 "This module contains a collection of generally useful derived 190 YANG data types. 192 Copyright (c) 2010 IETF Trust and the persons identified as 193 the document authors. All rights reserved. 195 Redistribution and use in source and binary forms, with or 196 without modification, is permitted pursuant to, and subject 197 to the license terms contained in, the Simplified BSD License 198 set forth in Section 4.c of the IETF Trust's Legal Provisions 199 Relating to IETF Documents 200 (http://trustee.ietf.org/license-info). 202 This version of this YANG module is part of RFC XXXX; see 203 the RFC itself for full legal notices."; 204 // RFC Ed.: replace XXXX with actual RFC number and remove this note 206 revision 2010-04-24 { 207 description 208 "Initial revision."; 209 reference 210 "RFC XXXX: Common YANG Data Types"; 212 } 213 // RFC Ed.: replace XXXX with actual RFC number and remove this note 215 /*** collection of counter and gauge types ***/ 217 typedef counter32 { 218 type uint32; 219 description 220 "The counter32 type represents a non-negative integer 221 which monotonically increases until it reaches a 222 maximum value of 2^32-1 (4294967295 decimal), when it 223 wraps around and starts increasing again from zero. 225 Counters have no defined `initial' value, and thus, a 226 single value of a counter has (in general) no information 227 content. Discontinuities in the monotonically increasing 228 value normally occur at re-initialization of the 229 management system, and at other times as specified in the 230 description of a schema node using this type. If such 231 other times can occur, for example, the creation of an 232 a schema node of type counter32 at times other than 233 re-initialization, then a corresponding schema node 234 should be defined, with an appropriate type, to indicate 235 the last discontinuity. 237 The counter32 type should not be used for configuration 238 schema nodes. A default statement SHOULD NOT be used in 239 combination with the type counter32. 241 This type is in the value set and its semantics equivalent 242 to the Counter32 type of the SMIv2."; 243 reference 244 "RFC 2578: Structure of Management Information Version 2 (SMIv2)"; 245 } 247 typedef zero-based-counter32 { 248 type yang:counter32; 249 default "0"; 250 description 251 "The zero-based-counter32 type represents a counter32 252 which has the defined `initial' value zero. 254 A schema node of this type will be set to zero(0) on creation 255 and will thereafter increase monotonically until it reaches 256 a maximum value of 2^32-1 (4294967295 decimal), when it 257 wraps around and starts increasing again from zero. 259 Provided that an application discovers a new schema node 260 of this type within the minimum time to wrap, it can use the 261 initial value as a delta. It is important for a management 262 station to be aware of this minimum time and the actual time 263 between polls, and to discard data if the actual time is too 264 long or there is no defined minimum time. 266 This type is in the value set and its semantics equivalent 267 to the ZeroBasedCounter32 textual convention of the SMIv2."; 268 reference 269 "RFC 4502: Remote Network Monitoring Management Information 270 Base Version 2 using SMIv2"; 271 } 273 typedef counter64 { 274 type uint64; 275 description 276 "The counter64 type represents a non-negative integer 277 which monotonically increases until it reaches a 278 maximum value of 2^64-1 (18446744073709551615 decimal), 279 when it wraps around and starts increasing again from zero. 281 Counters have no defined `initial' value, and thus, a 282 single value of a counter has (in general) no information 283 content. Discontinuities in the monotonically increasing 284 value normally occur at re-initialization of the 285 management system, and at other times as specified in the 286 description of a schema node using this type. If such 287 other times can occur, for example, the creation of 288 a schema node of type counter64 at times other than 289 re-initialization, then a corresponding schema node 290 should be defined, with an appropriate type, to indicate 291 the last discontinuity. 293 The counter64 type should not be used for configuration 294 schema nodes. A default statement SHOULD NOT be used in 295 combination with the type counter64. 297 This type is in the value set and its semantics equivalent 298 to the Counter64 type of the SMIv2."; 299 reference 300 "RFC 2578: Structure of Management Information Version 2 (SMIv2)"; 301 } 303 typedef zero-based-counter64 { 304 type yang:counter64; 305 default "0"; 306 description 307 "The zero-based-counter64 type represents a counter64 which 308 has the defined `initial' value zero. 310 A schema node of this type will be set to zero(0) on creation 311 and will thereafter increase monotonically until it reaches 312 a maximum value of 2^64-1 (18446744073709551615 decimal), 313 when it wraps around and starts increasing again from zero. 315 Provided that an application discovers a new schema node 316 of this type within the minimum time to wrap, it can use the 317 initial value as a delta. It is important for a management 318 station to be aware of this minimum time and the actual time 319 between polls, and to discard data if the actual time is too 320 long or there is no defined minimum time. 322 This type is in the value set and its semantics equivalent 323 to the ZeroBasedCounter64 textual convention of the SMIv2."; 324 reference 325 "RFC 2856: Textual Conventions for Additional High Capacity 326 Data Types"; 327 } 329 typedef gauge32 { 330 type uint32; 331 description 332 "The gauge32 type represents a non-negative integer, which 333 may increase or decrease, but shall never exceed a maximum 334 value, nor fall below a minimum value. The maximum value 335 cannot be greater than 2^32-1 (4294967295 decimal), and 336 the minimum value cannot be smaller than 0. The value of 337 a gauge32 has its maximum value whenever the information 338 being modeled is greater than or equal to its maximum 339 value, and has its minimum value whenever the information 340 being modeled is smaller than or equal to its minimum value. 341 If the information being modeled subsequently decreases 342 below (increases above) the maximum (minimum) value, the 343 gauge32 also decreases (increases). 345 This type is in the value set and its semantics equivalent 346 to the Gauge32 type of the SMIv2."; 347 reference 348 "RFC 2578: Structure of Management Information Version 2 (SMIv2)"; 349 } 351 typedef gauge64 { 352 type uint64; 353 description 354 "The gauge64 type represents a non-negative integer, which 355 may increase or decrease, but shall never exceed a maximum 356 value, nor fall below a minimum value. The maximum value 357 cannot be greater than 2^64-1 (18446744073709551615), and 358 the minimum value cannot be smaller than 0. The value of 359 a gauge64 has its maximum value whenever the information 360 being modeled is greater than or equal to its maximum 361 value, and has its minimum value whenever the information 362 being modeled is smaller than or equal to its minimum value. 363 If the information being modeled subsequently decreases 364 below (increases above) the maximum (minimum) value, the 365 gauge64 also decreases (increases). 367 This type is in the value set and its semantics equivalent 368 to the CounterBasedGauge64 SMIv2 textual convention defined 369 in RFC 2856"; 370 reference 371 "RFC 2856: Textual Conventions for Additional High Capacity 372 Data Types"; 373 } 375 /*** collection of identifier related types ***/ 377 typedef object-identifier { 378 type string { 379 pattern '(([0-1](\.[1-3]?[0-9]))|(2\.(0|([1-9]\d*))))' 380 + '(\.(0|([1-9]\d*)))*'; 381 } 382 description 383 "The object-identifier type represents administratively 384 assigned names in a registration-hierarchical-name tree. 386 Values of this type are denoted as a sequence of numerical 387 non-negative sub-identifier values. Each sub-identifier 388 value MUST NOT exceed 2^32-1 (4294967295). Sub-identifiers 389 are separated by single dots and without any intermediate 390 white space. 392 The ASN.1 standard restricts the value space of the first 393 sub-identifier to 0, 1, or 2. Furthermore, the value space 394 of the second sub-identifier is restricted to the range 395 0 to 39 if the first sub-identifier is 0 or 1. Finally, 396 the ASN.1 standard requires that an object identifier 397 has always at least two sub-identifier. The pattern 398 captures these restrictions. 400 Although the number of sub-identifiers is not limited, 401 module designers should realize that there may be 402 implementations that stick with the SMIv2 limit of 128 403 sub-identifiers. 405 This type is a superset of the SMIv2 OBJECT IDENTIFIER type 406 since it is not restricted to 128 sub-identifiers. Hence, 407 this type SHOULD NOT be used to represent the SMIv2 OBJECT 408 IDENTIFIER type, the object-identifier-128 type SHOULD be 409 used instead."; 410 reference 411 "ISO/IEC 9834-1: Information technology -- Open Systems 412 Interconnection -- Procedures for the operation of OSI 413 Registration Authorities: General procedures and top 414 arcs of the ASN.1 Object Identifier tree"; 415 } 417 typedef object-identifier-128 { 418 type object-identifier { 419 pattern '\d*(\.\d*){1,127}'; 420 } 421 description 422 "This type represents object-identifiers restricted to 128 423 sub-identifiers. 425 This type is in the value set and its semantics equivalent 426 to the OBJECT IDENTIFIER type of the SMIv2."; 427 reference 428 "RFC 2578: Structure of Management Information Version 2 (SMIv2)"; 429 } 431 /*** collection of date and time related types ***/ 433 typedef date-and-time { 434 type string { 435 pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?' 436 + '(Z|[\+|-]\d{2}:\d{2})'; 437 } 438 description 439 "The date-and-time type is a profile of the ISO 8601 440 standard for representation of dates and times using the 441 Gregorian calendar. The profile is defined by the 442 date-time production in section 5.6 of RFC 3339. 444 The date-and-time type is compatible with the dateTime XML 445 schema type with the following notable exceptions: 447 (a) The date-and-time type does not allow negative years. 449 (b) The date-and-time time-offset -00:00 indicates an unknown 450 time zone (see RFC 3339) while -00:00 and +00:00 and Z all 451 represent the same time zone in dateTime. 453 (c) The canonical format (see below) of data-and-time values 454 differs from the canonical format used by the dateTime XML 455 schema type, which requires all times to be in UTC using the 456 time-offset 'Z'. 458 This type is not equivalent to the DateAndTime textual 459 convention of the SMIv2 since RFC 3339 uses a different 460 separator between full-date and full-time and provides 461 higher resolution of time-secfrac. 463 The canonical format for date-and-time values with a known time 464 zone uses a numeric time zone offset that is calculated using 465 the device's configured known offset to UTC time. A change of 466 the device's offset to UTC time will cause date-and-time values 467 to change accordingly. Such changes might happen periodically 468 in case a server follows automatically daylight saving time 469 (DST) time zone offset changes. The canonical format for 470 date-and-time values with an unknown time zone (usually refering 471 to the notion of local time) uses the time-offset -00:00."; 472 reference 473 "RFC 3339: Date and Time on the Internet: Timestamps 474 RFC 2579: Textual Conventions for SMIv2 475 W3C REC-xmlschema-2-20041028: XML Schema Part 2: Datatypes 476 Second Edition"; 477 } 479 typedef timeticks { 480 type uint32; 481 description 482 "The timeticks type represents a non-negative integer which 483 represents the time, modulo 2^32 (4294967296 decimal), in 484 hundredths of a second between two epochs. When a schema 485 node is defined which uses this type, the description of 486 the schema node identifies both of the reference epochs. 488 This type is in the value set and its semantics equivalent 489 to the TimeTicks type of the SMIv2."; 490 reference 491 "RFC 2578: Structure of Management Information Version 2 (SMIv2)"; 492 } 494 typedef timestamp { 495 type yang:timeticks; 496 description 497 "The timestamp type represents the value of an associated 498 timeticks schema node at which a specific occurrence happened. 499 The specific occurrence must be defined in the description 500 of any schema node defined using this type. When the specific 501 occurrence occurred prior to the last time the associated 502 timeticks attribute was zero, then the timestamp value is 503 zero. Note that this requires all timestamp values to be 504 reset to zero when the value of the associated timeticks 505 attribute reaches 497+ days and wraps around to zero. 507 The associated timeticks schema node must be specified 508 in the description of any schema node using this type. 510 This type is in the value set and its semantics equivalent 511 to the TimeStamp textual convention of the SMIv2."; 512 reference 513 "RFC 2579: Textual Conventions for SMIv2"; 514 } 516 /*** collection of generic address types ***/ 518 typedef phys-address { 519 type string { 520 pattern '([0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*)?'; 521 } 522 description 523 "Represents media- or physical-level addresses represented 524 as a sequence octets, each octet represented by two hexadecimal 525 numbers. Octets are separated by colons. The canonical 526 representation uses lower-case characters. 528 This type is in the value set and its semantics equivalent 529 to the PhysAddress textual convention of the SMIv2."; 530 reference 531 "RFC 2579: Textual Conventions for SMIv2"; 532 } 534 typedef mac-address { 535 type string { 536 pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}'; 537 } 538 description 539 "The mac-address type represents an IEEE 802 MAC address. 540 The canonical representation uses lower-case characters. 542 This type is in the value set and its semantics equivalent to 543 the MacAddress textual convention of the SMIv2."; 544 reference 545 "IEEE 802: IEEE Standard for Local and Metropolitan Area 546 Networks: Overview and Architecture 547 RFC 2579: Textual Conventions for SMIv2"; 548 } 549 /*** collection of XML specific types ***/ 551 typedef xpath1.0 { 552 type string; 553 description 554 "This type represents an XPATH 1.0 expression. 556 When a schema node is defined which uses this type, the 557 description of the schema node MUST specify the XPath 558 context in which the XPath expression is evaluated."; 559 reference 560 "XPATH: XML Path Language (XPath) Version 1.0"; 561 } 563 } 565 567 4. Internet Specific Derived Types 569 file "ietf-inet-types@2010-04-24.yang" 571 module ietf-inet-types { 573 namespace "urn:ietf:params:xml:ns:yang:ietf-inet-types"; 574 prefix "inet"; 576 organization 577 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 579 contact 580 "WG Web: 581 WG List: 583 WG Chair: David Partain 584 586 WG Chair: David Kessens 587 589 Editor: Juergen Schoenwaelder 590 "; 592 description 593 "This module contains a collection of generally useful derived 594 YANG data types for Internet addresses and related things. 596 Copyright (c) 2010 IETF Trust and the persons identified as 597 the document authors. All rights reserved. 599 Redistribution and use in source and binary forms, with or 600 without modification, is permitted pursuant to, and subject 601 to the license terms contained in, the Simplified BSD License 602 set forth in Section 4.c of the IETF Trust's Legal Provisions 603 Relating to IETF Documents 604 (http://trustee.ietf.org/license-info). 606 This version of this YANG module is part of RFC XXXX; see 607 the RFC itself for full legal notices."; 608 // RFC Ed.: replace XXXX with actual RFC number and remove this note 610 revision 2010-04-24 { 611 description 612 "Initial revision."; 613 reference 614 "RFC XXXX: Common YANG Data Types"; 616 } 617 // RFC Ed.: replace XXXX with actual RFC number and remove this note 619 /*** collection of protocol field related types ***/ 621 typedef ip-version { 622 type enumeration { 623 enum unknown { 624 value "0"; 625 description 626 "An unknown or unspecified version of the Internet protocol."; 627 } 628 enum ipv4 { 629 value "1"; 630 description 631 "The IPv4 protocol as defined in RFC 791."; 632 } 633 enum ipv6 { 634 value "2"; 635 description 636 "The IPv6 protocol as defined in RFC 2460."; 637 } 638 } 639 description 640 "This value represents the version of the IP protocol. 642 This type is in the value set and its semantics equivalent 643 to the InetVersion textual convention of the SMIv2."; 644 reference 645 "RFC 791: Internet Protocol 646 RFC 2460: Internet Protocol, Version 6 (IPv6) Specification 647 RFC 4001: Textual Conventions for Internet Network Addresses"; 648 } 650 typedef dscp { 651 type uint8 { 652 range "0..63"; 653 } 654 description 655 "The dscp type represents a Differentiated Services Code-Point 656 that may be used for marking packets in a traffic stream. 658 This type is in the value set and its semantics equivalent 659 to the Dscp textual convention of the SMIv2."; 660 reference 661 "RFC 3289: Management Information Base for the Differentiated 662 Services Architecture 663 RFC 2474: Definition of the Differentiated Services Field 664 (DS Field) in the IPv4 and IPv6 Headers 665 RFC 2780: IANA Allocation Guidelines For Values In 666 the Internet Protocol and Related Headers"; 667 } 669 typedef ipv6-flow-label { 670 type uint32 { 671 range "0..1048575"; 672 } 673 description 674 "The flow-label type represents flow identifier or Flow Label 675 in an IPv6 packet header that may be used to discriminate 676 traffic flows. 678 This type is in the value set and its semantics equivalent 679 to the IPv6FlowLabel textual convention of the SMIv2."; 680 reference 681 "RFC 3595: Textual Conventions for IPv6 Flow Label 682 RFC 2460: Internet Protocol, Version 6 (IPv6) Specification"; 683 } 685 typedef port-number { 686 type uint16 { 687 range "0..65535"; 688 } 689 description 690 "The port-number type represents a 16-bit port number of an 691 Internet transport layer protocol such as UDP, TCP, DCCP or 692 SCTP. Port numbers are assigned by IANA. A current list of 693 all assignments is available from . 695 Note that the port number value zero is reserved by IANA. In 696 situations where the value zero does not make sense, it can 697 be excluded by subtyping the port-number type. 699 This type is in the value set and its semantics equivalent 700 to the InetPortNumber textual convention of the SMIv2."; 701 reference 702 "RFC 768: User Datagram Protocol 703 RFC 793: Transmission Control Protocol 704 RFC 4960: Stream Control Transmission Protocol 705 RFC 4340: Datagram Congestion Control Protocol (DCCP) 706 RFC 4001: Textual Conventions for Internet Network Addresses"; 707 } 709 /*** collection of autonomous system related types ***/ 711 typedef as-number { 712 type uint32; 713 description 714 "The as-number type represents autonomous system numbers 715 which identify an Autonomous System (AS). An AS is a set 716 of routers under a single technical administration, using 717 an interior gateway protocol and common metrics to route 718 packets within the AS, and using an exterior gateway 719 protocol to route packets to other ASs'. IANA maintains 720 the AS number space and has delegated large parts to the 721 regional registries. 723 Autonomous system numbers were originally limited to 16 724 bits. BGP extensions have enlarged the autonomous system 725 number space to 32 bits. This type therefore uses an uint32 726 base type without a range restriction in order to support 727 a larger autonomous system number space. 729 This type is in the value set and its semantics equivalent 730 to the InetAutonomousSystemNumber textual convention of 731 the SMIv2."; 732 reference 733 "RFC 1930: Guidelines for creation, selection, and registration 734 of an Autonomous System (AS) 735 RFC 4271: A Border Gateway Protocol 4 (BGP-4) 736 RFC 4893: BGP Support for Four-octet AS Number Space 737 RFC 4001: Textual Conventions for Internet Network Addresses"; 738 } 740 /*** collection of IP address and hostname related types ***/ 742 typedef ip-address { 743 type union { 744 type inet:ipv4-address; 745 type inet:ipv6-address; 746 } 747 description 748 "The ip-address type represents an IP address and is IP 749 version neutral. The format of the textual representations 750 implies the IP version."; 751 } 753 typedef ipv4-address { 754 type string { 755 pattern 756 '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}' 757 + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])' 758 + '(%[\p{N}\p{L}]+)?'; 759 } 760 description 761 "The ipv4-address type represents an IPv4 address in 762 dotted-quad notation. The IPv4 address may include a zone 763 index, separated by a % sign. 765 The zone index is used to disambiguate identical address 766 values. For link-local addresses, the zone index will 767 typically be the interface index number or the name of an 768 interface. If the zone index is not present, the default 769 zone of the device will be used. 771 The canonical format for the zone index is the numerical 772 format"; 773 } 775 typedef ipv6-address { 776 type string { 777 pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}' 778 + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|' 779 + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}' 780 + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))' 781 + '(%[\p{N}\p{L}]+)?'; 782 pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|' 783 + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)' 784 + '(%.+)?'; 785 } 786 description 787 "The ipv6-address type represents an IPv6 address in full, 788 mixed, shortened and shortened mixed notation. The IPv6 789 address may include a zone index, separated by a % sign. 791 The zone index is used to disambiguate identical address 792 values. For link-local addresses, the zone index will 793 typically be the interface index number or the name of an 794 interface. If the zone index is not present, the default 795 zone of the device will be used. 797 The canonical format of IPv6 addresses uses the compressed 798 format described in RFC 4291 section 2.2 item 2 with the 799 following additional rules: The :: substitution must be 800 applied to the longest sequence of all-zero 16-bit chunks 801 in an IPv6 address. If there is a tie, the first sequence 802 of all-zero 16-bit chunks is replaced by ::. Single 803 all-zero 16-bit chunks are not compressed. The canonical 804 format uses lower-case characters and leading zeros are 805 not allowed. The canonical format for the zone index is 806 the numerical format as described in RFC 4007 section 807 11.2."; 809 reference 810 "RFC 4291: IP Version 6 Addressing Architecture 811 RFC 4007: IPv6 Scoped Address Architecture 812 IDv6TREP: A Recommendation for IPv6 Address Text Representation"; 813 } 815 typedef ip-prefix { 816 type union { 817 type inet:ipv4-prefix; 818 type inet:ipv6-prefix; 819 } 820 description 821 "The ip-prefix type represents an IP prefix and is IP 822 version neutral. The format of the textual representations 823 implies the IP version."; 824 } 826 typedef ipv4-prefix { 827 type string { 828 pattern 829 '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}' 830 + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])' 831 + '/(([0-9])|([1-2][0-9])|(3[0-2]))'; 832 } 833 description 834 "The ipv4-prefix type represents an IPv4 address prefix. 835 The prefix length is given by the number following the 836 slash character and must be less than or equal to 32. 838 A prefix length value of n corresponds to an IP address 839 mask which has n contiguous 1-bits from the most 840 significant bit (MSB) and all other bits set to 0. 842 The canonical format of an IPv4 prefix has all bits of 843 the IPv4 address set to zero that are not part of the 844 IPv4 prefix."; 845 } 847 typedef ipv6-prefix { 848 type string { 849 pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}' 850 + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|' 851 + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}' 852 + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))' 853 + '(/(([0-9])|([0-9]{2})|(1[0-1][0-9])|(12[0-8])))'; 854 pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|' 855 + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)' 856 + '(/.+)'; 858 } 859 description 860 "The ipv6-prefix type represents an IPv6 address prefix. 861 The prefix length is given by the number following the 862 slash character and must be less than or equal 128. 864 A prefix length value of n corresponds to an IP address 865 mask which has n contiguous 1-bits from the most 866 significant bit (MSB) and all other bits set to 0. 868 The IPv6 address should have all bits that do not belong 869 to the prefix set to zero. 871 The canonical format of an IPv6 prefix has all bits of 872 the IPv6 address set to zero that are not part of the 873 IPv6 prefix. Furthermore, IPv6 address is represented 874 in the compressed format described in RFC 4291 section 875 2.2 item 2 with the following additional rules: The :: 876 substitution must be applied to the longest sequence of 877 all-zero 16-bit chunks in an IPv6 address. If there is 878 a tie, the first sequence of all-zero 16-bit chunks is 879 replaced by ::. Single all-zero 16-bit chunks are not 880 compressed. The canonical format uses lower-case 881 characters and leading zeros are not allowed."; 882 reference 883 "RFC 4291: IP Version 6 Addressing Architecture"; 884 } 886 /*** collection of domain name and URI types ***/ 888 typedef domain-name { 889 type string { 890 pattern '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*' 891 + '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)' 892 + '|\.'; 893 length "1..253"; 894 } 895 description 896 "The domain-name type represents a DNS domain name. The 897 name SHOULD be fully qualified whenever possible. 899 Internet domain names are only loosely specified. Section 900 3.5 of RFC 1034 recommends a syntax (modified in section 901 2.1 of RFC 1123). The pattern above is intended to allow 902 for current practise in domain name use, and some possible 903 future expansion. It is designed to hold various types of 904 domain names, including names used for A or AAAA records 905 (host names) and other records, such as SRV records. Note 906 that Internet host names have a stricter syntax (described 907 in RFC 952) than the DNS recommendations in RFCs 1034 and 908 1123, and that systems that want to store host names in 909 schema nodes using the domain-name type are recommended to 910 adhere to this stricter standard to ensure interoperability. 912 The encoding of DNS names in the DNS protocol is limited 913 to 255 characters. Since the encoding consists of labels 914 prefixed by a length bytes and there is a trailing NULL 915 byte, only 253 characters can appear in the textual dotted 916 notation. 918 The description clause of schema nodes using the domain-name 919 type MUST describe when and how these names are resolved to 920 IP addresses. Note that the resolution of a domain-name value 921 may require to query multiple DNS records (e.g., A for IPv4 922 and AAAA for IPv6). The order of the resolution process and 923 which DNS record takes precedence can either be defined 924 explicitely or it may depend on the configuration of the 925 resolver. 927 Domain-name values use the US-ASCII encoding. Their canonical 928 format uses lowercase US-ASCII characters. Internationalized 929 domain names MUST be encoded in punycode as described in RFC 930 3492"; 931 reference 932 "RFC 952: DoD Internet Host Table Specification 933 RFC 1034: Domain Names - Concepts and Facilities 934 RFC 1123: Requirements for Internet Hosts -- Application 935 and Support 936 RFC 2782: A DNS RR for specifying the location of services 937 (DNS SRV) 938 RFC 3490: Internationalizing Domain Names in Applications 939 (IDNA) 940 RFC 3492: Punycode: A Bootstring encoding of Unicode for 941 Internationalized Domain Names in Applications 942 (IDNA)"; 943 } 945 typedef host { 946 type union { 947 type inet:ip-address; 948 type inet:domain-name; 949 } 950 description 951 "The host type represents either an IP address or a DNS 952 domain name."; 953 } 954 typedef uri { 955 type string; 956 description 957 "The uri type represents a Uniform Resource Identifier 958 (URI) as defined by STD 66. 960 Objects using the uri type MUST be in US-ASCII encoding, 961 and MUST be normalized as described by RFC 3986 Sections 962 6.2.1, 6.2.2.1, and 6.2.2.2. All unnecessary 963 percent-encoding is removed, and all case-insensitive 964 characters are set to lowercase except for hexadecimal 965 digits, which are normalized to uppercase as described in 966 Section 6.2.2.1. 968 The purpose of this normalization is to help provide 969 unique URIs. Note that this normalization is not 970 sufficient to provide uniqueness. Two URIs that are 971 textually distinct after this normalization may still be 972 equivalent. 974 Objects using the uri type may restrict the schemes that 975 they permit. For example, 'data:' and 'urn:' schemes 976 might not be appropriate. 978 A zero-length URI is not a valid URI. This can be used to 979 express 'URI absent' where required. 981 This type is in the value set and its semantics equivalent 982 to the Uri SMIv2 textual convention defined in RFC 5017."; 983 reference 984 "RFC 3986: Uniform Resource Identifier (URI): Generic Syntax 985 RFC 3305: Report from the Joint W3C/IETF URI Planning Interest 986 Group: Uniform Resource Identifiers (URIs), URLs, 987 and Uniform Resource Names (URNs): Clarifications 988 and Recommendations 989 RFC 5017: MIB Textual Conventions for Uniform Resource 990 Identifiers (URIs)"; 991 } 993 } 995 997 5. IANA Considerations 999 This document registers two URIs in the IETF XML registry [RFC3688]. 1000 Following the format in RFC 3688, the following registration is 1001 requested. 1003 URI: urn:ietf:params:xml:ns:yang:ietf-yang-types 1004 URI: urn:ietf:params:xml:ns:yang:ietf-inet-types 1006 Registrant Contact: The NETMOD WG of the IETF. 1008 XML: N/A, the requested URI is an XML namespace. 1010 This document registers two YANG modules in the YANG Module Names 1011 registry [YANG]. 1013 name: ietf-yang-types 1014 namespace: urn:ietf:params:xml:ns:yang:ietf-yang-types 1015 prefix: yang 1016 reference: RFCXXXX 1018 name: ietf-inet-types 1019 namespace: urn:ietf:params:xml:ns:yang:ietf-inet-types 1020 prefix: inet 1021 reference: RFCXXXX 1023 6. Security Considerations 1025 This document defines common data types using the YANG data modeling 1026 language. The definitions themselves have no security impact on the 1027 Internet but the usage of these definitions in concrete YANG modules 1028 might have. The security considerations spelled out in the YANG 1029 specification [YANG] apply for this document as well. 1031 7. Contributors 1033 The following people contributed significantly to the initial version 1034 of this draft: 1036 - Andy Bierman (Netconf Central) 1037 - Martin Bjorklund (Tail-f Systems) 1038 - Balazs Lengyel (Ericsson) 1039 - David Partain (Ericsson) 1040 - Phil Shafer (Juniper Networks) 1042 8. Acknowledgments 1044 The editor wishes to thank the following individuals for providing 1045 helpful comments on various versions of this document: Ladislav 1046 Lhotka, Lars-Johan Liman, Dan Romascanu. 1048 9. References 1050 9.1. Normative References 1052 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1053 Requirement Levels", BCP 14, RFC 2119, March 1997. 1055 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 1056 Internet: Timestamps", RFC 3339, July 2002. 1058 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 1059 for Internationalized Domain Names in Applications 1060 (IDNA)", RFC 3492, March 2003. 1062 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1063 January 2004. 1065 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1066 Resource Identifier (URI): Generic Syntax", STD 66, 1067 RFC 3986, January 2005. 1069 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 1070 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 1071 March 2005. 1073 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1074 Architecture", RFC 4291, February 2006. 1076 [XPATH] Clark, J. and S. DeRose, "XML Path Language (XPath) 1077 Version 1.0", World Wide Web Consortium 1078 Recommendation REC-xpath-19991116, November 1999, 1079 . 1081 [YANG] Bjorklund, M., Ed., "YANG - A data modeling language for 1082 NETCONF", draft-ietf-netmod-yang-12 (work in progress). 1084 9.2. Informative References 1086 [IDv6TREP] 1087 Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1088 Address Text Representation", 1089 draft-ietf-6man-text-addr-representation-07 (work in 1090 progress). 1092 [IEEE802] IEEE, "IEEE Standard for Local and Metropolitan Area 1093 Networks: Overview and Architecture", IEEE Std. 802-2001. 1095 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1096 August 1980. 1098 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1099 September 1981. 1101 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1102 RFC 793, September 1981. 1104 [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet 1105 host table specification", RFC 952, October 1985. 1107 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1108 STD 13, RFC 1034, November 1987. 1110 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 1111 and Support", STD 3, RFC 1123, October 1989. 1113 [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, 1114 selection, and registration of an Autonomous System (AS)", 1115 BCP 6, RFC 1930, March 1996. 1117 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1118 (IPv6) Specification", RFC 2460, December 1998. 1120 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1121 "Definition of the Differentiated Services Field (DS 1122 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1123 December 1998. 1125 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1126 Schoenwaelder, Ed., "Structure of Management Information 1127 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 1129 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1130 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 1131 STD 58, RFC 2579, April 1999. 1133 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 1134 Values In the Internet Protocol and Related Headers", 1135 BCP 37, RFC 2780, March 2000. 1137 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1138 specifying the location of services (DNS SRV)", RFC 2782, 1139 February 2000. 1141 [RFC2856] Bierman, A., McCloghrie, K., and R. Presuhn, "Textual 1142 Conventions for Additional High Capacity Data Types", 1143 RFC 2856, June 2000. 1145 [RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information 1146 Base for the Differentiated Services Architecture", 1147 RFC 3289, May 2002. 1149 [RFC3305] Mealling, M. and R. Denenberg, "Report from the Joint W3C/ 1150 IETF URI Planning Interest Group: Uniform Resource 1151 Identifiers (URIs), URLs, and Uniform Resource Names 1152 (URNs): Clarifications and Recommendations", RFC 3305, 1153 August 2002. 1155 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 1156 "Internationalizing Domain Names in Applications (IDNA)", 1157 RFC 3490, March 2003. 1159 [RFC3595] Wijnen, B., "Textual Conventions for IPv6 Flow Label", 1160 RFC 3595, September 2003. 1162 [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. 1163 Schoenwaelder, "Textual Conventions for Internet Network 1164 Addresses", RFC 4001, February 2005. 1166 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1167 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1169 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1170 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 1172 [RFC4502] Waldbusser, S., "Remote Network Monitoring Management 1173 Information Base Version 2", RFC 4502, May 2006. 1175 [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, 1176 December 2006. 1178 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 1179 Number Space", RFC 4893, May 2007. 1181 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 1182 RFC 4960, September 2007. 1184 [RFC5017] McWalter, D., "MIB Textual Conventions for Uniform 1185 Resource Identifiers (URIs)", RFC 5017, September 2007. 1187 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1188 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1189 May 2008. 1191 Author's Address 1193 Juergen Schoenwaelder (editor) 1194 Jacobs University 1196 Email: j.schoenwaelder@jacobs-university.de