idnits 2.17.1 draft-michaelson-4byte-as-representation-05.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 283. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 294. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 301. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 307. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 113: '...ts containing AS numbers MUST use this...' RFC 2119 keyword, line 116: '...AS number values MUST accept asdot not...' RFC 2119 keyword, line 117: '... default, and SHOULD also be capable...' 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 (December 2, 2007) is 5990 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) ** Obsolete normative reference: RFC 4893 (Obsoleted by RFC 6793) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Michaelson 3 Internet-Draft G. Huston 4 Expires: June 4, 2008 APNIC 5 December 2, 2007 7 Canonical Textual Representation of Four-octet AS Numbers 8 draft-michaelson-4byte-as-representation-05 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 June 4, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 A taxonomy of textual representations for four-octet Autonomous 42 System (AS) numbers is defined. The 'asdot' textual representation 43 is recommended. The syntax chosen avoids ambiguity with Border 44 Gateway Protocol (BGP) community string representation of AS numbers. 45 It is recommended that this textual representation be used by all 46 documents, systems and user interfaces referring to four-octet AS 47 numbers. 49 1. Introduction 51 A single textual representation for four-octet Autonomous System (AS) 52 numbers is defined. The syntax chosen avoids ambiguity with Border 53 Gateway Protocol (BGP) community string representation of AS numbers. 55 A number of forms of representation have been discussed in various 56 routing forums, and this document provides a taxonomy of the various 57 representations that have been considered, and recommends the 58 adoption of a textual representation scheme termed "asdot" notation. 60 It is recommended that only this "asdot" textual representation be 61 used by all documents, systems and user interfaces referring to four- 62 octet AS numbers. 64 2. Terminology 65 asplain 66 refers to a syntax scheme of representing all AS numbers using 67 decimal integer notation. Using asplain notation an AS number of 68 value 65526 would be represented as the string "65526" and as AS 69 number of value 65546 would be represented as the string "65546". 71 asdot+ 72 refers to a syntax scheme of representing all AS numbers using a 73 notation of two integer values joined by a period character: .. Using asdot+ notation, an AS number of value 65526 76 would be represented as the string "0.65526" and an AS number of 77 value 65546 would be represented as the string "1.10". 79 asdot 80 refers to a syntax scheme of representing AS number values less 81 than 65536 using asplain notation and representing AS number 82 values equal to or greater than 65536 using asdot+ notation. 83 Using asdot notation, an AS number of value 65526 would be 84 represented as the string "65526" and as AS number of value 65546 85 would be represented as the string "1.10". 87 four-octet AS numbers 88 refers to AS numbers in the range 0.0 - 65535.65535 (using asdot+ 89 notation), or 0 - 4294967295 (using asplain notation). Four-octet 90 AS numbers are defined in [RFC4893] 92 four-octet only AS numbers 93 refers to AS numbers in the range 1.0 - 65535.65535 (using asdot+ 94 notation) or 65536 - 4294967295 (using asplain notation) 96 two-octet only AS numbers 97 refers to AS numbers in the range 0.0 - 0.65535 (using asdot+ 98 notation), or 0 - 65535 (using asplain notation). 100 3. Representation of AS Number Values 102 To avoid confusion, a single textual notation is useful for 103 documentation, configuration systems, reports, and external tools and 104 information repositories, but it is also necessary to observe that 105 any recommendation regarding notation that changes existing use would 106 represent an unwarranted imposition. 108 The asdot representation represents a reasonable compromise, in that 109 it preserves the current convention of using an asplain 110 representation for two-octet only AS number values, and proposes 111 using the asdot+ notation for four-octet only AS numbers. 113 All systems that generate reports containing AS numbers MUST use this 114 asdot notation to represent the AS number value. 116 Interfaces that accept AS number values MUST accept asdot notation by 117 default, and SHOULD also be capable of correctly interpreting values 118 expressed in asplain and asdot+ notation. 120 4. Consideration of Approaches to AS number representation 122 Initially, the ":" was proposed to separate the two-octet components 123 for the four-octet AS number value. 125 It was noted that this representation clashes with use of the ":" 126 character in community attribute syntax in BGP, and the 127 representation of AS numbers in BGP community attributes would be 128 ambiguous as a result of this choice of notation. 130 It has also been pointed out that Routing Protocol Specification 131 Language (RPSL) [RFC2622] [RFC4012] AS-Set objects use the ":" 132 character to denote sequences of AS objects forming a chain. Since 133 the AS object would have had the ":" character embedded in the 134 instance name, this would have required double-parsing to find four- 135 octet AS number in AS-Set chains. This also is not acceptable. 137 It was also noted that AS numbers are used by network operations 138 staff, and the larger values in the four-octet AS number set when 139 using asplain notation introduces the increased risk of transcription 140 error with these numbers. 142 5. IANA Considerations 144 [Note: not for publication. No changes are proposed for the IANA, as 145 the IANA AS number registry, 146 http://www.iana.org/assignments/as-numbers, already uses asdot 147 notation.] 149 6. Acknowledgments 151 The text of the definition of a four-octet AS is taken from 152 [RIPE2005-12]. 154 The terminology of "asplain", "asdot" and "asdot+" was originally 155 devised and described by Juergen Kammer in January 2007 [KAMMER2007]. 157 The authors thank Rudiger Volk, Joao Damas, Joe Abley, Peter Koch and 158 Henk Uijterwaal for feedback and extensive comments on this document. 160 7. Implementation Notes 162 Many programming languages treat xxx.yyy numeric strings as real 163 number values on input, and convert the value internally to a 164 canonical floating point representation. Since the precision cannot 165 be guaranteed to be preserved, this risks changing the value of the 166 four-octet quantity on output, or by mis-placed arithmetical 167 calculation. 169 Use of the POSIX 'regexp' function requires care, since the full-stop 170 character is used to denote 'any char' and can be matched by a 171 decimal digit. Thus AS1.1 can match AS101, AS121 etc, unless the dot 172 is escaped in the pattern match as AS1\.1 in this instance. This 173 risk has been present for some time, and depended on the textual 174 representation of an AS being 1:1 with the imputed binary value. In 175 reality, AS pattern matching should be interpreted, and applied to 176 the binary value, not a specific representation. 178 Care must be taken that asdot notation strings are treated as 179 'special-purpose strings' on input and output, and parsed correctly 180 to a four-octet quantity. It would be sensible to draft suitable 181 function definitions to define the transform from presentation to 182 internal value, as was done for IPv4 and IPv6 addresses with the 183 inet_pton() and inet_ntop() functions. 185 The [RFC2622] and [RFC4012] specifications, and systems which 186 manipulate AS numbers need to be reviewed for conformance with asdot 187 textual representation, and for the syntactic implications of this 188 representation. 190 8. Changes 192 [Note: This section is not for publication.] 194 8.1. Changes since the -01 draft 196 An IANA Considerations section has been added to amend an existing 197 registry. 199 The document now clarifies that it refers to a textual 200 representation, the binary representation used on-the-wire is 201 unaffected by this draft. 203 8.2. Changes since the -02 draft 205 The terms "asplain", "asdot" and "asdot+" have been used, reflecting 206 current discussion on this topic. 208 An IANA Considerations section has been removed, as the AS number 209 registry uses asdot notation and no further changes would be required 210 of the IANA registry according to the recommendation made here. 212 8.3. Changes since the -03 draft 214 Grammatical errors were corrected. 216 A spellcheck was run. 218 8.4. Changes since the -04 draft 220 More grammatical errors were corrected. 222 Commentary on REGEXP was added. 224 9. References 225 9.1. Normative References 227 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-Octet AS 228 Number Space", RFC 4893, May 2007. 230 9.2. Informative References 232 [KAMMER2007] 233 Kammer, J., "AS Number Formats", Jan 2007, 234 . 236 [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., 237 Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, 238 "Routing Policy Specification Language (RPSL)", RFC 2622, 239 June 1999. 241 [RFC4012] Blunk, L., Damas, J., Parent, F., and A. Robachevsky, 242 "Routing Policy Specification Language next generation 243 (RPSLng)", RFC 4012, March 2005. 245 [RIPE2005-12] 246 Huston, G., "four-octet AS Number Policy", Dec 2005, < 247 http://www.ripe.net/ripe/policies/proposals/2005-12.html>. 249 Authors' Addresses 251 George Michaelson 252 Asia Pacific Network Information Centre 253 Level 1, 33 Park Road 254 Milton, Queensland 4064 255 AU 257 Phone: +61 7 3858 3100 258 Email: ggm@apnic.net 260 Geoff Huston 261 Asia Pacific Network Information Centre 262 Level 1, 33 Park Road 263 Milton, Queensland 4064 264 AU 266 Phone: +61 7 3858 3100 267 Email: gih@apnic.net 269 Full Copyright Statement 271 Copyright (C) The IETF Trust (2007). 273 This document is subject to the rights, licenses and restrictions 274 contained in BCP 78, and except as set forth therein, the authors 275 retain all their rights. 277 This document and the information contained herein are provided on an 278 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 279 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 280 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 281 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 282 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 283 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 285 Intellectual Property 287 The IETF takes no position regarding the validity or scope of any 288 Intellectual Property Rights or other rights that might be claimed to 289 pertain to the implementation or use of the technology described in 290 this document or the extent to which any license under such rights 291 might or might not be available; nor does it represent that it has 292 made any independent effort to identify any such rights. Information 293 on the procedures with respect to rights in RFC documents can be 294 found in BCP 78 and BCP 79. 296 Copies of IPR disclosures made to the IETF Secretariat and any 297 assurances of licenses to be made available, or the result of an 298 attempt made to obtain a general license or permission for the use of 299 such proprietary rights by implementers or users of this 300 specification can be obtained from the IETF on-line IPR repository at 301 http://www.ietf.org/ipr. 303 The IETF invites any interested party to bring to its attention any 304 copyrights, patents or patent applications, or other proprietary 305 rights that may cover technology that may be required to implement 306 this standard. Please address the information to the IETF at 307 ietf-ipr@ietf.org. 309 Acknowledgment 311 Funding for the RFC Editor function is provided by the IETF 312 Administrative Support Activity (IASA).