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

From: David Conrad <[email-masked]>
Date: Fri, 3 Jan 2014 20:21:07 -0800

Hi Russ,

A few comments/suggestions on your draft:

Overall:  

I'm a bit uncomfortable with specifying the contents of registries within RFCs these days as they can become out of date even before they're published.  For example, it's likely there's going to be a reservation of IPv6 space for LISP EID prefixes in the near future but (I suspect) after your draft is published as an RFC.  Perhaps it would make more sense to reference IANA registries instead of listing the contents of what would be in those registries in the draft text, e.g., pointing to http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xml for IPv4 and http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml for IPv6 (and creating a special purpose registry for AS numbers)?

I find it curious that when talking about top-level domains, the criteria (according to RFC 6761) for reservation is "Standards Action" or "IESG Approval" but when talking about reserving Internet Number resources, the criteria is "IETF Review".  Any idea why there is a discrepancy?

Specific comments:

Section 2.1, second paragraph:

   The allocation and registration functions for all non-reserved AS
   numbers are handled by the Internet Numbers Registry System in
   accordance with policies developed by the Regional Internet
   Registries (RIRs).

I might suggest:

"The allocation and registration functions for all non-reserved AS numbers are currently handled by the Internet Numbers Registry System in accordance with policies developed via the Regional Internet Registries' (RIRs) public policy development processes."

Section 2.2, first paragraph:

   The allocation and registration functions for all non-reserved
   globally unique unicast IPv4 unicast addresses are handled by the
   Internet Numbers Registry System in accordance with policies
   developed by the Regional Internet Registries (RIRs).

Similar to the previous suggestion (dropping a redundant 'unicast'):

"The allocation and registration functions for all non-reserved globally unique unicast IPv4 addresses are currently handled by the Internet Numbers Registry System in accordance with policies developed via the RIRs' public policy development processes."

Section 2.3, second paragraph:

   The allocation and registration functions for all non-reserved
   globally unique unicast IPv6 unicast addresses are handled by the
   Internet Numbers Registry System in accordance with policies
   developed by the Regional Internet Registries (RIRs).

Similar to the previous suggestion (also dropping a redundant 'unicast'):

"The allocation and registration functions for all non-reserved globally unique unicast IPv6 addresses are currently handled by the Internet Numbers Registry System in accordance with policies developed via the RIRs' public policy development processes."

Section 3:

The parenthetical "(e.g., anycast)" may be a bit confusing/ambiguous.  What most people today think of anycast (i.e., "shared unicast") don't generally need to be treated specially by the Internet Numbers Registry System or the IETF.  I'd recommend just dropping the parenthetical.

Section 4:

While the statement there is truthful, perhaps should there be some mention of the potential implications of reserved space in the context of trying to identify sources of badness that are using reserved addresses or ASes?  E.g., perhaps recommending that care should be taken by operators to ensure that traffic sourced and/or destined to reserved addresses/ASNs is appropriate?

Hope this helps.

Regards,
-drc

---

From: Thomas Narten <[email-masked]>
Date: Mon, 06 Jan 2014 16:37:06 -0500

Overall, this document looks good. But a couple of suggestions.

As a general comment, I think the document should include a reference
wherever it states what a policy is (as defined elswhere).

>    Reservations of special-purpose AS Numbers are made through Internet
>    Standards actions.

Citation of where that policy is defined?

But then later, the document says::

> 3.  IANA Considerations
> 
>    "IETF Review" as defined in [RFC5226] is required to reserve special-
>    purpose AS numbers, IPv4 addresses, or IPv6 addresses.  Reserved AS
>    numbers, IPv4 addresses, or IPv6 addresses may be designated to
>    support testing, IETF experimental activities, or other special uses
>    (e.g., anycast).  These reservations are recorded in the relevant

which contradicts the previous statement.

Also, would be good to cite all the individual RFCs when restating
what the policy is for each registries listed above.

>    Reservation of special-purpose IPv4 addresses are made through
>    Internet Standards actions.  Reserved IPv4 unicast addresses are
>    registered in the Special Purpose IP address registries [RFC6890].

Citation for first sentence?

>    The vast bulk of the IPv6 address space (approximately 7/8ths of the
>    whole address space) is reserved by the IETF, with the expectation

For first sentence, cite where that reservation/delegation was made
(i.e., RFC 3513).

Thomas

---

From: Geoff Huston <[email-masked]>
Date: Wed, 8 Jan 2014 06:20:46 +1100

> "The allocation and registration functions for all non-reserved globally unique unicast IPv6 addresses are currently handled by the Internet Numbers Registry System in accordance with policies deve…

In all three cases you are proposing to change "are handled" to "are currently handled"

Could you kindly explain the rationale for this proposed change in wording, as the subtle distinction between the two terms is, I'm afraid, somewhat lost on me.

regards,

   Geoff

---

From: David Conrad <[email-masked]>
Date: Tue, 7 Jan 2014 12:03:30 -0800

Geoff,

> In all three cases you are proposing to change "are handled" to "are currently handled"

Yep.

> Could you kindly explain the rationale for this proposed change in wording, as the subtle distinction between the two terms is, I'm afraid, somewhat lost on me.

RFC 7020 describes the Internet Numbers Registry as it exists today and talks about the evolution system, indicating that the system "can evolve to meet the changing demands of the global Internet community."  As this draft bills itself as a companion to 7020, indicating that the various allocation and registration functions are _currently_ performed by the RIRs (implying that this might change in the future as the system evolves) seems appropriate.  I've found (particularly with experiences related to RFC 2050) that is is useful to be explicit about the distinction between "current" and an implied "permanent".

Regards,
-drc

---

From: Geoff Huston <[email-masked]>
Date: Wed, 8 Jan 2014 07:12:49 +1100

> RFC 7020 describes the Internet Numbers Registry as it exists today and talks about the evolution system, indicating that the system "can evolve to meet the changing demands of the global Internet…

I'm reminded of a discussion (probably on this list) some time ago when kre reminded me that all RFCs can be updated or obsoleted in the future by subsequent RFCs. I read this draft in a different sense, in that the text in this draft is a description of a here and now state of affairs that will presumably exist in the future until updated or obsoleted by a subsequent RFC, much the same as the fate of RFC2050 I suppose.

regards,
   Geoff

---

From: David Conrad <[email-masked]>
Date: Tue, 7 Jan 2014 16:06:47 -0800

Geoff,

On Jan 7, 2014, at 12:12 PM, Geoff Huston <[email-masked]> wrote:
> I'm reminded of a discussion (probably on this list) some time ago when kre reminded me that all RFCs can be updated or obsoleted in the future by subsequent RFCs.

True, albeit whether their being updated/obsoleted in a timely matter is a separate issue (noting 2050, published in 1996, didn't get moved to Historic until 2013 despite questionable relevance of a majority of text in that RFC to the current allocation system).

>  I read this draft in a different sense, in that the text in this draft is a description of a here and now state of affairs that will presumably exist in the future until updated or obsoleted by a subsequent RFC, much the same as the fate of RFC2050 I suppose.

And my suggested edits merely makes the point explicit that this is the case. I believe minimizing ambiguity in RFCs is a good thing. I have seen/experienced far too many cases of "As is written in the Holy 2050" as justification to feel comfortable in relying on people reading the draft/RFC 'correctly'.

Regards,
-drc

---

From: Geoff Huston <[email-masked]>
Date: Wed, 8 Jan 2014 11:55:27 +1100

> And my suggested edits merely makes the point explicit that this is the case. I believe minimizing ambiguity in RFCs is a good thing. I have seen/experienced far too many cases of "As is written in…

ok - I guess it's style - I prefer the shorter version with the common understanding that NO RFC is written in the ink of eternal truth, but I can live with either.

regards,

  Geoff

---

From: Randy Bush <[email-masked]>
Date: Thu, 09 Jan 2014 05:46:01 +0900

> I'm reminded of a discussion (probably on this list) some time ago
> when kre reminded me that all RFCs can be updated or obsoleted in the
> future by subsequent RFCs. I read this draft in a different sense, in
> that the text in this draft is a description of a here and now state
> of affairs that will presumably exist in the future until updated or
> obsoleted by a subsequent RFC, much the same as the fate of RFC2050 I
> suppose.

wrong venue.  should you want to non-ietf parts of the iana function,
you do not want to go through the ietf process.

randy

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 19 Jan 2014 18:51:30 -0000

Hi,

I was doing my telechat reviews for next Thursday and would have entered a
Discuss for his document but...

- there is no ballot
- the last call is still running

So here is my IETF last call review of this document :-)

Thanks,
Adrian

Section 2.1 says...

Section 2.2 says...

   Reservation of special-purpose IPv4 addresses are made through
   Internet Standards actions.

Section 2.3 says...

   Reservation of special-purpose IPv6 addresses are made through
   Internet Standards actions.

Section 3 says...

   "IETF Review" as defined in [RFC5226] is required to reserve special-
   purpose AS numbers, IPv4 addresses, or IPv6 addresses.

1. 2.1, 2.2, and 2.3 should have a reference to 5226
2. Section 3 contradicts 2.1, 2.2, and 2.3.
3. Why is Section 3 present since there are no instructions for IANA?

---

From: Jari Arkko <[email-masked]>
Date: Tue, 21 Jan 2014 15:25:08 +0000

> 3. Why is Section 3 present since there are no instructions for IANA?

FWIW, I agree with these comments, and they deserve to be fixed. Thanks for your review.

Jari

---

From: Russ Housley <[email-masked]>
Date: Sat, 25 Jan 2014 09:48:31 -0500

SM:

> At 14:34 16-12-2013, Russ Housley wrote:
>> This document tells which registries have policy set by the RIRs.  The special-purpose values are exceptions, and that is why they are named in this document.
> 
> [snip]
> 
>> Again, these are saying that exceptions require IETF Review, but otherwise the policy for these registries is handled by the RIRs.
> 
> Thanks for the reply.  I read draft-housley-number-registries-02 again.  The "which registries have policy set ..." would be the following text:
> 
>  "The allocation and registration functions for all non-reserved
>   globally unique unicast IPv4/IPv6 unicast addresses are handled by the
>   developed by the Regional Internet Registries (RIRs)."
> 
> The special-propose values are already discussed in RFC 6890.  Section 2.2 of that RFC mentions that:
> 
>  'IANA will update the aforementioned registries as requested in the
>   "IANA Considerations" section of a document that has passed IETF
>   Review [RFC5226].'
> 
> My reading of the above is that it says that exceptions require IETF Review.  I read Section 3 of RFC 7020:
> 
>  "In addition, ICANN performs the IANA services related to the IP
>   address space and AS numbers according to global number resource
>   policies that have been developed by the community and formalized
>   under a Memorandum of Understanding between ICANN and the Regional
>   Internet Registries [ASOMOU] and documented in [ICANNv4], [ICANNv6],
>   and [ICANNASN]."
> 
> That text covers the policy angle.
> 
> The Introduction section of the draft mentions "IANA registries".  The quoted paragraph of the reply mentioned that the "document tells which registries have policy ...".  It is difficult to understand what the draft is about.
> 
> Regards,
> -sm 

Thanks for your comments.  I have changed section 1 and section 2 to address them.  Here is the updated text:

1.  Introduction

   In accordance with the IETF-IANA Memorandum of Understanding
   [RFC2860], RFC 7020 [RFC7020] provides information about the Internet
   Numbers Registry System and how it is used in the distribution of
   autonomous system (AS) numbers and globally unique unicast Internet
   Protocol (IP) address space.

   This companion document identifies the IANA registries that are part
   of the Internet Numbers Registry System at this time.

2.  Internet Numbers Registries

   Three IANA registries are associated with the Internet Numbers
   Registry System: AS Numbers, unicast IPv4 Addresses, and unicast IPv6
   Addresses.  However, in each case, there are special-purpose values,
   and those special-purpose values are outside the Internet Numbers
   Registry System.

Russ

---

From: Russ Housley <[email-masked]>
Date: Sat, 25 Jan 2014 11:06:09 -0500

> Citation of where that policy is defined?

I have updated the document; it will be posted as -03.  It now uses "IETF Review" throughout.
 
> what the policy is for each registries listed above.

I have reworked this as suggested by David Conrad.  It now points to the existing IANA registry, which already requires "IETF Review" for additions.

> Citation for first sentence?

I have reworked this as suggested by David Conrad.  It now points to the existing IANA registry, which already requires "IETF Review" for additions.

> For first sentence, cite where that reservation/delegation was made

Okay.

Russ

---

From: Russ Housley <[email-masked]>
Date: Sat, 25 Jan 2014 10:58:39 -0500

> I'm a bit uncomfortable with specifying the contents of registries within RFCs these days as they can become out of date even before they're published.  For example, it's likely there's going to be…

I think this is a good idea.  It required a fairly significant update to the document.  I did it in version -03.

> I find it curious that when talking about top-level domains, the criteria (according to RFC 6761) for reservation is "Standards Action" or "IESG Approval" but when talking about reserving Internet…

These three IANA registries require IETF Review.  In fact, that is already documented at the two URLs that you provide above.

> "The allocation and registration functions for all non-reserved AS numbers are currently handled by the Internet Numbers Registry System in accordance with policies developed via the Regional Inter…

Okay.  I added "public policy development processes" to the end of the sentence.

> "The allocation and registration functions for all non-reserved globally unique unicast IPv4 addresses are currently handled by the Internet Numbers Registry System in accordance with policies deve…

Okay. I dropped the duplicate "unicast."  I added "public policy development processes" to the end of the sentence.

> "The allocation and registration functions for all non-reserved globally unique unicast IPv6 addresses are currently handled by the Internet Numbers Registry System in accordance with policies deve…

Okay. I dropped the duplicate "unicast."  I added "public policy development processes" to the end of the sentence.

> The parenthetical "(e.g., anycast)" may be a bit confusing/ambiguous.  What most people today think of anycast (i.e., "shared unicast") don't generally need to be treated specially by the Internet…

This section is completely replaced with the establishment of the special-purpose AS number registry.

> While the statement there is truthful, perhaps should there be some mention of the potential implications of reserved space in the context of trying to identify sources of badness that are using re…

How about:

Network operators should take care that special-purpose numbers and
addresses are used on the public Internet in a manner that is consistent
with their reserved purpose.

Russ

---

From: Russ Housley <[email-masked]>
Date: Sat, 25 Jan 2014 11:21:31 -0500

Scott:

Others have made a similar suggestion.  I think it might be better to point to the IANA registry, instead of the RFC that created the registry.  In addition, this document can create a registry for special-purpose AS numbers.

Russ

On Dec 16, 2013, at 2:09 PM, Scott O Bradner wrote:

> I’m not sure it is helpful to have the special use IPv4 address in more than one RFC
> 
> i.e., why not just point to RFC 6890 rather than reproduce it?
> 
> and if there is a reason to make a new one then this doc should unambiguously obsolete RFC 6890
> 
> Scott
> 
> On Dec 16, 2013, at 12:55 PM, The IESG <[email-masked]> wrote:
> 
>> 
>> The IESG has received a request from an individual submitter to consider
>> the following document:
>> - 'Internet Numbers Registries'
>> <draft-housley-number-registries-02.txt> as Informational RFC
>> 
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action. Please send substantive comments to the
>> [email-masked] mailing lists by 2014-01-22. Exceptionally, comments may be
>> sent to [email-masked] instead. In either case, please retain the
>> beginning of the Subject line to allow automated sorting.
>> 
>> Abstract
>> 
>> 
>>  RFC 7020 provides information about the Internet Numbers Registry
>>  System and how it is used in the distribution of autonomous system
>>  (AS) numbers and globally unique unicast Internet Protocol (IP)
>>  address space.
>> 
>> The file can be obtained via
>> http://datatracker.ietf.org/doc/draft-housley-number-registries/
>> 
>> IESG discussion can be tracked via
>> http://datatracker.ietf.org/doc/draft-housley-number-registries/ballot/
>> 
>> 
>> No IPR declarations have been submitted directly on this I-D.
>> 
>> 
>

---

From: Russ Housley <[email-masked]>
Date: Sat, 25 Jan 2014 11:38:51 -0500

>   purpose AS numbers, IPv4 addresses, or IPv6 addresses.

I will post -03 soon.  It uses "IETF Review" throughout.

> 1. 2.1, 2.2, and 2.3 should have a reference to 5226

Fixed.

> 2. Section 3 contradicts 2.1, 2.2, and 2.3.

Fixed.

> 3. Why is Section 3 present since there are no instructions for IANA?

Based on the suggestion from David Conrad, Section 3 now asks IANA to establish a registry for special-purpose AS numbers.

Russ

---

From: SM <[email-masked]>
Date: Sat, 25 Jan 2014 07:33:24 -0800

Hi Russ,
>    and those special-purpose values are outside the Internet Numbers

Thanks for addressing the comments.  I am okay with the above.

Regards,
-sm

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 25 Jan 2014 20:14:11 -0000

Hi Russ,

Thanks for this. The -03 revision just posted addresses my comments.

Adrian

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: 25 January 2014 16:39
> To: [email-masked]
> Cc: IETF
> Subject: Re: Last Call: <draft-housley-number-registries-02.txt> (Internet
> Numbers Registries) to Informational RFC
> 
> Adrian:
> 
> > Section 2.1 says...
> >
> Based on the suggestion from David Conrad, Section 3 now asks IANA to
establish
> a registry for special-purpose AS numbers.
> 
> Russ

---

From: David Conrad <[email-masked]>
Date: Sun, 26 Jan 2014 23:08:29 -0800

Russ,

On Jan 25, 2014, at 7:58 AM, Russ Housley <[email-masked]> wrote:
>> Perhaps it would make more sense to reference IANA registries instead of listing the contents of what would be in those registries in the draft text

Works for me.

> These three IANA registries require IETF Review.  In fact, that is already documented at the two URLs that you provide above.

Right. The thing I found curious was that special numbers get "IETF Review" whereas special names get "Standards Action" or "IESG Approval".  This isn't really a comment on your draft per se, just confusion about the discrepancy in treatment between these identifiers.

> Okay.  I added "public policy development processes" to the end of the sentence.

As Geoff identified, the bit I was more focused on was the "currently", however this is a nit I can probably avoid picking.

> with their reserved purpose.

Works for me.

Thanks!

Regards,
-drc

---

From: David Farmer <[email-masked]>
Date: Mon, 27 Jan 2014 15:56:56 -0600

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