Name: John C Klensin
Submission ID: 119

ICG,
Comments attached.
My apologies for not using your template but, after reviewing
it, these comments did not seem very well matched to it.
Best wishes with the next steps in your process.
regards,
John Klensin

Comments on “Proposal to Transition the Stewardship of the Internet
Assigned Numbers Authority (IANA) Functions from the U.S.
Commerce Department’s National Telecommunications and Information
Administration (NTIA) to the Global Multistakeholder Community, July
2015”
John C. KLENSIN, Ph.D.+
Email:

REDACTED

Organization: Speaking for myself only, but with considerable long-term perspective on IANA acquired in a
number of capacities (see endnote)

Prefatory remark and disclaimer
I am submitting these comments with considerable reluctance and some sadness. I remain a very strong
supporter of an open and diverse Internet and of the principles behind the ICANN approach. However, I haveconcluded that the community has taken some wrong turns that jeopardize, rather than strengthen, that model(whether characterized as “multistakeholder” or otherwise). As a result, while the current ICG proposal appears
to be largely consistent with the requirements of the charge from the NTIA and the narrow needs of the“operational communities”, I believe it carries excessive risks of evolving into arrangements in practice that are
undesirable for the long-term and healthy future of the Internet.
While I have provided assistance or suggestions on other sets of comments being submitted to ICG, thesecomments are somewhat different from those and represent my personal opinions only. References to the
proposal are not complete and have been provided only where they seemed to be important

Klensin, 2015‐09‐08, page 1

Table of Contents
Prefatory remark and disclaimer...........................................................................................................................1
Structure of these Remarks ...................................................................................................................................2
The Role of NTIA ................................................................................................................................................2
IANA as an Administrative Function ...................................................................................................................3
Committees, organizations, complexity, participation barriers, and accountability .............................................3
The multistakeholder model and the Internet community ....................................................................................4
Accountability to the Internet community versus accountability to narrow interests ..........................................6
Nuclear options as the key protection...................................................................................................................7
A historical correction ..........................................................................................................................................7

Structure of these Remarks
I have identified what I consider to be the key issues below. They are heavily intertwined to the degree that it isprobably meaningless to try to consider any of them, except possibly the first, in the absence of the others. Eachsection is followed by a brief summary, in italics, of what I consider to be the issue for the report and associatedproposals.

The Role of NTIA
While other issues have dominated the various conversations, I believe the principal role of NTIA vis-a-vis
ICANN has been to act as a guarantor of the various agreements and good behavior. When, early in ICANN's
history, some staff members asserted that they were the final authority on various protocol parameter
assignments and on the management of the “ARPA.” infrastructure domain, NTIA was able to step in andcorrect that behavior. Various communities have moved forward on the assumption that other agreements would
be kept and extreme abuses prevented simply because of the possibility of NTIA stepping in if they were not.
Reasonable people can claim that NTIA has intervened when they should have refrained from doing so and point
to examples; equally reasonable people can point to examples where they believe NTIA should have intervened
and did not.
The NTIA role in approving root zone changes is separate from the guarantor one and, assuming ICANN
remains rational and is not captured by some particular interests, can reasonably just be discontinued as the
proposal suggests (0.II.08)
Given that role as guarantor, which I believe is key to “stewardship” (as distinct from “oversight” or“management”) a transition away from NTIA stewardship should carefully address the question of who or what
will provide the needed guarantees or, if they are no longer needed, explain why that is no longer the case.
Instead, the present set of proposals appear to assume that the appropriate way to replace that NTIA role is toKlensin, 2015‐09‐08, page 2

abandon it, taking on faith that there will be no abuses or attempts by one community to intrude on the role ofothers in the future. They add a great deal of new structure (see below) but those structures are all vulnerable toprecisely the situations that NTIA's involvement has guaranteed against.
Issue: The proposal does not provide a replacement for NTIA's role, merely drops it and introduces a lot of new
structure within the IANA and ICANN frameworks.

IANA as an Administrative Function
When the IANA function was first created in cooperation with what was then called the Internet Activities Board,a key goal (at least according to more or less contemporaneous discussions with Jon Postel) was to insulate it
and a number of functions from both policies and concerns about conflicts of interest associated with people
with commercial or contractual interests that might be affected by IANA decisions. That boundary was
reinforced by Jon's profound desire to avoid becoming a judge or someone who had to referee disputes among
others. In many respects, the role and operational function of IANA could be summarized as: someone requests
a value, IANA checks the request, assigns a value, and writes it down in a book.
That function gradually began to change in the late 1990s, primarily with the advent of ICANN and transfer of
IANA responsibility to it. Instead, IANA began to be perceived as a policy leverage point, initially by ICANN
staff and then more broadly. That “policy leverage point” model (almost always described in other ways) was
reinforced when the original ICANN contract with the US Government was replaced by the Affirmation ofCommitments. As a result IANA became the obvious point for policy intervention.
NTIA tried to control the risks associated with that policy leverage issue by insisting, in various generations of
the IANA contract, that IANA staff not be involved with ICANN policy functions. Unfortunately, at least in myopinion, that effort to prevent problems ran into trouble, partially because IANA staff sometimes had greater
expertise on various issues than anyone else in the ICANN system and partially because the result was that only
NTIA could intervene with IANA on policy issues.
Issue: To the extent to which the key elements of the proposal involve replacing the NTIA role with mechanisms
internal to IANA or ICANN only, rather than some external oversight mechanism, then it is critical to remove thepolicy leverage point aspect from the IANA function. If that boundary were [re-]established more clearly, then
IANA could again be treated as a purely administrative function and its relationship to parties other than the
IANA customer groups would be largely irrelevant except for mechanisms to ensure that IANA data remained
openly and publicly available.

Committees, organizations, complexity, participation barriers, and accountability
To a considerable extent, the Internet was designed and built on the principle that complexity should be
minimized and that complexity is, indeed, the enemy of a reliable, stable, and predictable network. The end-toend principle, which is ultimately about keeping complexity at the edges of the network and away from thecenter and network functions, is ultimately just a corollary of that low-complexity principle. ICANN, whether
necessarily or not, has never operated according to that principle. Over the years, the tendency has been to
create more and more organizational structure and organizational complexity. That evolution has been
Klensin, 2015‐09‐08, page 3

characterized by very long reports and proposals that no one other than those who are heavily invested canactually read and study. Committees have been appointed to study and investigate various issues and often given
unworkable scope or unrealistic schedules. Those committees have, in turn, tended to recommend theappointment of additional committees. Sometimes, if staff or others don't like the answers from the committees,
they are replaced by others who produce new reports until the answers are considered more acceptable. Many ofthese efforts drag on for months or years, with much of the work being done by people whom ICANN considers
volunteers. Very few people can afford to “participate” at the level needed unless they have corporate ororganizational support with very significant travel and salary (or equivalent) resources. Unsurprisingly, thatlevel of support tends to come from organizations who have a vested interest in particular ICANN outcomes,
whether that be protecting profits, creating new business opportunities, or pushing a particular technologicalapproach. The net result is that ICANN claims very active and involved participation in many of its activities,
but the actual participants tend to come from a relatively narrow range of organizations and interests, primarily
those with self-interest in, or support from, the marketing and sales of domain names and those who are directly
or indirectly supported by ICANN itself.
The result has been a collection of organizational structures that are extremely vulnerable to capture and thathave appeared to have been captured on several occasions. The multiple and complex structures also reduce
accountability in practice: ICANN claims wide consultation and that they were just following committee advice(even when they appointed those committees and controlled their membership and scope); one committee claims
that another one was responsible. The PTI structure, especially with some of the details still unspecified or tied
to the CCWG work, appears to provide an opportunity for an even more extreme example of obscured
accountability. It is an affiliate/subsidiary that is intended to be independent, with its own leadership andmanagement. At the same time, it is under ICANN control for budgetary matters, perhaps general strategy.
ICANN remains responsible for agreements with the IETF and other bodies, agreements that must be
implemented by PTI but with no clear lines of authority to fulfill those responsibilities. Adding additional
structure, such as the proposed “Customer Standing Committee” on top of all of this appears to me to amplify
the problem. Especially given the history of ICANN and some of the same constituencies who were involved
with formulating that proposal, the proposed structure seems to me to be a perfect opportunity for each ofmultiple entities to claim that they are not responsible for any given situation or problem. They may not evenhave (or claim) responsibility for identifying who is responsible.
Issue: The proposed arrangements are far more complex than they actually need to be, especially for an IANA
that is largely or entirely an administrative function rather than a policy-making one. The complexity creates
opportunities for both capture and for badly obscured or nonexistent accountability.

The multistakeholder model and the Internet community
Given that the goal of this activity is to “transition the stewardship of key Internet functions to theglobal multistakeholder community” it is necessary to examine what that term means if the community
is to evaluate proposals. It seems to me that the term raises two important issues, at least one of which
has been an issue for ICANN since its inception. First, there is a real question about what is required to
be a “stakeholder”. Does that require being materially concerned with the work or its outcomes? Does
it include people with no real historical involvement with the Internet but an interest in “governance”
Klensin, 2015‐09‐08, page 4

models or world government and a desire to experiment with them at large scale? People who, toparaphrase an influential ICANN staff member, simply have too much time on their hands? Whether
one accepts a narrow or broad definition of “multistakeholder”, it should be clear that the term includes
materially concerned parties, with whom one disagrees as well as those with whom one agrees or who
share one's own particular interests.
I note that the very ability to participate actively in “over 100 calls and meetings and over 4,000
mailing list messages” (0.IV.A.1.17) excludes participants and, in all likelihood, stakeholder groups, by
attrition and exhaustion. “No objections or minority statements recorded” (ibid) may indicate
consensus or even unanimity; it could also indicate that everyone who did not agree with the wellresourced CWG mainstream dropped out before the opportunity to express dissenting positions arose.
Second, however the community for which CWG is speaking is defined, there is a question about how
representative the proposal is of that community (much less, of course, of the global multistakeholder
community concerned with domain names. We know that a certain level of non-representativeness has
been a consideration of the NTIA instructions (0.IV.D.43 and elsewhere): at least as those instructions
have been interpreted, governments are not permitted to have a significant role in the resulting proposal.
From observation, they (other than NTIA) have participated very indirectly, if at all, in the various
processes of proposal formulation. More important, both the proposal formulation process and the
proposals themselves have primarily involved the three IANA “customer” communities – protocol
parameters, addresses, and domain names – plus, insofar as it does not consist only of the names
community, ICANN itself. When we consider the broad Internet community, or even a broad
selection of entities who might reasonably be considered as stakeholders, that group represents a very
narrow range of interests: the protocol parameter and address communities because they have (quite
properly) focused on what they need to keep IANA functioning properly, efficiently, and fairly for theirrequirements, and the domain names (and broader ICANN) communities for the reasons discussed
above.
The choice to concentrate on those three “operational communities” may be reasonable –and I think
that, for IANA issues, it is-- but we should not confuse oversight and control by them (or probably evenby the 13, mostly self-selected, communities represented on the ICG) with “global multistakeholder
community”. While noting that review of the proposal by those communities is different from review
by the broader Internet community, I believe that the ICG is probably diverse enough, and sensitive
enough to broad Internet interests, to be able to assess whether a proposal is acceptable to the broader
community but note that conclusion is very much open to challenge. In particular, the argument in
0.IV.D.2.46ff depends heavily on the assumption that the current arrangements for IANA oversight andinteractions are sufficiently representative of the global multistakeholder community that replacementsthat are no worse are also adequately representative.
Issue: If the meaning and implications of “global multistakeholder community” or “multistakeholder
Internet community” are carefully considered, neither this process, nor the ICG membership, nor theKlensin, 2015‐09‐08, page 5

proposal, are actually representative of those broader communities. Moreover the process andperhaps even the ICG membership involved significant influence from clusters of parties who are
arguably not stakeholders, especially in the IANA function.

Accountability to the Internet community versus accountability to narrow interests
This issue overlaps with the CCWG proposal but, since the ICG one depends on it (0.II.09, 0.IV.B.31 and 32 andelsewhere), a few brief comments. Any proposal to make IANA, or ICANN more broadly, more accountablemust have a clear (even if implicit) definition of who it is to be accountable to and then a comparison of the
proposal to that target. If the goal is “accountable to the global multistakeholder community” (or the“multistakeholder Internet community”, which may be a bit different), as the NTIA letter and the proposal
suggest, then accountability to a “community process” that appears to be able to be controlled by a single
ICANN constituency or cluster of interests (whether initially or through later capture) cannot do the job.
To be blunt, the CCWG proposal appears to make ICANN far more accountable to the names community(perhaps with a narrower definition than in 0.II.03) than it has historically been. If those changes are evenpotentially relevant to either the broader Internet multistakeholder community or even to the other IANA
Operational Communities, then having the ICG confirm with the CWG that its requirements have been met(X012, 0.II.09) is not sufficient – the possible consequences for ICANN have to be examined in the light ofpotential effects to all possibly-relevant communities.
Rearrangements of ICANN structures could be particularly problematic in areas where the operational
communities interact. For example, there is a long history of IETF (and predecessor) work constraining thestrings that can be used as labels in the DNS with examples including the original “preferred syntax” (“LDH”)
rules, the “will be alphabetic” constraint on names delegated from the root, and the IDNA approach tointernationalized domain names (rather than direct use of local characters). Could DNS processes over which
the “names community” had a higher degree of control, without the constraints imposed by NTIA as guarantor,
choose to ignore security, stability, or operational advice – treating ACs and other sources of input as advisory
entities whose advice could be dismissed-- in the interest of some commercial advantage to domain marketers.
Could those names market interests, under the proposed new model, bully the Board or other ICANN entities
into accepting their preferences? If the answer could even hypothetically be “yes”, it is hard to think about howthat would “Maintain the security, stability, and resiliency of the Internet DNS”.
Issue: While, especially if IANA can be isolated from policy-making and policy-leverage functions, it may bereasonable to make IANA accountable only to the Operational Communities (although that is debatable), if
IANA is to continue as an ICANN function or even under the umbrella of an ICANN affiliate or subsidiary, thensome changes to ICANN and how it is managed or controlled, especially those that might affect budgets, staff
working conditions, or other relationships, have the potential to later disrupt the IANA function. Either
changes to how ICANN is organized and mechanisms that could affect its internal power relationships should betaken off the table, or ICG should assure that those changes have no potential to either be disruptive or tochange the communities to which ICANN or IANA are accountable.

Klensin, 2015‐09‐08, page 6

Nuclear options as the key protection
The proposal indicates that the accountability mechanisms rely “mostly on the right of each operational

community to select a new entity for the performance of the IANA function” (0.C.2.36 and elsewhere).
That reliance raises several issues. First if the right to withdraw is the main tool available to thosecommunities, then this is an immensely long and complex proposal, with a tremendous number ofsmall details. There are far more details and provisions than are needed to secure that right; thoseadditional proposal elements arguably contribute almost nothing is the principal protection iswithdrawal. It would seem far more productive for the proposal to focus on mechanisms for working
out, or even forcing, course corrections should IANA somehow stray away from expectations.
Provisions with a goal of encouraging corrections seem to be deemphasized or to be very weak. The
IETF proposal and the traditional modes of interaction between IETF and IANA is an exception, butthat tradition seems to be only weakly reflected in these elements of the combined proposal. Suchmeasures appear to be completely absent from the “names” proposal.
If the intent is really to rely on the ability of each community to pull out, presumably destroying theunified IANA function in the process, then I would expect the proposal to contain far more analysis of
the consequences of such moves, e.g., on whichever operational communities were left. Equally or
more important, we know from real-world experience with such options that they often have more of adeterrent effect, encouraging good behavior lest disaster ensue, than an actual effective measure given
the disruption, work required, and other bad effects on the parties involved. While the text indicatesthat requirements are in place to help ensure that any such future changes of the IANA functions
operator “will not result in operational disruptions” (0.IV.C.3.40), the mechanisms outlined for thecases in which one operator withdraws are not convincing. It would seem far preferable to figure out away to enforce the keeping of commitments made by IANA (or ICANN, or PTI).
Issue: Even for the IANA function in isolation, there should be better controls on IANA and ways toguarantee expected behavior rather than merely the fear of one of the operational communities
deciding to withdraw and make its own arrangements.

A historical correction
The proposal claims, e.g., in Executive Summary paragraph X003, repeated in different words in
0.II.03, that “the policy and oversight responsibilities for the three functions resides in these three
separate communities (and has for decades).” This is actually not true and understanding why may be
important. First, for many years, although the processes tended to be very consultative, IANA (atUSC-ISI) was the policy authority for protocol parameters and addresses. Although the IAB (and later
the IETF) made requests, IANA decided what protocol parameter registries would be created anddecided what values would be allocated in them. Similarly, allocation of address ranges to the RIRs
that existed at the time was an IANA function, not one for which policy was set by the RIRs
Klensin, 2015‐09‐08, page 7

themselves (nor by the “address community”, which I cannot remember even being discussed as anentity during that period). If there was any formal oversight at the time, it came from combinations of
US Government agencies, notably the National Science Foundation (NSF) and the Federal Networking
Council in the 1990s That pattern of IANA authority relative to protocol and address registries began
to shift in the 1990s as the IETF asked for and received more control over the registries being createdand values allocated in them, followed by a more dramatic shift with ICANN's creation. By the time
the IETF-ICANN MOU (RFC 2860) was published in 2000, detailed policy and oversight control overprotocol parameter registries, including specific values to be allocated, lay entirely with the IAB/IETF,
but that is not “decades”.
The pre-ICANN situation with DNS Top-Level Domains was even more clear. IANA controlled thedecisions about what was allocated and to the entities to whom names were delegated. Although RFC
1591 was not published until 1994, it documented practices that had been in effect for many years.
Rather than being an announcement of new policies, it was very much an authoritative IANA
description of how things were being done for the information of the community. It was not in any
sense an IETF or other externally-approved document. The policy model in RFC 1591 for ccTLDs wasvery different from that for gTLDs, with the determination of eligible entities and the codes that would
be used for the former effectively delegated to the Maintenance Agency for ISO 3166 and IANA
assuming responsibility for taking applications from relevant entities and making delegation decisions.
Those decisions, especially those that were at all controversial, were generally highly consultative with
IANA tending to wait until the various parties reached agreement prior to taking action. When relevant,various other individuals and bodies, including staff of US Government agencies and someinternational bodies, were consulted. For gTLDs, the general assumption, partially reflected in the textof RFC 1591, was that the use of hierarchy in the DNS and availability of registrations in a variety of
domains if an initial choice was not suitable, would continue to make additional gTLDs unnecessary
unless a completely new scope of coverage or application appeared. Nonetheless, the IANA retained
the ability to allocate and delegate them should they prove necessary (the last pre-ICANN gTLD
allocated, “INT.”, was considered a new scope of coverage at the time).
The above description applied, with only small variations, until ICANN was created. There was no“names community”. There were regional ccTLD discussions in conjunction with other regional
network bodies but they were not setting policy for ccTLD applications or policies generally. So, in
terms of a “names community” controlling policy or oversight for part of the IANA function, certainly
not decades.
Issue: Historical accuracy is important in its own right. It is particularly relevant to the present
proposal only if people reason from it but, to some extent, it appears that people have reasoned fromstatements consistent with those in the document.

Klensin, 2015‐09‐08, page 8

i
For identification, the author served as an adviser to IANA on policy matters from the early 1980s throughthe organization of ICANN, including as a member of the Internet Domain Names Board (IDNB) and bothcommittees to plan for the transition of IANA functions out of USC-ISI, was involved in several of the efforts that led
to ICANN, attended the organizational meeting of the initial (“interim”) ICANN Board, and later became the IABappointed Liaison to the ICANN Board. He has served ICANN in multiple other capacities, including as a Nomcom
member and as a sometime advisor and consultant on internationalization issues, including policy development efforts
for International Domain Names. In the IETF, he served as Area Director for Applications, chaired or co-chaired
many working groups involving both technical standards development and policy and procedure development. He
served twice as a member of the IAB and served once as its chair. He was on the MIT research staff for nearly 25
years, became MCI's first Distinguished Engineering Fellow, and was Internet Architecture Vice President at AT&T
Labs. He holds an S.B. in Political Science and an interdisciplinary Ph.D. from MIT.

Klensin, 2015‐09‐08, page 9