Re: IANA blog article

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Jari,

On Jan 3, 2014, at 9:36 AM, IETF Chair <chair@xxxxxxxx> 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)


Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]