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