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.