The Internet Numbers Registry System
draft-housley-rfc2050bis-02

[Ballot comment]
Minor editorial nit:
OLD:
  This document does not propose any changes to the Internet Numbers
  Registry System, but it does provide information about the current
  Internet Numbers Registry System used in the distribution of globally
  unique Internet Protocol (IP) address space and autonomous system
  (AS) numbers, while also providing for further evolution of the
  Internet Numbers Registry System.
NEW:
  This document does not propose any changes to the Internet Numbers
  Registry System. It does provide information about the current
  Internet Numbers Registry System used in the distribution of globally
  unique Internet Protocol (IP) address space and autonomous system
  (AS) numbers.  It also provides for further evolution of the
  Internet Numbers Registry System.

I think my proposed new text isn't as elegant, but it will be easier to parse.

Otherwise the document looks good.

[Ballot comment]
I'd really like to see this run-on sentence divided into something easier to parse:

OLD:
  This document does not propose any changes to the Internet Numbers
  Registry System, but it does provide information about the current
  Internet Numbers Registry System used in the distribution of globally
  unique Internet Protocol (IP) address space and autonomous system
  (AS) numbers, while also providing for further evolution of the
  Internet Numbers Registry System.
NEW:
  This document does not propose any changes to the Internet Numbers
  Registry System. It does provide information about the current
  Internet Numbers Registry System used in the distribution of globally
  unique Internet Protocol (IP) address space and autonomous system
  (AS) numbers.  It also provides for further evolution of the
  Internet Numbers Registry System.

I think my proposed new text isn't as elegant, but it will be easier for non-english speakers to parse.

Otherwise the document looks good.

[Ballot comment]
One expects the RIRs to have to scrub all their policy documents of 2050 related references... Some of which will require policy work through their respective processes...

[Ballot comment]
I think that Pete makes a good point wrt removing a BCP from the register.
It also seems to me that 2050 and the document it in turn obsoleted (etc. back into pre-history) should all now be formally marked as Historic.
Let's not have a debate about what 2026 says and means, but just consider how we want BCP 12 to "disappear".

[Ballot comment]
A strictly procedural point, and it does not prevent this document from moving forward at all, but we should figure out what the "right" thing is here. I'm forwarding to the RFC Editor to get their feedback:

This is an Informational document that is Obsoleting a BCP. I am convinced that everyone during Last Call understood the implication of that, so I don't think we need to go back and do something special there. But does the IESG need to do some magical incantation to remove BCP 12 from the BCP Index? We could make 2050 HISTORIC, which would make it clear, or simply treat it as bookkeeping on the RFC Editor web site.

This is the first time I've ever seen this happen, so it's not surprising we don't have a procedure for this.

[Ballot comment]
A strictly procedural point, and it does not prevent this document from moving forward at all, but we should figure out what the "right" thing is here. I'm Cc'ing the RFC Editor to get their feedback:

This is an Informational document that is Obsoleting a BCP. I am convinced that everyone during Last Call understood the implication of that, so I don't think we need to go back and do something special there. But does the IESG need to do some magical incantation to remove BCP 12 from the BCP Index? We could make 2050 HISTORIC, which would make it clear, or simply treat it as bookkeeping on the RFC Editor web site.

This is the first time I've ever seen this happen, so it's not surprising we don't have a procedure for this.

[Ballot comment]
The IANA site points to RFC2050 as technical documentation in at least one place. I am therefore surprised that there is no IANA action to trigger IANA to update their document pointers.

[Ballot discuss]

Just checking something in case it was missed. I hope
this doesn't open cans of worms. If it does... apologies
in advance;-)

(1) RFC 2050 section 6 describes an appeal process. It
seems reasonable for 2050bis to not even talk about how
appeals work up to the level of appealing to IANA, but
you could read 2050 in conjunction with 2860 as meaning
that if IANA receive such an appeal, they might then ask
the IESG (with a possible appeal later to the IAB). This
document might therefore be read as getting rid of that
bit of appeal process (if it ever existed) that involved
the IESG & IAB. Is that correct? (I'm not sure and happy
to be corrected if I'm reading it wrong.) If so, was that
discussed during the IETF LC? (I looked and didn't see
it.) If the appeal path I postulate here was real, then
it would appear that the sentence in the abstract that
2050bis doesn't change anything isn't quite right. Or
perhaps that 2050 section 6 appeal process was already
changed by 2860 or ICANN by-laws or something else later
on?

[Ballot comment]

These may read like I'm more concerned than I am, but
they're really just nits, and I'm ok if they're treated
as nits.  It might however be worthwhile thinking about
them if this is considered an important RFC, given that
it may be another 17 years before its touched again. So
take 'em or leave 'em, and either's ok with me.

- section 2, bullet 1: the fixed length of IPv6 addresses
doesn't seem to me to imply that allocations "must" be
made in any particular way solely because of the size of
the number space.  The size of the IPv4 space also
doesn't matter now that its gone. And with 32 bit AS
numbers that should also be ok.

- s2, bullet 2, typo: s/aggegated/to be aggregated/

- s2, bullet 2: What is our level of confidence that
allocation processes and routing technology will develop
in tandem? If we've no a-priori reason to suspect that's
likely then is it really wise to bind allocation and
routing like that? (Assuming it'll be another 17 years
until this gets updated again.) Maybe better to just say
that that's how its done today and not try justify that
based on routing. That might be sorted with a trivial
change e.g.  to s/it is a goal/it is currently a goal/

- s2, bullet 3: "uniqueness" of what?

- s2, bullet 3: accuracy doesn't seem to me to be a goal
of a distribution scheme but rather a bookkeeping
requirement for any distribtution scheme that also has an
accountability goal. Is the real goal here that those
involved in distributing number resources and those using
those resources can be accountable? If so, saying so
might be better.

- s2, generally seems to be justifying the status quo
when it might be better to just state that this is the
status quo, its working ok and so there's no reason to
mess with it.

- section 3: defining IANA like this ignores their role
in most of the protocol registries they operate.  I'd
suggest s/allocation hierarchies./allocation hierarchies
as well as managing many other protocol registries on
behalf of the IETF./ or something like that.

[Ballot comment]
This doc seems fine. I do have one question that could very well be unrelated, but I'll ask anyway.

This doc uses the word "multi-stakeholder" in Section 5, but doesn't define it. There are a number of fine words in the following paragraph, but I'm not seeing anything that looks like "and by 'multi-stakeholder', we mean ...".

My understanding was that we've been running into people who don't have the same understanding of that word that we do (to the point of "of course we're multi-stakeholder! we invite ALL the governments!")

Is there anything like an agreed-upon definition this document could reference?

If not, is this the wrong place to say something about what we think that word means?

IESG/Authors/WG Chairs:

IANA has reviewed draft-housley-rfc2050bis-01, which is currently in
Last Call, and has the following comments:

Upon approval of this document, we understand that this document will
not create any new IANA actions.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (The Internet Numbers Registry System) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'The Internet Numbers Registry System'
  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
ietf@ietf.org mailing lists by 2013-05-14. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document provides information about the current Internet Numbers
  Registry System used in the distribution of globally unique Internet
  Protocol (IP) address space and autonomous system (AS) numbers.

  This document also provides information about the processes for
  further evolution of the Internet Numbers Registry System.

  This document replaces RFC 2050.

  This document does not propose any changes to the Internet Numbers
  Registry System.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-housley-rfc2050bis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-housley-rfc2050bis/ballot/


No IPR declarations have been submitted directly on this I-D.

I have done my AD review, re-read 2050, and looked at the discussion. I do not have any suggestions at this point, I think you have made excellent work with the document. Thank you. (Although I'm sure the IETF list will come up with suggestions, as always!)

I have initiated IETF Last Call. Are there any specific extra lists that we should advertise the last call at, other than ietf@ietf.org?

Russ says:

There has been very little comment on the new version.  We are expecting some based on prodding some people that really care, but I think those could be handled as part of Last Call.  Do you think it is ready?

Jari says:

I will take it under AD review.