Hi John,
At 20:38 20-03-2013, John Curran wrote:
Excellent question; it's my belief that obsoleting RFC2050 would
do that, but perhaps it would be best to make that point more
Yes.
specific in this document?
It may be easier to add text which provides a (simple) explanation
about why RFC 2050 is obsolete. The text in Section 5 (possibly with
changes) could be moved to Section 1.
The draft already has the core of the text. If Section 1 and Section
2 are restructured most of the work is done.
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.
The above is clear and to the point.
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."
Yes. That's why I would suggest keeping the draft simple instead of
getting into ICANN stuff.
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 above is clear and to the point. It is good material for the draft.
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.
There is already a normative reference to RFC 2860. Please note that
I have not spent sufficient time reading the draft and related
material to suggest whether or how to reference the terms in RFC 2860.
There argument is about the delineation of responsibility. RFC 2860
could be side-stepped; i.e. the draft could be turned into an
understanding between the IETF and RIRs. Obviously ICANN or any
other organization can be added to the mix if anyone affiliated with
the organization posts arguments to this mailing list to explain why
that should be done.
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.
Ok. I will try to be patient and wait for people with greater
experience and knowledge to address those questions.
Thanks for the feedback - I hope I've helped explain at least some of the
reasoning behind the language in the draft.
Thank you for the clear explanations and providing the reasoning.
Regards,
-sm