ietf
[Top] [All Lists]

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

2013-03-20 22:38:11
On Mar 20, 2013, at 8:45 PM, SM <sm(_at_)resistor(_dot_)net> wrote:

Ok.  I'll defer to the learned individuals of the IETF in respect
to the intended status.  It is my understanding that the document
also aims to replace BCP 12.

Excellent question; it's my belief that obsoleting RFC2050 would 
do that, but perhaps it would be best to make that point more 
specific in this document?

I can only say that in my opinion the omission of the finer details
does not have any negative consequences for the RIRs.

IN-ADDR maintenance is explicitly in RFC 2050, and has not been
overtaken by events to my knowledge, hence it is included in this 
successor document.

 "Per the delineation of responsibility for Internet address policy
  issues specified in the IETF/IAB/ICANN MOU [RFC2860], discussions
  regarding the evolution of the Internet Numbers Registry System
  structure, policy, and processes are to take place within the ICANN
  framework and will respect ICANN's core values [ICANNBL]."

How does the above affect the IETF, e.g. what process changes happened 
between RFC 2050 and draft-housley-rfc2050bis-00?  Why is it even relevant to 
the IETF?

The IETF/IAB signed an MOU with ICANN for performance of certain IANA tasks,
including a framework which recognized that ICANN would be dealing with policy 
issues related to the domain name system and the IP address system.  At the 
same 
time, the Regional Internet Registries worked with ICANN to perform the 
community-
based regional and global IP policy development coordinated with ICANN's 
overall 
framework.  This is clearly a different way of establishing IP address policy 
than 
described in the current RFC2050, and hence material to the IETF.

 "These core values encourage broad, informed participation reflecting
  the functional, geographic, and cultural diversity of the Internet at
  all levels of policy development and decision-making, as well as the
  delegation of coordination functions and recognition of the policy
  roles of other responsible entities that reflect the interests of
  affected parties."

I do not understand what the above means in practice.

There are lots of folks over in the DNS world wondering that same question... 
;-)

Seriously, one could write volumes about ICANN, its structure, processes
oversight role, etc., but at the end of the day you'd be creating a fixed
copy of what is an evolving organization.  The IETF does not decide today
when and which new top-level domains are added to the DNS root, that is an
example of a question which requires "broad, informed participation reflecting
the functional, geographic, and cultural diversity of the Internet at all 
levels of policy development and decision-making."

 "The discussions regarding Internet Numbers Registry evolution must
  also continue to consider the overall Internet address architecture
  and technical goals referenced in this document."

After reading  draft-housley-rfc2050bis-00 it is my understanding that the 
Internet Numbers Registry is out of scope for the IETF.  I read the above as 
meaning that the IETF is telling RIRs and ICANN that they must also follow 
technical guidance from the IETF in respect to the Internet address 
archtecture.

The IETF defines the architecture of the Internet Protocol, and this includes
the IP address space.  Regardless of whether policy development has been
delegated to the RIRs under the ICANN framework, the address architecture
is still established by the IETF.

"The foregoing does not alter the IETF's continued responsibility for
 the non-policy aspects of Internet addressing such as the architectural
 definition of IP address and AS number spaces and specification of
 associated technical goals and constraints in their application, assignment
 of specialized address blocks, and experimental technical assignments as
 documented in RFC 2860."

The above sounds like something from the legal department.  I unfortunately 
cannot hire a lawyer to tell me whether that text matches the text in RFC 
2860.  I don't see how one can expect informed participation when the text to 
be read might be unclear to the people from the rest of the world.

To my knowledge, it does correctly represent the terms in RFC 2860, 
but I understand that the language is rather dense and may be hard
to parse.  We do not want to repeat the entirety of RFC 2860 here,
but it is useful for readers to know that per that MOU, there is a
has a delineation of responsibilities between the IETF and the 
ICANN/RIR system.

By the way I read my previous message [1] again and the reply [2] I received 
and I noticed that there wasn't any response to two of the questions.

Agreed.  I commented on those aspects where my remarks may add value to 
the discussion; there are others on this list with greater experience and
knowledge which may help with other questions you have raised.

Thanks for the feedback - I hope I've helped explain at least some of the 
reasoning behind the language in the draft.
/John

Disclaimer:  My views alone.