idnits 2.17.1 draft-michaelson-4byte-as-representation-03.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 260. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 271. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 278. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 284. 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 (May 29, 2007) is 6177 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: November 30, 2007 APNIC 5 May 29, 2007 7 Canonical Textual Representation of Four-octet AS Numbers 8 draft-michaelson-4byte-as-representation-03 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 November 30, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 A single textual representation for four-octet Autonomous System (AS) 42 numbers is defined. The syntax chosen avoids collision with Border 43 Gateway Protocol (BGP) community string parsing of AS numbers. It is 44 recommended that this textual representation be used by all 45 documents, systems and user interfaces referring to four-octet AS 46 numbers. 48 1. Introduction 50 A single textual representation for four-octet Autonomous System (AS) 51 numbers is defined. The syntax chosen avoids collision with Border 52 Gateway Protocol (BGP) community string parsing of AS numbers. 54 A number of forms of representation have been discussed in various 55 routing forums, and this document provides a taxonomy of the various 56 representations that have been considered, and recommends the 57 adoption of a textual representation scheme termed "asdot" notation. 59 It is recommended that only this "asdot" textual representation be 60 used by all documents, systems and user interfaces referring to four- 61 octet AS numbers. 63 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: < 74 high order 16-bit value in decimal > . < low order 16-bit value in 75 decimal >. Using asdot+ notation, an AS number of value 65526 76 would be represented as the string "0.65526" and as 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 that changes existing use would represent an 106 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 values expressed in 118 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 and the 127 representation of AS numbers in BGP community attributes would be 128 ambiguous as a result of this 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 139 introduces the increased risk of transcription error with these 140 numbers. 142 The asdot representation does not present these problems. 144 5. IANA Considerations 146 [Note: not for publication. No changes are proposed for the IANA, as 147 the IANA AS number registry, 148 http://www.iana.org/assignments/as-numbers, already uses asdot 149 notation.] 151 6. Acknowledgements 153 The text of the definition of a four-octet AS is taken from 154 [RIPE2005-12] 156 The terminology of "asplain", "asdot" and "asdot+" was originally 157 devised and described by Juergen Kammer in January 2007 [KAMMER2007] 159 The authors thank Rudiger Volk, Joao Damas, Joe Abley, Peter Koch and 160 Henk Uijterwaal for feedback and extensive comments on this document. 162 7. Implementation Notes 164 Many programming languages treat xxx.yyy numeric strings as real 165 number values on input, and convert the value internally to a 166 canonical floating point representation. Since the precision cannot 167 be guaranteed to be preserved, this risks changing the value of the 168 four-octet quantity on output, or by mis-placed arithmetical 169 calculation. 171 Care must be taken that asdot notation strings are treated as 172 'special-purpose strings' on input and output, and parsed correctly 173 to a four-octet quantity. It would be sensible to draft suitable 174 function definitions to define the transform from presentation to 175 internal value, as was done for IPv4 and IPv6 addresses with the 176 inet_pton() and inet_ntop() functions. 178 The [RFC2622] and [RFC4012] specifications, and systems which 179 manipulate AS numbers need to be reviewed for conformance with asdot 180 textual representation, and for the syntactic implications of this 181 representation. 183 8. Changes since the -01 draft 185 An IANA Considerations section has been added to amend an existing 186 registry. 188 The document now clarifies that it refers to a textual 189 representation, the binary representation used on-the-wire is 190 unaffected by this draft. 192 9. Changes since the -02 draft 194 The terms "asplain", "asdot" and "asdot+" have been used, reflecting 195 current discussion on this topic. 197 An IANA Considerations section has been removed as the AS number 198 registry uses asdot notation. 200 10. References 202 10.1. Normative References 204 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-Octet AS 205 Number Space", RFC 4893, May 2007. 207 10.2. Informative References 209 [KAMMER2007] 210 Kammer, J., "AS Number Formats", Jan 2007, 211 . 213 [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., 214 Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, 215 "Routing Policy Specification Language (RPSL)", RFC 2622, 216 June 1999. 218 [RFC4012] Blunk, L., Damas, J., Parent, F., and A. Robachevsky, 219 "Routing Policy Specification Language next generation 220 (RPSLng)", RFC 4012, March 2005. 222 [RIPE2005-12] 223 Huston, G., "four-octet AS Number Policy", Dec 2005, < 224 http://www.ripe.net/ripe/policies/proposals/2005-12.html>. 226 Authors' Addresses 228 George Michaelson 229 Asia Pacific Network Information Centre 230 Level 1, 33 Park Road 231 Milton, Queensland 4064 232 AU 234 Phone: +61 7 3858 3100 235 Email: ggm@apnic.net 237 Geoff Huston 238 Asia Pacific Network Information Centre 239 Level 1, 33 Park Road 240 Milton, Queensland 4064 241 AU 243 Phone: +61 7 3858 3100 244 Email: gih@apnic.net 246 Full Copyright Statement 248 Copyright (C) The IETF Trust (2007). 250 This document is subject to the rights, licenses and restrictions 251 contained in BCP 78, and except as set forth therein, the authors 252 retain all their rights. 254 This document and the information contained herein are provided on an 255 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 256 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 257 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 258 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 259 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 260 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 262 Intellectual Property 264 The IETF takes no position regarding the validity or scope of any 265 Intellectual Property Rights or other rights that might be claimed to 266 pertain to the implementation or use of the technology described in 267 this document or the extent to which any license under such rights 268 might or might not be available; nor does it represent that it has 269 made any independent effort to identify any such rights. Information 270 on the procedures with respect to rights in RFC documents can be 271 found in BCP 78 and BCP 79. 273 Copies of IPR disclosures made to the IETF Secretariat and any 274 assurances of licenses to be made available, or the result of an 275 attempt made to obtain a general license or permission for the use of 276 such proprietary rights by implementers or users of this 277 specification can be obtained from the IETF on-line IPR repository at 278 http://www.ietf.org/ipr. 280 The IETF invites any interested party to bring to its attention any 281 copyrights, patents or patent applications, or other proprietary 282 rights that may cover technology that may be required to implement 283 this standard. Please address the information to the IETF at 284 ietf-ipr@ietf.org. 286 Acknowledgment 288 Funding for the RFC Editor function is provided by the IETF 289 Administrative Support Activity (IASA).