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

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(_at_)umn(_dot_)edu
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
================================================