David: With respect to the AS Special purpose Registry, I might sit more comfortably in its own document, and then it could be referenced from this document. At this point, I'm concerned that he delay to this document would be quite unfortunate. Do you believe that such a document can be produced and approved rapidly? If not, then I'd like to see this document move forward and a subsequent document could make an update if there is community consensus to evolve the form of the special-purpose AS number registry. Russ > On 1/25/14, 14:14 , Adrian Farrel wrote: >> Hi Russ, >> >> Thanks for this. The -03 revision just posted addresses my comments. >> >> Adrian > > Russ, > > I also like the -03 revision, its has generally moved everything in the right direction. But I have a few comments on it. > > 1. The part about RFC2860 in Section 1 seems like an incomplete thought, at the very least it seems awkward to me. I'm really not sure what you are intending to say. But, I agree RFC2860 is relevant to the discussion. I'm just not sure you have nailed what to say about it. > > 2. I really like the idea of creating a "Special-Purpose AS Number Registry". However, it may be a better idea to spin-off the creation of a "Special-Purpose AS Number Registry" into a separate draft. I'm concerned that trying to do two important things in the same document will fail to achieve one or both of the important things. For instance the simple section 3 you have currently worries me. I'd really think RFC6890 is the template to use for creating a "Special-Purpose AS Number Registry", more below. > > If you spin-off the creation of a "Special-Purpose AS Number Registry", the following items are for that draft. > > 3. There is a draft in WG Last Call in the IDR that documents the reservations of ASNs 65535 and 4294967295, the "Last ASNs". > http://tools.ietf.org/html/draft-ietf-idr-last-as-reservation-01 > > 4. As I said, I like the idea of creating a "Special-Purpose AS Number Registry", but it should have certain information recoded about each AS number range. This information should be similar to the format described in Section 2.2.1 of RFC6890 for the "Special-Purpose IP Address Registries" for IPv4 and IPv6, that you reference elsewhere in the draft. > > First, there should be general information describing each of the special-purpose ASN ranges, essentially the first half of the columns specified in Section 2.2.1 of RFC6890; > > o AS Number Range - An AS number or range of AS numbers that has been > registered for a special purpose. > > o Name - A descriptive name for the special-purpose AS number range. > > o RFC - The RFC through which the special-purpose AS number range was > requested. > > o Allocation Date - The date upon which the special-purpose AS number > range was allocated. > > o Termination Date - The date upon which the allocation is to be > terminated. This field is applicable for limited-use allocations > only. > > Then, information specific to how the special-purpose ASNs are to be used. There may be others as well, I but I think these are the minimum. > > o Local - A boolean value indicating whether an AS number from the > allocated special-purpose AS Number range is valid when used as the > value of the "My Autonomous System" field of a BGP OPEN message, or > equivalently in the Capability Value of the "support for four-octet > AS number capability". > > o Global - A boolean value indicating whether an ASN from the allocated > special-purpose ASN range is valid in the AS_PATH or AS4_PATH > attributes when advertised to the global Internet. > > o Reserved-by-Protocol - A boolean value indicating whether the > special-purpose address block is reserved by BGP, itself. This > value is "TRUE" if the RFC that created the special-purpose ASN > range requires all compliant implementations to behave in a special > way when this ASN is used. > > I believe this is the table for these last three items > > ASN Range Local Global Reserved-by-Protocol > --------------------- ------- ------- -------------------- > 0 FALSE FALSE TRUE > 23456 TRUE[1] TRUE[1] TRUE > 64496-64511 FALSE FALSE FALSE > 64512-65534 TRUE FALSE FALSE > 65535 FALSE FALSE FALSE > 65536-65551 FALSE FALSE FALSE > 4200000000-4294967294 TRUE FALSE FALSE > 4294967295 FALSE FALSE FALSE > > [1] Only valid in a BGP OPEN message or AS_PATH, not valid within a > four-octet AS number capability negotiation or AS4_PATH. > > > Thanks. > > -- > ================================================ > David Farmer Email: farmer@xxxxxxx > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 1-612-626-0815 > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > ================================================