My name is Karl Auerbach. I reside in Santa Cruz, California.
I was the first, and only, publicly elected North American director on ICANN's Board of Directors.
I have been affiliated with the internet since the early 1970's.
I have created Internet Standard RFC's for the IETF and have made use of IANA protocol number assignments.
I have never understood the force of the argument made by ICANN that ICANN and the IANA function are best bound together into a single entity.
Indeed, I have always considered the more appropriate path to be that of separation.
There is essentially no cross-pollination of work or knowledge between ICANN and IANA except in one area: DNSSEC keys for the ICANN-NTIA-Verisign root zone of the domain name system.
Apart from that I perceive no particular technical value that ICANN brings to IANA, or IANA brings to ICANN.
Many of the jobs performed by IANA are largely clerical - in many instances protocol parameter assignments resemble the action of a "take a number" machine in a baker's shop. It is true that sometimes IANA assignments are more complex than that; however the IETF has established a mechanism through which it provides experts and expertise to IANA in those situations.
There is, of course, a notable exception: the recognition of the rightful administrator of country code top level domains (ccTLDs). This is a task that is in many regards more political than technical and perhaps more appropriate to be vested into an treaty body than in the informally grounded, and technically based, IANA. (I am making the assumption that recognition of ccTLD administrators is more properly an IANA function than an ICANN one - given the commingling of functions under the ICANN umbrella it is not always clear whether a particular act of ICANN+IANA is done while wearing the ICANN hat or the IANA hat.)
ICANN has made use of its joint role as both ICANN and IANA in a kind of political shell game: for many years ICANN defended itself by using IANA as a pawn to raise the specter of internet collapse should anyone question or challenge ICANN's non-technical activities, such as ICANN's trademark-protective actions. It does neither ICANN or IANA, or the internet, any good when ICANNs political and organizational interests are promoted via IANA as technical imperatives.
The famous architect Louis Sullivan observed that "form follows function".
That same principle ought to guide the future of IANA: IANA ought to be wrapped into an organizational structure - or structures - that best fit the tasks IANA is to perform. The convenience of ICANN or NTIA ought to be subordinate.
As has been mentioned by others the IANA function is not a single task.
Consequently it may be most appropriate to shape IANA into distinct entities, each shaped around a particular task.
Of course, there are economies of scale that can be obtained by having fewer rather than more little IANA entities. However, the decision whether to have a monolithic IANA or several functional units ought to be made with clear consideration of these issues rather than by silent default.
Many of the jobs performed by IANA are of a nature that rarely engenders conflicts. Consequently, IANA need not be burdened with the massive procedural costs and delays that have become so much a part of the ICANN system. Rather, IANA functions could function largely on a simple notice-and-comment system in which IANA decisions are subject only to review on the basis of abuse of discretion.
To a large degree many of the jobs performed by IANA could be done by any entity that has proven competence in keeping clear public ledgers and maintaining accurate audit trails - in other words something more like a bookkeeping firm than a high-tech enterprise.
With regard to DNSSEC numbers for the ICANN-NTIA-Verisign root zone, this may be one IANA function that perhaps ought to be carved off and left within ICANN.
If nothing else the outcome of this NOI ought to be to define very clear procedural interfaces between the various IANA (and ICANN) tasks. This will greatly clarify the limits of authority and help identify gaps of authority. It will also facilitate restructuring as the internet evolves.
The internet will be better served by an fast and inexpensive IANA rather than something that seems modeled after the Circumlocution Office of Dickens' book "Little Dorrit" - See http://www.cavebear.com/archive/cavebear/containing_the_whole_science_of_government.html
I fear that ICANN's empire building and Byzantine tendencies would result in the kind of IANA that we don't want, and that the internet does not need, were the two entities to remain bound together.
There remain unanswered questions:
Is the L-Root server properly part of the IANA function or part of ICANN itself? There is a seeming lack of documentation on this question.
Is the IPv4 and/or IPv6 address space properly part of IANA or ICANN? (It seems that the answer is "IANA" but much of that seems to arise from assertion rather than documented sources of authority.)
Are the Regional Internet address Registries (RIRs) sub-entities of IANA, ICANN, or neither?
I have written previously on this topic:
Posted by karl at March 29, 2011 8:29 PM