Re: Please review draft-housley-rfc2050bis-00.txt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 3/19/13 14:48 , Russ Housley wrote:
David:

1) In Section 1, goal #2, "Hierarchical Allocation", I believe a reference the definition in RFC 5226 - Section 4.1.  Well-Known IANA Policy Definitions, should be considered.

We could do so, but I do not believe that the few word in RFC 5226 on hierarchical allocation improve the understanding of IP address allocation being discussed here.

OK.

2) I also wonder if another appropriate goal would be explicitly defining the ASN and IP address registries using RFC 5226 language including the formal linkage to ICANN and the RIRs as the mechanism for IANA to implementing the Hierarchical Allocation of these registries. See: RFC 5226, section 4.3. "Updating IANA Guidelines for Existing Registries"

The intention wouldn't be to override RFC 2860, ICANN Policy, or IR global policy, but to provide and explicit formal technical definition for these registries that really have only been implicitly defined to date as far as I can tell.  There are any number of other registries that are far less important overall, that have excellent formal technical definitions that comply with RFC 5226 or its predecessors. However, these our most important registries have no such formal technical definitions, I think its really time to fix this situation.

That said, to the greatest extent possible we need a formal technical definition compliant with RFC 5226 of the as-is-state, not of the want-it-to-be-state.  Or, if I'm incorrect and there are formal technical definitions for these registries that comply with RFC 5226, or its predecessors, then they should be referenced in this document.

The top of the IPv6 Address Registry says:

  The IPv6 address management function was formally delegated to
  IANA in December 1995 [RFC1881]. The registration procedure
  was confirmed with the IETF Chair in March 2010.

RFC 1881 is short, but it seems to say the things that need to be said.

Figured it existed for IPv6, but I didn't think of looking for the reference in the IANA registry. I really like what RFC1881 says, and it should be referenced in the Draft.

But, looking at the IPv4 registry, it references RFC1466, which was obsoleted by 2050, which this proposes to obsolete, and the ASN registry references RFC1930. Both of these are pretty murky as a formal technical definition for these two registries. RFC6793 is referenced in the ASN registry for the 32 bit portion, but is just says it is expanding the registry to 32 bits. I think the difference between RFC1881 and these other references reenforces my argument about needing a formal technical definition for at least the IPV4 and ASN registries that is compliant with RFC 5226.

3) The last paragraph of Section 3, "Internet Numbers Registry Technical Considerations"  Says;

   As the Internet and the Internet Numbers Registry System continue to
   evolve, it may be necessary for the Internet community to examine
   these and related technical and operational considerations and how
   best to meet them.

I wonder if it wouldn't be appropriate to at least provide some suggestions for how this is to be accomplished.  Maybe request that future RFCs related to these technical and operational considerations include an applicability statement as to the Internet Numbers Registry System, either in a separate section or maybe as a sub-section of the IANA Considerations.

This evolution is discussed in Section 4.  Maybe a forward pointer is needed.  Did you not find Section 4 sufficient?

I saw that, it says;

   In addition, in the cases where the IETF sets technical
   recommendations for protocols, practices, or services which are
   directly related to IP address space or AS numbers, such
   recommendations must be taken into consideration in Internet Numbers
   Registry System policy discussions regardless of venue.

This is good, but I read it as saying the IR system, and the RIR's in particular, are obligated to consider the technical recommendations of the IETF when making policy. That is only part of the equation.

I was looking for the other side, "the IETF is obligated to maintain clear, relevant, and up to date technical recommendations for the IR system, including how such recommendations are intended to apply to the IR system."

There are situations where RIR policy is consistent with IETF technical recommendations that have not been updated in a long time, or at least deprecated. When issues come up they are said to be RIR policy issues, not IETF issues. So, are the RIR's suppose to ignore outdated technical recommendations? Who decided they are outdated?

Put another way, the RIR's need to follow the technical recommendations of the IETF, but the IETF needs to provide relevant technical recommendations including updating or deprecating them when they are no longer valid. It can't be a one-way street.

Rereading things again, I have another suggestion;

4) Split the Goals of the Internet registry system out of the Introduction. The Intro starts out talking about the document, its goals, and what is in scope and out of scope of the document. Then transitions to talking about the goals of the Internet registry system. I think the goals of the Internet registry system should be a separate section from the Introduction. And, the Introduction should be expanded to better describe the purpose of the document.

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


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]