Research
Article - ICANN Reform - Structure and Mission (June 2002)
- Introduction
- Reform of ICANN’s structure
- Current problems
- Principles of Reform
- Details of the reforms
- The mission debate
- The mission proposal
- ICANN’s technical responsibilities
|
Introduction
This is the first of a two part article considering proposals to reform the Domain Name System, and more specifically ICANN. Part One considers reform of the structure of ICANN, and Part Two considers reform of ICANN’s mission and responsibilities.
ICANN is a private, not-for-profit corporation set up in 1998 to help co-ordinate certain key aspects of the Internet’s technical infrastructure. Specifically, it was given responsibility for ‘coordinating the Internet’s naming, address allocation, and protocol parameter assignment systems.’[1] Four years later, proposals have been tabled to reform both the structure and mission of ICANN.
The CEO and President of ICANN, Mr Stuart Lynn, issued a report on 24 February 2002 entitled ICANN: The Case For Reform.[2] This contains a critical analysis of ICANN operations and achievements against its mission, and recommends major changes in structure and operations. His focus is on what he perceives as an ‘undue focus on process to the exclusion of substance and effectiveness’.
The following text is an edited summary of his proposal.
Reform of ICANN’s structure
ICANN’s assigned mission - to create an effective private sector policy development process capable of administrative and policy management of the Internet’s naming and address allocation systems - was incredibly ambitious. Nothing like this had ever been done before. ICANN was to serve as an alternative to the traditional, pre-Internet model of a multinational governmental treaty organization. The hope was that a private-sector body would be like the Internet itself: more efficient - more nimble - more able to react promptly to a rapidly changing environment and, at the same time, more open to meaningful participation by more stakeholders, developing policies through bottom-up consensus. It was also expected that such an entity could be established, and become functional, faster than a multinational governmental body.
It is now more than three years since the creation of ICANN, and there are some real accomplishments: the introduction of a competitive registrar market, the Uniform Dispute Resolution Policy, the creation of seven new global Top Level Domains. But despite this progress, all the original expectations of ICANN have not been realized. ICANN is still not fully organized, and it is certainly not yet capable of shouldering the entire responsibility of global DNS management and coordination. ICANN has also not shown that it can be effective, nimble, and quick to react to problems. ICANN is overburdened with process, and at the same time underfunded and understaffed. For these and other more fundamental reasons, ICANN in its current form has not become the effective steward of the global Internet’s naming and address allocation systems as conceived by its founders. Perhaps even more importantly, the passage of time has not increased the confidence that it can meet its original expectations and hopes.
I have come to the conclusion that the original concept of a purely private sector body, based on consensus and consent, has been shown to be impractical. The fact that many of those critical to global coordination are still not willing to participate fully and effectively in the ICANN process is strong evidence of this fact. But I also am convinced that, for a resource as changeable and dynamic as the Internet, a traditional governmental approach as an alternative to ICANN remains a bad idea. The Internet needs effective, lightweight, and sensible global coordination in a few limited areas, allowing ample room for the innovation and change that makes this unique resource so useful and valuable.
I have concluded that ICANN needs reform: deep, meaningful, structural reform, based on a clearheaded understanding of the successes and failures of the last three years. If ICANN is to succeed, this reform must replace ICANN’s unstable institutional foundations with an effective public-private partnership, rooted in the private sector but with the active backing and participation of national governments.
In short, ICANN is at a crossroads. The process of relocating functions from the US Government to ICANN is stalled. For a variety of reasons described in this document, I believe that ICANN’s ability to make further progress is blocked by its structural weaknesses. To put it bluntly: On its present course, ICANN cannot accomplish its assigned mission. A new path - a new and reformed structure - is required.
Current problems
ICANN’s major problems can be broadly categorized into three categories: too little participation by critical stakeholders (across the full range of infrastructure operators, major users and national governments); too much focus on process; and too little funding to provide quality services.
Too Little Participation by Critical Entities.
The essential participants in an effective ICANN are, in no particular order: (a) the various infrastructure providers of the Internet, broadly defined; (b) major users; (c) the relevant technical community and (d) national governments;
It is these participants that are absolutely essential for ICANN to carry out global management and coordination effectively. And their participation must be more than token. They must be actively involved; those that are part of the name and address operating infrastructure must be willing to agree to abide by the results of the ICANN policymaking process; and they must fund the process at levels adequate for ICANN to function effectively.
It is worth describing in some detail why certain of these participants are essential.
ccTLDs:
An ICANN process without the full participation of the 243 ccTLDs cannot accomplish its core objectives of privatization and internationalization. More specifically, ICANN would be unable to deliver on two of its core assigned responsibilities: (i) assuring global DNS interoperability and stability; and (ii) delegating - through a framework of responsible agreements - non-technical policy matters to politically accountable local organizations, wherever feasible.
For ICANN to limit itself to its global coordination function, it must extricate itself from highly politicized local policy matters that arise most prevalently with ccTLDs. In nearly all redelegation cases, disputes over the administration of a local ccTLD turn on the determination of the will of the local Internet community - which, together with technical competence, constitute the criteria by which redelegation decisions are to be made, according to longstanding IANA policy. Consistent with the core ICANN mission, those responsibilities can only be devolved to local Internet communities if there are available meaningful and accountable alternatives to ICANN. For these alternatives to qualify as fully accountable necessarily requires some involvement and supervision by the local government or of a publicly accountable body that is recognized by the government.
Without formal agreements, the global Internet community, working through ICANN, has today only one tool - albeit an impractical one - to ensure compliance with global policies by those (almost all) ccTLD administrators that do not have a binding agreement with ICANN: ICANN could, in theory, recommend that a particular ccTLD be redelegated to a cooperating administrator, and if the US Government accepted that recommendation, non-cooperating ccTLD administrators would be replaced. But this course of action runs counter to the basic ICANN mission, since it could be very disruptive, at least in the short term. What would solve the problem in many jurisdictions would be for national governments to use their good offices to assure the cooperation of their ccTLD administrators. As we have seen with Australia and Japan, national governments can take actions to create the proper environment for appropriate ICANN/ccTLD agreements. Without similar actions by other governments, for the most part this problem will not be solved. Thus, an ICANN with more active encouragement by national governments (as originally conceived) would be more likely to achieve the necessary agreements with ccTLDs that are critical to a successful ICANN.
Root Name Server Operators:
The root name server operators are a different story. These are not funded by ICANN but today are supported by the public-minded generosity of their sponsoring institutions and by the personal commitments of the individuals involved. Three root name servers are operated by US Government agencies; several more are operated at US locations, most by government contractors of various sorts (such as VeriSign). Three are outside the US, one each in the UK, Sweden and Japan. Today, the 13 root name server operators are the critical source of the single stable and authoritative root.
It is essential that the root name server operators be full and complete participants in the ICANN process. That logically requires stable and appropriate agreements between ICANN and the institutions and individuals that operate the root name servers. After more than two years of discussions, we have reached a general consensus among the various root name server operators and ICANN on a form of MOU. But the progress has been agonizingly slow.
Address Registries:
The address registries are similar to the ccTLDs in the sense that there is only a small, but important, element of global coordination required in this area. Most address policy decisions can be made at the regional (RIR) level, but ultimately there is a small aspect of absolutely necessary global coordination. We are close to agreements with the RIRs, but those agreements (which have been heavily negotiated over the last two years) are arguably incomplete in two respects: (a) they allow the address registries to opt out of ICANN policies with which they do not agree, by taking the ultimate step of terminating the agreements, and (b) they include special limitations on the proportion of ICANN’s funding requirements that the address registries will provide under those agreements. While these are not fatal flaws by any means, given the cooperative nature of the RIRs - and are not the most critical issue facing ICANN - they are another illustration of the difficulty in gaining the necessary voluntary and complete cooperation of all the critical participants needed for ICANN to accomplish its mission.
Major Users, ISPs and Backbone Providers:
The vast majority of the business community (outside of the registries and registrars who are most directly affected by ICANN’s policies) has chosen not to participate in the ICANN process. There have been, of course, some notable exceptions among a few corporations and trade organizations, but these are a minority. ICANN is very grateful to those organizations that provided the funding that was so critical to ICANN’s early survival, but outside of those registries and registrars who are contractually committed, broad participation by those commercial entities that most depend on a reliable Internet has not been forthcoming.
The ICANN policymaking process is impoverished by the absence of most of the entities with the greatest direct interest in DNS stability and those whom its decisions will most directly impact, and by the consequent overrepresentation of advocates for one special interest or another. While this lack of participation by those who critically depend on the successful fulfillment of ICANN’s mission may be explainable, it puts enormous pressure on what is supposed to be a consensus development body to come up with responsible policies when major stakeholders are silent.
National Governments:
Perhaps the above points are self-evident. What may not be quite so obvious is my conclusion, based on all our experience to date, that active national government participation in ICANN is critical to its success.
Indeed, in the final analysis, national governments are perhaps the most irreplaceable supporters of ICANN, in the sense that - notwithstanding the efforts or desires of other stakeholders - the backing of governments is necessary if private sector coordination of the Internet’s naming and address allocation systems is to be feasible. If governments choose to take direct responsibility for the management of the name and address systems of the Internet, they have the power to do so. And even if they do not make that choice, given the importance of the global resource that ICANN has been established to coordinate, it is unrealistic to think that governments will simply sit by and allow ICANN’s processes to work without their careful attention and review.
Today, the Governmental Advisory Committee is the only formal mechanism for governmental input into ICANN. Despite significant effort by many of its members, it has been only a minimally acceptable vehicle, partly because of a lack of adequate commitments by the world’s governments and partly because of the Internet community’s own ambivalent attitudes (reflected in the attitude of ICANN, which is a composite of that community) towards government involvement. In addition, while all governments are invited to participate, the existence of the GAC has not generated the scope of governmental participation and commitment that is necessary for ICANN’s long-term success.
I recognize that proposing an increased role for governments in ICANN is a significant departure from the original conception of ICANN as a purely private sector body, but I am convinced an increased governmental role is essential if ICANN is to carry out its mission. Appropriate national government participation would contribute greatly to the success of ICANN in at least two ways. First, it could provide the public interest accountability that all agree should be a part of any global ICANN-like organization. Second, it would increase the likelihood that governments would more effectively encourage the participation of their national citizens and entities that is critical for ICANN’s success.
Too Much Process.
ICANN was born with a particular and intense focus on process and representation. Undue focus on process to the exclusion of substance and effectiveness is the second major problem facing ICANN.
In many ways, ICANN’s creation was a political exercise, working from the outside in: what structure is required to secure the participation of this group or that group? The result was an entity in which most of the groups seen to be essential at the time were willing to participate, but not necessarily in a way or within a structure that was designed to be effective. The driving notion at the time of ICANN’s creation was consensus; it is clear to me that the driving notion today, with the renewed focus precipitated by the events of 9/11, must be effectiveness. Like any institution with responsibility for key infrastructure, ICANN must be able to act when needed.
This is not to say that process, participation or representation are irrelevant or undesirable. They are highly relevant, but they must be viewed as means to achieve ICANN’s goals, not ends in themselves.
The intense focus on process at the time of ICANN’s creation was in part driven by a reasonable desire among some to shield the Internet from hasty, unsophisticated or foolish decisions by ICANN, a new and untested institution. However, that impulse, coupled with a widespread failure to understand ICANN’s inherently limited scope and lack of coercive authority, caused the creation of ever-more procedural loops and layers at the expense of overall Internet-speed effectiveness. There were even attempts to cause ICANN to implement the thousands upon thousands of pages of administrative and regulatory procedures that apply to US government agencies - a move that is totally inconsistent with the reason for creating a private sector organization in the first place.
This focus on process was also produced by what in hindsight was oversensitivity to the possible involvement of governments and governmental bodies in ICANN. The fact is that the Internet, and therefore management and coordination of the naming and addressing functions of the Internet, are critically important to governments, because they are critically important to their citizens and businesses. It is naïve to assume that governments will not be heavily interested and involved in global policymaking for these areas. In the current ICANN structure, however, government involvement is limited to the advisory function of the Governmental Advisory Committee. The disconnect between this theoretical limitation, and the actual power and influence of governmental bodies on the management of such a critical global resource, has been increasingly evident in the tension between the GAC and other parts of the ICANN structure.
This deliberately limited role of governments in ICANN inevitably fueled demands for other and different accountability structures. Since ICANN would eventually ‘control’ an important global resource, the argument went, it must be accountable to those affected by its decisions. These include, at least abstractly and in the view of some, every person and entity in the world. Thus, we have seen calls for global elections by all interested individuals, and demands for Board representation and other indicia of status by various groups and affected entities.
One of the reasons why ICANN has not yet generated the necessary support and involvement of critical stakeholders is that many participants in the ICANN process have devoted very significant attention to various non-core issues that should not, in my opinion, receive such overwhelming priority. The effect of these distractions has been ICANN’s appearing to many as a collection of squabbling interests, tied up in an elaborately complicated organizational chart. The single largest distraction from what should have been the central ICANN focus has been the many competing notions of an At Large membership.
I am now persuaded, after considerable reflection, that this concept was flawed from the beginning. The notion is noble but deeply unrealistic, and likely to generate more harm than good. We now have three years of very hard effort by a wide variety of people to arrive at some workable consensus solution - and there still is none. If a blue-ribbon committee - headed ably by a former Prime Minister of Sweden and United Nations Representative to Bosnia, and populated by highly respected and hardworking members - cannot generate a community consensus on this subject, it is likely there is no consensus to be found.
A very significant portion of the total resources devoted to ICANN over the last three years has been spent trying to solve the tension between the desire for more government-like representation and accountability, on the one hand, and a workable, effective and stable ICANN on the other. It is now time to recognize that effectiveness in the management and coordination of name and addressing policies is the primary objective of ICANN, and that process and representational values must be served in ways that are compatible with the primary objective. To do otherwise is self-defeating; if ICANN is not effective, it will fail, and all the process and organizational structure in the world will not save it. A multi-national governmental substitute for ICANN will not be likely to provide the kind of process that some believe is essential for ICANN.
For all these reasons, I have come to the conclusion that the concept of At Large membership elections from a self-selected pool of unknown voters is not just flawed, but fatally flawed, and that continued devotion of ICANN’s very finite energy and resources down this path will very likely prevent the creation of an effective and viable institution. We must find another, more effective path for appropriate input into the ICANN process by the general user community that will accomplish the key purpose underlying the At Large concept - to ensure that the broad public interest is effectively reflected and protected in the ICANN consensus development process.
+The endless disputes over the feasibility and desirability of online elections represent a significant example of how much of the finite amount of ICANN energy available from a largely volunteer cadre has been drained on topics that are almost orthogonal to its key mission, but it is not the only one. The reconsideration process is another, where precious staff and Board time have been devoted to what are often clearly frivolous requests. It is time to get our priorities straight, and to reform ICANN’s structure and procedures so that they all assist, rather than impede, the achievement of its core mission.
Too Little Funding.
Finally, the third major problem is inadequate funding. ICANN began its existence with no guaranteed funding from any source - governments or private entities. Indeed, it survived its initial days only because of loans from public-spirited businesses (and the great good fortune that it was launched during the boom, not the bust, part of the global business cycle). It survives today on a heavily negotiated revenue stream generated from a small number of very interested intermediaries - who also have major influence in establishing the ICANN budget. Perhaps it is not surprising that ICANN has been seriously underfunded from its creation.
I believe ICANN is underfunded for the following reasons:
- There is a significant shortfall each year even within current budgets, because - without agreements in place - ccTLDs do not bear their appropriate share of the burden. There has been a $400-500,000 shortfall each year, a number that seems likely to increase absent a dramatic change in ccTLD attitudes. In addition, the RIRs, in the absence of any agreements with ICANN, have yet to contribute (although those funds have been put in escrow awaiting the completion of the necessary agreements).
- ICANN has accommodated that shortfall only through not hiring to authorized levels, and at the expense of building reserves. The former means that work is not done effectively; the ICANN process is dangerously understaffed, and has always been understaffed. The latter is extremely risky financially, as it would be for any organization, allowing for no unexpected expenditures including, for example, litigation expenses.
- Even more importantly, existing budgets would be completely inadequate even if fully funded. ICANN has little or no backup of key individuals, making the organization extremely vulnerable to the loss of those key people. This could lead to serious instabilities in certain circumstances. Beyond that, there are too few staff to do a proper job - even while many current staff are already working unsustainable long hours. ICANN
- Perhaps even more importantly, the ICANN process as presently funded will never be able to fulfill its intended coordination and consensus building tasks, its IANA and other technical tasks, its security responsibilities, its legal coordination and contract monitoring tasks, and its management tasks. Furthermore, costs are increasing even to pursue its current activities.
Overall, the ICANN process is understaffed by at least 10-12 fulltime employees, and possibly more - depending on what it is expected to accomplish. A fully funded ICANN probably requires an operating budget of 300-500% of its current budget level, plus funding for significant one-time expenditures if funding of root name server operators and the establishment of appropriate reserves are included.
This level of needed funding requires a very different kind of funding structure from the one that exists today. My conclusion is that the funding sources of ICANN must be broadened, and overall funding must significantly increase. Today, ICANN depends entirely for its funding on the cooperation of those entities who generate revenues from servicing the names and address space, who essentially serve as intermediaries between ICANN and the name registrants that are the ultimate source of those funds. This is a limited number of entities, and thus leaves ICANN overly vulnerable. In addition, it means that the other participants that are critical for ICANN’s success do not have an immediate or direct stake in the ICANN budget. All of the participants in the ICANN process that have the ability to pay a share of ICANN funding should do so. With ‘skin in the game,’ these participants will feel a more immediate and direct connection to the success of the ICANN process. And this includes governments.
Principles of Reform
Based on the experience of the last three years and my own focus on ICANN over the last year, I am convinced that a reformed ICANN can be successful - if we re-focus on our core mission, reform our institutional foundations to fit that mission, and eliminate the distractions of peripheral issues and agendas.
To be clear: ICANN’s mission is effective management and coordination of those few, higher-level elements of the Internet’s naming and address allocation systems that require or benefit from global management and coordination, while abstaining from actions that might interfere with the creativity and innovation that has made the Internet such a dynamic resource. ICANN’s mission is stewardship and operational stability, not the defense of its existence or the preservation of the status quo.
Having said that, it is essential to state unambiguously what falls outside of ICANN’s scope. The core ICANN mission includes no mandate to innovate new institutions of global democracy, nor to achieve mathematically equal representation of all affected individuals and organizations, nor to regulate content, nor to solve the problems of the digital divide, nor to embody some idealized (and never-before-realized) model of process or procedure. However important those ideals may be, they are for other, better-suited organizations to address. Unfortunately, we have allowed the advocates for these and other non-core objectives to divert ICANN from what must be its tight focus on its core mission. These diversions have been and will continue to be a significant impediment to accomplishing ICANN’s core mission, unless we undertake a powerful reform of ICANN’s structure and operations, and a committed refocus on its limited but important mission.
Core Values Should Be Preserved
Central to the ICANN experiment - and integral to its successes thus far - have been core values of openness and broad participation. I believe strongly in those values, and aim to strengthen them in a reformed ICANN. ICANN can and should do much better in achieving transparency, enabling meaningful participation, and reaching out to involve the global diversity of the Internet.
A New Public-Private Partnership Is Necessary
I am now convinced that the original desire to avoid a totally governmental takeover of the IANA functions led to an overreaction - the choice of a totally private model. With three years’ experience, it is clear that model is simply not workable. It is not workable because it leaves ICANN isolated from the real-world institutions - governments - whose backing and support are essential for any effective global coordinating body to accomplish its assigned tasks. ICANN currently has an advisory committee to channel governmental input, but that mechanism has not effectively integrated the views or the influence of governments; we must find a better way.
Though many in the traditional Internet community react strongly against the very mention of governments, it is simply unrealistic to believe that global coordination of the DNS can succeed without more active involvement of governments. Indeed, it has been for decades a bedrock principle of the Internet that technical managers should stick to what they know and do best, and leave to other organizations what they in turn do best. Governments play a unique role in representing the broad public interests of their populations. So far, ICANN’s existing structures have not engaged the attention, commitment, and support of governments to the necessary degree.
What is needed at this stage if ICANN is to carry out its mission is neither a totally private nor a totally governmental solution, but rather a well-balanced public-private partnership. Stable functioning of the Internet’s naming and address allocation systems is too important to national economies and other national goals for governments to be left on the sidelines. Experience has shown that the influence, authority, and close cooperation of governments is essential to accomplish ICANN’s mission. Because of the significant advantages represented by a strong private-sector organization, however, we should seek a robust and effective middle ground - the right public-private partnership - that will incorporate the best of both extreme options.
The mission debate
As the dialogue about ICANN reform continues, it is useful to also focus on the ICANN mission. It is difficult to arrive at a consensus about ICANN’s structure and procedures unless there also exists a consensus on what ICANN’s mission is - and what it should be going forward.[3]
It is quite clear that, to date, ICANN’s mission has not been limited to only technical coordination. As one obvious example, the promotion of competition is not a technical objective, but it has been an important part of ICANN’s mission from the beginning. Nevertheless, ICANN’s mission cannot be open-ended; there must be understood boundaries, or ICANN risks losing its focus. Thus, the development of a common general understanding of what types of global coordination activities are either required or highly desirable for the proper functioning of the Internet’s naming and address allocation systems, and thus reasonably fall within the ICANN mission, is an important component of the ongoing ICANN reform effort.
The mission proposal
This document is an attempt to provide a beginning point for that discussion by enumerating the most significant activities that ICANN does today. It is not intended to be an exhaustive list, or a defense of a particular structure or mission, but simply a statement of current fact. The hope is that this description of the status quo will facilitate a substantive debate about what (if any) changes - additions or subtractions - are appropriate going forward, and how the boundaries that result from that discussion can best be articulated. That in turn should be a useful contribution to the community discussion about the nature of the reforms to ICANN’s structure and procedures that are best suited to ICANN effectively carrying out its mission.
Mission overview
The Internet Corporation for Assigned Names and Numbers (ICANN) is responsible for coordinating the Internet’s naming, address allocation, and protocol parameter assignment systems. These systems enable globally unique and universally interoperable identifiers for the benefit of the Internet and its users.
These systems are highly distributed: hundreds of registries, registrars, and others, located around the world, play essential roles in providing naming and address allocation services for the Internet. ICANN’s paramount concern is the stability of these remarkably robust services.
As overall coordinator of the Internet’s systems of unique identifiers, ICANN’s role, while defined and limited, includes both operational and policymaking functions.
Operations
In the operational sphere, the ICANN staff perform a range of day-to-day services, including:
(1) maintaining the DNS root zone file,
(2) allocating top-level blocks of IPv4 and IPv6 addresses and AS numbers to the regional Internet registries,
(3) maintaining 120+ registries of protocol port and parameter numbers,
(4) publishing online databases of information about the top-level domain registries included in the DNS root zone file,
(5) operating one of the thirteen authoritative DNS root name servers, and coordinating the overall DNS root name server system,
(6) publishing the InterNIC website and related functions,
(7) operating the .int registry,
(8) maintaining common/technical IP address spaces, such as the private-use address space,
(9) managing the reverse delegation namespace at the top level, and
(10) administering the DNS implementations of certain technical registries, such as .arpa and the legacy infrastructure-related .int zones.
In addition, ICANN staff perform a set of day-to-day administrative and policy functions relating to the generic top-level domain (gTLD) registries, including:
(1) accreditation of competitive registrars;
(2) supervising the administration of the Uniform Dispute Resolution Policy;
(3) handling of complaints about registrations;
(4) monitoring and enforcement of registry and registrar agreements, and
(5) implementation of data escrow programs.
For the country-code top-level domain (ccTLD) registries, ICANN staff handle, investigate, and process requests for delegation and redelegation, and for changes in the TLD nameservers specified in the root zone file.
Security
Finally, ICANN has the responsibility for policy coordination with respect to the security of the various parts of infrastructure that make up the operational DNS. This activity is reflected in the recent creation of the Standing Committee on Security and Stability. In addition, ICANN has certain operational security responsibilities with respect to ICANN’s operational activities. Finally, ICANN attempts to nurture and encourage continuing and serious attention to security and stability issues by all participants in the DNS, and to ensure that necessary tasks are undertaken by some responsible party.
Policymaking
In the policymaking sphere, ICANN is responsible for developing and implementing policies related to each of its operational functions. The nature and scope of ICANN’s policymaking role differs for each function.
For example, in the area of IP address and AS number allocation, ICANN’s responsibility extends only to global addressing policies; local policies are made by each regional Internet registry or lower-level Internet registries. ICANN’s policy role for the country-code top-level domain registries (ccTLDs) is similarly limited to global policy coordination with deference to each local Internet community’s responsibility to set its own registry-level policies (i.e., registration criteria, pricing, dispute resolution, mechanisms for local community participation and policymaking, etc.). In the area of protocol numbering, ICANN administers the IANA registries pursuant to the instructions of the Internet Engineering Task Force (IETF).
By contrast, ICANN plays a more direct and significant role in setting registry-level policies for the global top-level domain registries (gTLDs), such as .com, .net, .org, .info, .name, and .biz. In effect, ICANN serves as the global Internet community’s open policymaking forum for the gTLD registries.
In its initial charge from the U.S. Government, embodied in the 1998 White Paper, ICANN policymaking was to be guided by a set of non-technical principles: preserving stability; promoting competition; relying where possible on private-sector, bottom-up, participatory mechanisms that reflect the functional and geographic diversity of the Internet; development of efficient dispute resolution alternatives (for the gTLD registries); and promoting accountability in management (for all registries).
These principles are necessarily somewhat general, which has led to some confusion and disagreement about the exact boundaries of ICANN’s policymaking mission. This has led some to suggest that those boundaries should be restated and described in as much detail as is feasible, taking into account the necessary flexibility required to effectively deal with the rapidly changing nature of the Internet. Such an effort, to the extent it produced useful guidance both for ICANN and the Internet community as a whole, would undoubtedly be a helpful contribution to the current ICANN reform discussions.
Chris Connolly
Galexia
ICANN’s technical responsibilitiesNames - DNS Root Zone FileThe DNS root zone file consists of a list of all top-level domains in the authoritative public DNS, along with the names and IP addresses of the primary and secondary name servers that are authoritative for each TLD. ICANN is responsible for defining the contents of the DNS root zone file, which means maintaining and updating the list of recognized TLDs and the name servers for each TLD. ICANN is also responsible for promulgating the file for publication by the 13 authoritative root name servers. Specific tasks include: 1. gTLD DelegationThe term ‘delegation’ refers to the addition of a new TLD to the DNS. In narrow technical terms, this means that a new TLD entry is added to the DNS root zone file, along with the names and IP addresses of the authoritative name servers for the new TLD. The policy tasks necessary to delegate new gTLDs include the preparation of a request for proposals, the definition of selection criteria, the evaluation of the proposals in light of those criteria, the analysis of any public or expert comments, the selection of registries and registry operators, and the negotiation of registry agreements. 2. gTLD Re-DelegationThe term ‘redelegation’ refers to a change from one gTLD sponsoring organization or manager to another. Once created, a new gTLD is subject to potential redelegation if: (a) the sponsoring organization or manager voluntarily chooses to abandon the registry; (b) it breaches its registry agreement with ICANN; or (c) the term of the current registry agreement expires. 3. gTLD Name Server ChangesOn occasion, TLD registries modify one or more of their existing TLD name servers. For example, a gTLD name server might change from one ISP to another, or might decide to improve overall name resolution performance by adding a new name server, or replacing an existing one. 4. Monitoring, Enforcement, and Implementation of gTLD AgreementsICANN is responsible for monitoring and enforcement of the gTLD registry agreements, along with certain operational tasks, including the accreditation of competitive registrars, the implementation of data escrow programs, and the administration of the Uniform Dispute Resolution Policy. Where there are formal agreements for registration accreditation and data escrow, ICANN must also undertake monitoring and enforcement of them, along with any related operational tasks, such as the verification that any registry data escrowed with ICANN is complete and generated in the correct technical format. 5. Internationalised Domain NamesAs the Internet becomes more accessible to more of the world, and usage by non-English speaking populations increases, the need for some workable system of internationalized domain names also increases. This is both a technical and a policy issue. The technical problem is extremely complex, and is the subject of intense activity at the IETF aimed at the creation of a workable technical standard. 6. ccTLD DelegationTurning to the country-code TLDs, ICANN is responsible for the DNS zone file administrative functions of ccTLD delegation, ccTLD re-delegation, ccTLD TLD name server changes, and the implementation of ccTLD registry agreements (where completed). 7. ccTLD Re-DelegationFar more common than ccTLD delegation matters are requests to ICANN for the re-delegation of already-delegated ccTLD registries. Requests for redelegation are judged according to the same basic criteria as delegation requests, with the focus on technical competence, support from the local Internet community, and commitment to accept the fundamental public service responsibilities that are inherent in ccTLD trusteeship. 8. ccTLD Name Server ChangesICANN is responsible for processing ccTLD name server change requests. Whenever a ccTLD manager wishes to change one or more of its authoritative primary or secondary name servers in the DNS root zone file, a name server change template must be submitted to ICANN. Once the request has been verified, ICANN tests the new name servers to see that they are functioning properly, and proceeds to promulgate a new DNS root zone file with the updated name server information for the ccTLD. 9. IANA TLD DatabaseICANN maintains an online IANA database of contact information for each ccTLD and gTLD registry, including the identity of the sponsoring organization (meaning designated ‘trustee’ for the ccTLD); the name, physical address, e-mail address, and phone and fax numbers for the delegated administrative and technical contacts; and the URL for registration information. Names - Root Name Server SystemICANN is responsible for coordinating the stable functioning of the DNS root name server system. For top-level resolution of DNS queries, the DNS relies upon 13 geographically distributed root name servers (identified by letters of the alphabet). There are 12 different root name server operators, ranging from universities to military institutions to commercial enterprises to not-for-profit organizations (such as ICANN). All of the root name server operators are independent volunteers, receiving no outside compensation for their services. ICANN is responsible for overall coordination of this system, which includes day-to-day communication on operations and incident response. L Root Name ServerICANN is the operator of the L root name server, one of the thirteen authoritative DNS root name servers. This responsibility is purely operational. and entails a significant allocation of resources to support the necessary technical staffing, hardware, and bandwidth. InterNIC ServiceICANN is responsible for a set of Internet services designated by the InterNIC service mark. These include the www.internic.net website, which provides information on the gTLD registries, such as a listing of accredited registrars and FAQs on dispute resolution. .int RegistryICANN currently operates the registry for the .int TLD, which is for organizations established by international treaty. In cooperation with the IETF, ICANN is working to transition the infrastructure-related domains away from .int into more appropriate TLDs. AddresseesICANN is responsible for the global allocation of top-level blocks of IPv4 and IPv6 addresses and blocks of autonomous system (AS) numbers to the recognized regional Internet registries (RIRs), which in turn allocate smaller blocks to ISPs and other local Internet registries within a particular geographic area. Through its Address Supporting Organization, and in close cooperation with the regional Internet registries, ICANN is responsible for developing global address policies for IP address and AS number allocation. ProtocolsICANN creates, maintains, and disseminates over 120 registries of protocol port and parameter numbers and other protocol identifiers. Through a memorandum of understanding, ICANN has been designated by the Internet Engineering Task Force (IETF) to perform this set of IANA functions. [1] See ‘Toward A Statement of the ICANN Mission’, http://www.icann.org/ [2] http://www.icann.org/general/lynn-reform-proposal-24feb02.htm [3] ‘Toward A Statement of the ICANN Mission’, http://www.icann.org/
|