Hi Jari,
On Jan 3, 2014, at 9:36 AM, IETF Chair <chair(_at_)ietf(_dot_)org> wrote:
In this article I wanted to highlight an important but often hidden part in
the IETF ecosystem: Internet Assigned Numbers Authority (IANA). What is
IANA, how does it work, how is it related to the IETF, and how has it evolved
over time? How will it evolve in the future, and how can you participate in
the discussion?
Thanks for this. I've often been surprised how few people know or understand
the IANA functions, how they're performed and under what authority, and I
suspect clarity on these issues is going to be increasingly important in the
future.
A few points:
- Perhaps it is merely your shorthand, but I've found that saying "IANA" as if
it is a discrete entity rather than a set of functions performed by a
contractor (or contractors) tends to confuse things. For example, you say "...
IANA then makes the actual allocations ...". In actuality (as you note later
on), ICANN, acting as the current IANA "protocol parameters function" operator
makes the allocation.
- As I suspect you're aware, ICANN, as the IANA function operator, performs a
couple of other administrative duties that are considered (at least in the
context of the IANA functions contract between the US Dept. of Commerce NTIA
and ICANN, see
http://www.ntia.doc.gov/files/ntia/publications/sf_26_pg_1-2-final_award_and_sacs.pdf)
outside of the protocol parameter, root zone management, and top-level
Internet numbers allocation functions, i.e., administration of the .ARPA
top-level domain and administration of the .INT top-level domain. Given past
experiences, I hope these other functions are kept in mind as people think/talk
about future frameworks associated with IANA functions evolution.
- Some nits in the sentence "For instance, 2000, the IETF and ICANN signed a
contract about the protocol parameters aspect of the IANA function (RFC 2560)":
I presume you meant "in 2000" and "RFC 2860". Also, as opposed to the IANA
functions contract between the USG and ICANN referenced above, 2860 is not a
contract but a "memorandum of understanding" -- I've been told by lawyers that
the distinction is important.
- I probably wouldn't say the system of IANA functions have "grown up" as that
suggests no further growth is necessary/needed. I'd agree that the system is
maturing, however I believe still has a ways to go, albeit primarily in
non-technical areas. In particular, it will be nice to clarify the current ...
ambiguity, at least in the eyes of some, regarding the authority over IANA
functions.
I look forward to seeing how things evolve in the future.
Regards,
-drc
(IANA General Manager, 2005 - 2010)
signature.asc
Description: Message signed with OpenPGP using GPGMail