idnits 2.17.1 draft-huston-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 149. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 160. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 167. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 173. 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 5752 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. Huston 3 Internet-Draft G. Michaelson 4 Intended status: Best Current APNIC 5 Practice July 28, 2008 6 Expires: January 29, 2009 8 Textual Representation of AS Numbers 9 draft-huston-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 as the decimal value of the AS Number. This textual 44 representation is to be used by all documents, systems and user 45 interfaces referring to AS numbers. 47 1. Introduction 49 A textual representation for Autonomous System (AS) numbers is 50 defined as the decimal value of the AS Number. This textual 51 representation is to be used by all documents, systems and user 52 interfaces referring to AS numbers. 54 This document notes a number of potential representation formats and 55 proposes the adoption of a decimal value notation for AS numbers, or 56 "asplain" according to the 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 decimal value representation, or 89 "asplain" is proposed as the textual notiation to use for AS Numbers. 91 The "asplain" representation represents the number as its decimal 92 value, without any field delimiter, corresponding to to lack of any 93 internal fields defined by the semantics AS numbers. 95 4. IANA Considerations 97 IANA Registries should use decimal representation ("asplain") for AS 98 numbers. 100 5. Security Considerations 102 This document does not refer to matters associated with security of 103 routing systems. 105 6. Acknowledgments 107 The terminology of "asplain", "asdot" and "asdot+" was originally 108 devised and described by Juergen Kammer in January 2007 [KAMMER2007]. 110 7. Informative References 112 [KAMMER2007] 113 Kammer, J., "AS Number Formats", Jan 2007, 114 . 116 Authors' Addresses 118 Geoff Huston 119 Asia Pacific Network Information Centre 120 Level 1, 33 Park Road 121 Milton, Queensland 4064 122 AU 124 Phone: +61 7 3858 3100 125 Email: gih@apnic.net 126 George Michaelson 127 Asia Pacific Network Information Centre 128 Level 1, 33 Park Road 129 Milton, Queensland 4064 130 AU 132 Phone: +61 7 3858 3100 133 Email: ggm@apnic.net 135 Full Copyright Statement 137 Copyright (C) The IETF Trust (2008). 139 This document is subject to the rights, licenses and restrictions 140 contained in BCP 78, and except as set forth therein, the authors 141 retain all their rights. 143 This document and the information contained herein are provided on an 144 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 145 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 146 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 147 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 148 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 149 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 151 Intellectual Property 153 The IETF takes no position regarding the validity or scope of any 154 Intellectual Property Rights or other rights that might be claimed to 155 pertain to the implementation or use of the technology described in 156 this document or the extent to which any license under such rights 157 might or might not be available; nor does it represent that it has 158 made any independent effort to identify any such rights. Information 159 on the procedures with respect to rights in RFC documents can be 160 found in BCP 78 and BCP 79. 162 Copies of IPR disclosures made to the IETF Secretariat and any 163 assurances of licenses to be made available, or the result of an 164 attempt made to obtain a general license or permission for the use of 165 such proprietary rights by implementers or users of this 166 specification can be obtained from the IETF on-line IPR repository at 167 http://www.ietf.org/ipr. 169 The IETF invites any interested party to bring to its attention any 170 copyrights, patents or patent applications, or other proprietary 171 rights that may cover technology that may be required to implement 172 this standard. Please address the information to the IETF at 173 ietf-ipr@ietf.org. 175 Acknowledgment 177 Funding for the RFC Editor function is provided by the IETF 178 Administrative Support Activity (IASA).