Subject: Re: Last Call: <draft-housley-number-registries-02.txt> (Internet Numbers Registries) to Informational RFC

From: Russ Housley <[email-masked]>
Date: Mon, 3 Feb 2014 15:20:34 -0500

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: [email-masked]
> 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
> ================================================

---

From: David Farmer <[email-masked]>
Date: Mon, 03 Feb 2014 19:51:09 -0600

I believe if RFC 6890 were used as a template, a Draft could be put 
together quickly, I'm personally willing to help.  I don't see why it 
should be controversial within the community, but unfortunately those 
can be famous last words. :)

---

From: David Conrad <[email-masked]>
Date: Tue, 4 Feb 2014 06:25:54 -0700

David,

> 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 relev…

I suspect it might be a bit hard for Russ to take action on this point without a bit more info as to what you feel is awkward or what's missing.

> 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. 

While I don't oppose splitting the docs, I'm not sure it's necessary as I don't believe there's anything controversial in Russ's draft. What do you foresee as blocking the document or causing it to fail in either of its goals?

> 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.

Seem's a bit of overkill to me (I like short documents).

Regards,
-drc

---

From: Russ Housley <[email-masked]>
Date: Fri, 7 Feb 2014 10:52:39 -0500

I am posting an update that includes some of your comments.  If a document comes along that defines a special-purpose AS number registry before this document becomes and RFC, I wouldgladly reference it.  If not, such a document can revise the registry that this document establishes.

Russ

On Feb 3, 2014, at 8:51 PM, David Farmer wrote:

> I believe if RFC 6890 were used as a template, a Draft could be put together quickly, I'm personally willing to help.  I don't see why it should be controversial within the community, but unfortunately those can be famous last words. :)
>

---

From: David Farmer <[email-masked]>
Date: Fri, 07 Feb 2014 21:57:35 -0600

> I am posting an update that includes some of your comments.  If a document comes along that defines a special-purpose AS number registry before this document becomes and RFC, I wouldgladly referenc…

I have no objection to that.

As for the -04 revision, I'd prefer to see 
[draft-ietf-idr-last-as-reservation] as the reference for AS65535 in the 
table and not [RFC1930].  Another option, less preferred by me, is to 
reference both [draft-ietf-idr-last-as-reservation] and [RFC1930] for 
AS65535.  By the way, draft-ietf-idr-last-as-reservation successfully 
completed WGLC in IDR.

While it is true that RFC1930 reserved AS65535, the text of RFC1930, 
section 10, identifies AS65535 as part of the Private Use range. 
However, the IANA AS Numbers registry had listed AS65535 separately from 
that range for sometime, well before RFC6996, and maybe back to RFC1997 
or even before RFC1930, I don't know for sure.  RFC1997 indirectly uses 
AS65535 for the well-known BGP communities.  RFC6996 updates that part 
of RFC1930 to clarify that AS65535 is not properly part of the Private 
Use range.  Then draft-ietf-idr-last-as-reservation will clarify the 
purpose of and formalizes the reservations for both AS65535 and 
AS4294967295, and discusses RFC1997's use of AS65535.

I did a some searching for any other ASNs specified for a 
special-purposes in RFCs, the only thing I found that isn't already 
covered is; RFC6304, which specifies the use of AS112 to provide a 
distributed sink for DNS reverse queries of RFC1918 blocks and other 
similar queries.  However, since the IPv4 prefix also specified isn't 
listed in the IANA IPv4 Special-Purpose Address Registry, I don't think 
its necessary to list the ASN either.  But, I thought I would mention it 
just in case someone feels differently.

Finally, should the Abstract and Introduction also include the fact that 
the IANA Special-Purpose AS Numbers Registry is established by this 
document.

Thanks