Subject: Re: Last Call: <draft-bonica-special-purpose-03.txt> (Special-Purpose Address Registries) to Best Current Practice

From: Pete Resnick <[email-masked]>
Date: Thu, 20 Dec 2012 17:33:20 -0600

I see Ron has gotten back to Geoff and posted a new version of his 
document. Since I've already stuck my nose out with questions before, I 
might as well do so again. (For the record, my DISCUSS on another 
document and the DISCUSS of me and a couple of others on another 
document is what motivated Ron to write this one, so I feel a bit of 
responsibility to make sure this gets done.)

So, some questions for SM:

On 11/29/12 9:22 PM, SM wrote:

> BCP 153 is about Special Use IPv4 addresses.  This intended BCP will 
> create a mishmash as the draft covers both IPv4 and IPv6.  I suggest 
> handling the IP versions in two separate drafts.

I haven't seen anyone jump out of the woodwork in support of splitting 
the document, and the document we've got on the table does it this way. 
Do you think this is important enough to stop the document?

> RFC 5375 is being obsoleted by this draft.  RFC 6598 updates RFC 
> 5375.  Could someone explain that to me (see 
> http://www.rfc-editor.org/errata_search.php?rfc=5375&eid=3309 and the 
> relevant discussion for details)?

I think you've confused the documents. It's 5735, not 5375. So I take it 
this is not relevant, correct?

> The following text is from RFC 3330 which was written by the Internet 
> Assigned Numbers Authority:
>
>   "Throughout its entire history, the Internet has employed a central
>    Internet Assigned Numbers Authority (IANA) responsible for the
>    allocation and assignment of various identifiers needed for the
>    operation of the Internet [RFC1174].  In the case of the IPv4 address
>    space, the IANA allocates parts of the address space to Regional
>    Internet Registries according to their established needs.  These
>    Regional Internet Registries are responsible for the assignment of
>    IPv4 addresses to operators and users of the Internet within their
>    regions.
>
>    [paragraph omitted]
>
>    On an ongoing basis, the IANA has been designated by the IETF to make
>    assignments in support of the Internet Standards Process [RFC2860].
>    Section 4 of this document describes that assignment process."
>
> The text was also present in RFC 5735.  I unfortunately have to object 
> to the disappearance of that text.

This document does not change 2860 and it doesn't change 1174. So this 
policy associated with this text is still in place, whether or not we 
repeat the above paragraphs. Putting this text in seems unimportant and 
I haven't seen support to do so. Can you explain how important this 
objection is? Again, do you see this as a reason not to go forward?

> RFC 5736 provides direction to IANA concerning the creation and 
> management of the IANA IPv4 Special Purpose Address Registry.   The 
> information in RFC 5375 is not obsolete.

We do want 5735 to be obsolete because it is no longer the authoritative 
list of addresses; the registry is. So I think you got that part wrong. 
But you may have a point about *also* obsoleting 5736. I'll leave that 
one to Ron and Ralph.

> From the IANA Considerations Section:

Ron updated this to:

    IANA will update the aforementioned registries as requested in the
    "IANA Considerations" section of an IETF reviewed document.  The
    "IANA Considerations" section must include all of the information
    specified in Section 2.1 of this document.

> RFC 5735 mentions that:
>
>   "Among other things, [RFC2860] requires that protocol parameters be
>    assigned according to the criteria and procedures specified in
>    RFCs, including Proposed, Draft, and full Internet Standards and
>    Best Current Practice documents, and any other RFC that calls for
>    IANA assignment."
>
> This draft changes it.

I don't understand what you mean here. Are you suggesting that this 
document updates 2860, or somehow changes something in 2860? It does not 
AFAICT. Please explain.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 20 Dec 2012 19:57:13 -0500

How about changing the title from "Special-Purpose Address Registries"
to "Special-Purpose IP Address Registries".

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

On Thu, Nov 29, 2012 at 3:55 PM, The IESG <[email-masked]> wrote:
>
> The IESG has received a request from an individual submitter to consider
> the following document:
> - 'Special-Purpose Address Registries'
>   <draft-bonica-special-purpose-03.txt> as Best Current Practice
>
> 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 2013-01-02. 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
>
>
>    This memo instructs IANA to restructure its IPv4 and IPv6 Special-
>    Purpose Address Registries.  Upon restructuring, the aforementioned
>    registries will record all special-purpose address blocks,
>    maintaining a common set of information regarding each address block.
>
>    This memo updates RFC 5736 and RFC 4773, which define the current
>    structure of the IPv4 and IPv6 Special-Purpose Address Registries.
>    It also obsoletes RFC 5735 and RFC 5156 which document special-
>    purpose address blocks that are not currently, but will in the
>    future, be recorded in the IPv4 and IPv6 Special-Purpose Address
>    Registries.
>
>
>
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-bonica-special-purpose/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-bonica-special-purpose/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>

---

From: SM <[email-masked]>
Date: Thu, 20 Dec 2012 23:33:11 -0800

Hi Pete,
At 15:33 20-12-2012, Pete Resnick wrote:
>I haven't seen anyone jump out of the woodwork in support of 
>splitting the document, and the document we've got on the table does 
>it this way. Do you think this is important enough to stop the document?

No, as I cannot justify this if I follow to the DISCUSS criteria.

>I think you've confused the documents. It's 5735, not 5375. So I 
>take it this is not relevant, correct?

I used RFC 5735 as an example.  There is a message from the person 
who submitted the erratum at 
http://www.ietf.org/mail-archive/web/v6ops/current/msg13689.html 
The threads of the discussion are at 
http://www.ietf.org/mail-archive/web/v6ops/current/msg13645.html and 
http://www.ietf.org/mail-archive/web/v6ops/current/msg13681.html 
It's difficult for the average reader to understand what is the 
current "standard" when document status, "updates" and "obsoletes" 
requires convoluted tracking.

>This document does not change 2860 and it doesn't change 1174. So 
>this policy associated with this text is still in place, whether or 
>not we repeat the above paragraphs. Putting this text in seems 
>unimportant and I haven't seen support to do so. Can you explain how 
>important this objection is? Again, do you see this as a reason not 
>to go forward?

I missed RFC 1174.  I'll drop the objection as your explanation is convincing.

>We do want 5735 to be obsolete because it is no longer the 
>authoritative list of addresses; the registry is. So I think you got 
>that part wrong. But you may have a point about *also* obsoleting 
>5736. I'll leave that one to Ron and Ralph.

Ok.

>document updates 2860, or somehow changes something in 2860? It does 
>not AFAICT. Please explain.

No.  Anyway, the probability of such an update being successful is zero. :-)

Regards,
-sm

---

From: Randy Bush <[email-masked]>
Date: Fri, 21 Dec 2012 09:45:10 -0500

i remain confused.  i am not being pedantic just to be a pita.  i really
worry that this document will be used to justtify strange brokenness.

from my 2012.11.29 message:

> are the following definitions
> 
>    o  Routable - A boolean value indicating whether a IP datagram whose
>       destination address is drawn from the allocated special-purpose
>       address block is routable (i.e., may traverse more than a single
>       IP interface)
> 
>    o  Global - A boolean value indicating whether a IP datagram whose
>       destination address is drawn from the allocated special-purpose
>       address block is routable beyond a specified administrative
>       domain.
> 
> intended to be baked in hardware, or are they SHOULDs to operators?  i
> look at RFC 1918 space and 127.0.0.0/8 and am not so sure how hard these
> boundaries are meant to be.  i worry because i think we regret how we
> specified (threw away is more like it) E space.
> 
> does the prefix describes a specific prefix length or a covering range?
> 
> e.g. 192.0.0.0/24 is neither routable nor global, while a subnet,
> 192.0.0.0/29, is routable.  i.e. might i route and forward
> 192.0.0.128/25?

another annoying example.

0.0.0.0/8 is said to be not routable, yet we commonly announce it in bgp
(or igp) and propagate it.  a protocol implmentor reading this document
would be justified in preventing the injection of 0.0.0.0/8 into a
routing protocol.  [ let's not get into that it is commonly in the
fib. ]

randy

---

From: Pete Resnick <[email-masked]>
Date: Fri, 21 Dec 2012 09:08:38 -0600

On 12/21/12 1:33 AM, SM wrote:

> I used RFC 5735 as an example.  There is a message from the person who 
> submitted the erratum at 
> http://www.ietf.org/mail-archive/web/v6ops/current/msg13689.html The 
> threads of the discussion are at 
> http://www.ietf.org/mail-archive/web/v6ops/current/msg13681.html It's 
> difficult for the average reader to understand what is the current 
> "standard" when document status, "updates" and "obsoletes" requires 
> convoluted tracking.

I am still confused. What is the action item here? Do you think 
something needs to be fixed in this document?

pr

---

From: John C Klensin <[email-masked]>
Date: Fri, 21 Dec 2012 10:18:56 -0500

--On Friday, December 21, 2012 09:45 -0500 Randy Bush
<[email-masked]> wrote:

> i remain confused.  i am not being pedantic just to be a pita.
> i really worry that this document will be used to justtify
> strange brokenness.
> 
>...
>> e.g. 192.0.0.0/24 is neither routable nor global, while a
>> subnet, 192.0.0.0/29, is routable.  i.e. might i route and
>> forward 192.0.0.128/25?
> 
> 0.0.0.0/8 is said to be not routable, yet we commonly announce
> it in bgp (or igp) and propagate it.  a protocol implmentor
> reading this document would be justified in preventing the
> injection of 0.0.0.0/8 into a routing protocol.  [ let's not
> get into that it is commonly in the fib. ]

And a slightly-related one.  At least one prominent ISP is not
giving IPv4 addresses out to its small business customers as
a.b.c.d/N with the boundary router address at the top or bottom
of that range.  Instead, it is giving out a "range" of a.b.c.d -
a.b.c.e (e > d >> 1) and then telling the customer to use
a.b.c.1 as the boundary router address.    Is that prohibited?
Can one route from a.b.c.y to a.b.c.x  (1 << x < d < y < e) and
do any our definitions make that harder or easier?

Like Geoff, I have an opinion about how the registry(/ies)
should be organized but believe that is a matter of taste as
long as the information is correct and clear.   

But anything that defines one of these terms or restates the
definitions must be absolutely precise and clear lest we cause
ourselves real problems down the line.

    john

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 21 Dec 2012 15:42:16 +0000

Sure. I'll catch that in the next rev.

                Ron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Donald Eastlake
> Sent: Thursday, December 20, 2012 7:57 PM
> To: [email-masked]
> Subject: Re: Last Call: <draft-bonica-special-purpose-03.txt> (Special-
> Purpose Address Registries) to Best Current Practice
> 
>  155 Beaver Street, Milford, MA 01757 USA  [email-masked]
> 
> 
> > The IESG has received a request from an individual submitter to
> > consider the following document:
> > [email-masked] mailing lists by 2013-01-02. Exceptionally, comments
> may
> > be sent to [email-masked] instead. In either case, please retain the

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 21 Dec 2012 15:49:04 +0000

Hi Randy,

It seems that we need one or both or the following:

- a better title for the new column
- a better definition to be associated with that column

Any suggestions?

              Ron

> Randy Bush
> Sent: Friday, December 21, 2012 9:45 AM
> To: IETF Disgust
> Subject: draft-bonica-special-purpose-04.txt
> 
> i remain confused.  i am not being pedantic just to be a pita.  i
> really worry that this document will be used to justtify strange
> brokenness.
> 
> > look at RFC 1918 space and 127.0.0.0/8 and am not so sure how hard
> > these boundaries are meant to be.  i worry because i think we regret
> > how we specified (threw away is more like it) E space.
> >
> 0.0.0.0/8 is said to be not routable, yet we commonly announce it in
> bgp (or igp) and propagate it.  a protocol implmentor reading this
> document would be justified in preventing the injection of 0.0.0.0/8
> into a routing protocol.  [ let's not get into that it is commonly in
> the fib. ]
> 
> randy

---

From: SM <[email-masked]>
Date: Fri, 21 Dec 2012 10:58:29 -0800

Hi Pete,
>something needs to be fixed in this document?

It was an explanation instead of an actionable comment.  My 
preference is to deal with the IPv4 and IPv6 registries separately as 
it is easier to explain.  I am okay with not making any changes to 
the document as it is not worth spending more time on it.

Regards,
-sm