idnits 2.17.1 draft-michaelson-as-representation-00.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 151. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 162. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 169. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 175. 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 : ---------------------------------------------------------------------------- No issues found here. 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 28, 2008) is 5751 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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 Intended status: Best Current APNIC 5 Practice July 28, 2008 6 Expires: January 29, 2009 8 Textual Representation of AS Numbers 9 draft-michaelson-as-representation-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 29, 2009. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 A textual representation for Autonomous System (AS) numbers is 43 defined using "asdot" notation. This textual representation is to be 44 used by all documents, systems and user interfaces referring to AS 45 numbers. 47 1. Introduction 49 A textual representation for Autonomous System (AS) numbers is 50 defined using "asdot" notation. This textual representation is to be 51 used by all documents, systems and user interfaces referring to AS 52 numbers. 54 This document notes a number of potential representation formats and 55 proposes the adoption of "asdot" notation, according to the 56 representation taxonomy described here. 58 2. Taxonomy of Representation Formats 60 A taxonomy of representation for AS numbers is as follows: 62 asplain 63 refers to a syntax scheme of representing all AS numbers using 64 decimal integer notation. Using asplain notation an AS number of 65 value 65526 would be represented as the string "65526" and as AS 66 number of value 65546 would be represented as the string "65546". 68 asdot+ 69 refers to a syntax scheme of representing all AS numbers using a 70 notation of two integer values joined by a period character: .. Using asdot+ notation, an AS number of value 65526 73 would be represented as the string "0.65526" and an AS number of 74 value 65546 would be represented as the string "1.10". 76 asdot 77 refers to a syntax scheme of representing AS number values less 78 than 65536 using asplain notation and representing AS number 79 values equal to or greater than 65536 using asdot+ notation. 80 Using asdot notation, an AS number of value 65526 would be 81 represented as the string "65526" and as AS number of value 65546 82 would be represented as the string "1.10". 84 3. Representation of AS Number Values 86 To avoid confusion, a single textual notation is useful for 87 documentation, configuration systems, reports, and external tools and 88 information repositories. The dotted decimal value representation, 89 or "asdot" is proposed as the textual notation to use for AS Numbers. 91 This notation allows explicit delineation between the set of 16-bit 92 AS numbers and the expansion set of numbers with non-zero values in 93 the high order 16 bits of the 32 bit representation of the AS number 94 value. The "asdot" representation may reduce the potential for 95 transription errors on the part of network operators 97 4. IANA Considerations 99 IANA Registries should use dotted decimal representation ("asdot") 100 for AS numbers. 102 5. Security Considerations 104 This document does not refer to matters associated with security of 105 routing systems. 107 6. Acknowledgments 109 The terminology of "asplain", "asdot" and "asdot+" was originally 110 devised and described by Juergen Kammer in January 2007 [KAMMER2007]. 112 7. Informative References 114 [KAMMER2007] 115 Kammer, J., "AS Number Formats", Jan 2007, 116 . 118 Authors' Addresses 120 George Michaelson 121 Asia Pacific Network Information Centre 122 Level 1, 33 Park Road 123 Milton, Queensland 4064 124 AU 126 Phone: +61 7 3858 3100 127 Email: ggm@apnic.net 128 Geoff Huston 129 Asia Pacific Network Information Centre 130 Level 1, 33 Park Road 131 Milton, Queensland 4064 132 AU 134 Phone: +61 7 3858 3100 135 Email: gih@apnic.net 137 Full Copyright Statement 139 Copyright (C) The IETF Trust (2008). 141 This document is subject to the rights, licenses and restrictions 142 contained in BCP 78, and except as set forth therein, the authors 143 retain all their rights. 145 This document and the information contained herein are provided on an 146 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 147 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 148 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 149 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 150 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 151 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 153 Intellectual Property 155 The IETF takes no position regarding the validity or scope of any 156 Intellectual Property Rights or other rights that might be claimed to 157 pertain to the implementation or use of the technology described in 158 this document or the extent to which any license under such rights 159 might or might not be available; nor does it represent that it has 160 made any independent effort to identify any such rights. Information 161 on the procedures with respect to rights in RFC documents can be 162 found in BCP 78 and BCP 79. 164 Copies of IPR disclosures made to the IETF Secretariat and any 165 assurances of licenses to be made available, or the result of an 166 attempt made to obtain a general license or permission for the use of 167 such proprietary rights by implementers or users of this 168 specification can be obtained from the IETF on-line IPR repository at 169 http://www.ietf.org/ipr. 171 The IETF invites any interested party to bring to its attention any 172 copyrights, patents or patent applications, or other proprietary 173 rights that may cover technology that may be required to implement 174 this standard. Please address the information to the IETF at 175 ietf-ipr@ietf.org. 177 Acknowledgment 179 Funding for the RFC Editor function is provided by the IETF 180 Administrative Support Activity (IASA).