idnits 2.17.1 draft-ietf-idr-as-representation-01.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 138. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 149. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 156. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 162. 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 (September 23, 2008) is 5666 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) 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 IDR G. Huston 3 Internet-Draft G. Michaelson 4 Intended status: Standards Track APNIC 5 Expires: March 27, 2009 September 23, 2008 7 Textual Representation of AS Numbers 8 draft-ietf-idr-as-representation-01.txt 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 March 27, 2009. 35 Abstract 37 A textual representation for Autonomous System (AS) numbers is 38 defined as the decimal value of the AS Number. This textual 39 representation is to be used by all documents, systems and user 40 interfaces referring to AS numbers. 42 1. Introduction 44 A textual representation for Autonomous System (AS) numbers is 45 defined as the decimal value of the AS Number. This textual 46 representation is to be used by all documents, systems and user 47 interfaces referring to AS numbers. 49 This document notes a number of potential representation formats and 50 proposes the adoption of a decimal value notation for AS numbers, or 51 "asplain" according to the representation taxonomy described here. 53 2. Taxonomy of Representation Formats 55 A taxonomy of representation for AS numbers is as follows: 57 asplain 58 refers to a syntax scheme of representing all AS numbers using 59 decimal integer notation. Using asplain notation an AS number of 60 value 65526 would be represented as the string "65526" and an AS 61 number of value 65546 would be represented as the string "65546". 63 asdot+ 64 refers to a syntax scheme of representing all AS numbers using a 65 notation of two integer values joined by a period character: .. Using asdot+ notation, an AS number of value 65526 68 would be represented as the string "0.65526" and an AS number of 69 value 65546 would be represented as the string "1.10". 71 asdot 72 refers to a syntax scheme of representing AS number values less 73 than 65536 using asplain notation and representing AS number 74 values equal to or greater than 65536 using asdot+ notation. 75 Using asdot notation, an AS number of value 65526 would be 76 represented as the string "65526" and an AS number of value 65546 77 would be represented as the string "1.10". 79 3. Representation of AS Number Values 81 To avoid confusion, a single textual notation is useful for 82 documentation, configuration systems, reports, and external tools and 83 information repositories. The decimal value representation, or 84 "asplain" is proposed as the textual notation to use for AS Numbers. 86 The "asplain" representation represents the number as its decimal 87 value, without any field delimiter, corresponding to the lack of any 88 internal structure required by the use of AS numbers in the inter- 89 domain routing context. 91 4. IANA Considerations 93 IANA Registries should use decimal representation ("asplain") for AS 94 numbers. 96 5. Security Considerations 98 This document does not refer to matters associated with security of 99 routing systems. 101 6. Acknowledgments 103 The terminology of "asplain", "asdot" and "asdot+" was originally 104 devised and described by Juergen Kammer in January 2007 [KAMMER2007]. 106 7. Informative References 108 [KAMMER2007] 109 Kammer, J., "AS Number Formats", Jan 2007, 110 . 112 Authors' Addresses 114 Geoff Huston 115 Asia Pacific Network Information Centre 117 Email: gih@apnic.net 119 George Michaelson 120 Asia Pacific Network Information Centre 122 Email: ggm@apnic.net 124 Full Copyright Statement 126 Copyright (C) The IETF Trust (2008). 128 This document is subject to the rights, licenses and restrictions 129 contained in BCP 78, and except as set forth therein, the authors 130 retain all their rights. 132 This document and the information contained herein are provided on an 133 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 134 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 135 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 136 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 137 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 138 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 140 Intellectual Property 142 The IETF takes no position regarding the validity or scope of any 143 Intellectual Property Rights or other rights that might be claimed to 144 pertain to the implementation or use of the technology described in 145 this document or the extent to which any license under such rights 146 might or might not be available; nor does it represent that it has 147 made any independent effort to identify any such rights. Information 148 on the procedures with respect to rights in RFC documents can be 149 found in BCP 78 and BCP 79. 151 Copies of IPR disclosures made to the IETF Secretariat and any 152 assurances of licenses to be made available, or the result of an 153 attempt made to obtain a general license or permission for the use of 154 such proprietary rights by implementers or users of this 155 specification can be obtained from the IETF on-line IPR repository at 156 http://www.ietf.org/ipr. 158 The IETF invites any interested party to bring to its attention any 159 copyrights, patents or patent applications, or other proprietary 160 rights that may cover technology that may be required to implement 161 this standard. Please address the information to the IETF at 162 ietf-ipr@ietf.org.