June 04, 2002
Note:
This page is still under construction - its
contents are likely to change over the next few weeks.
It is time to rebuild ICANN. This document presents a plan for that rebuilding.
The plan begins by adopting two proven rules of successful design:
The first of these rules comes from Louis Sullivan, one of the great architects of the 19th century. Sullivan articulated the principle that "form follows function."
The second of these rules comes from Niklaus Wirth. Wirth brought to the art of computer programming the concept of information hiding and modularity. To be a well designed program each module must cleanly encapsulate its mechanisms and its data; and the relationships and interactions between modules must be precisely identified. In addition, the whole modular structure must be structured to minimize the information and control flows between modules.
This document begins by looking at the functions we desire of the new ICANN. From that starting point a modular structure is articulated that is a capable and appropriate framework for the performance of those functions.
ICANN's duties as expressed in its Articles of Incorporation are to:
Coordinate the assignment of Internet technical parameters as needed to maintain universal connectivity on the Internet.
Perform and overseeing functions related to the coordination of the Internet Protocol address space.
Overseeing the operation of a DNS root server system.
Perform and oversee functions related to the coordination of the domain name system, including the development of policies for determining the circumstances under which new top-level domains are added to the ICANN operated DNS root system.
These duties contain a mix administrative and policymaking tasks. The administrative tasks involve only limited exercises of discretion. The tasks that create policies have significant amounts of discretionary freedom; contentious debates are to be anticipated.
We can see that ICANN's duties deal with three subjects:
"Technical parameters"
IP address space
domain name matters.
So let us enumerate ICANN's administrative and policymaking duties while being mindful of these three subjects.
Administrative duties are tasks that are patterned and are constrained by defined procedures. The exercise of discretion by the administrator is limited.
Properly executed administrative tasks are predictable - an external observer ought to be able to make reasonably accurate predictions about how any administrative matter will be handled.
To maintain the zone file that defines the contents of the root. For the most part this involves maintenance of the NS records that indicate which DNS servers handle a particular top level domain (TLD) according to instructions from the entity or person who has the authority over that TLD.
To periodically publish that zone file to the operators of the actual root servers as well as to the public.
To ensure that the root servers are operated, either via the DNS Root Administrator itself or via an operations contract, so as to meet specified technical standards, perform according to specified service levels, and to meet certain obligations regarding security and physical infrastructure
To validate that the root server system is operating well.
To process requests to change the entity or person who has authority over a TLD according to procedures specified by the ccTLD Organization or the gTLD Organization, as appropriate.
There are certain parts of these duties that may be considered as having policy components. For example, the choice of rules to be imposed upon root server operators does involve an element of public policy. However, it is considered that the debates over these could be satisfied by something less than direct public participation.
To act as the top level authority for delegation of IPv4 and IPv6 address blocks. These delegations will be made mainly to regional address registries (RIRs) such as today's APNIC, ARIN, and RIPE. As has historically occurred, it is expected that there will be occasional delegations outside of the RIR system.
To maintain the top level of the in-addr.arpa (and it's IPv6 equivalent) DNS hierarchy used for address-to-name mapping. (This task may be delegated to one of the RIRs if it is convenient to do so.)
To record the assignment of protocol numbers and other such values as specified by IETF issued documents. This job will require coordination with the IETF to properly perform according to the "IANA Considerations" of those RFCs that contain them and to handle those situations in which RFC guidance is absent.
Policy duties are tasks that involve the interplay of competing interests; the process is not tightly channeled and the outcome may be somewhat unpredictable.
Policy formulation is valid only when all potentially affected parties have the ability to participate in the debate and policy decision as peers with other parties. And the public has a strong interest that policy formulation is fair, open, and transparent.
To define what terms and conditions a ccTLD may be established, removed, of transferred to a new operator.
To define and apply the rules to establish, remove, or transfer gTLDs.
To define the rules to establish, remove, or transfer infrastructure TLDs (such as .arpa or .int.)
To define rules pertaining to the registration of domain names within gTLDs.
It is the belief of the author of this note that DNS policy ought not to include things that are more properly within the sphere of established legislative and judicial bodies. For that reason this note does not include matters such as the UDRP and the application of the UDRP among the DNS Policy Duties. There are many who have the contrary opinion. It must be noted that the general shape of this plan is unchanged if the UDRP is included among the DNS policy duties.
To define overall policies for IP address allocations and apply those policies to guide the allocation of address blocks to RIRs and other entities.
There are no policy duties regarding "technical parameters".
Based on the functions discussed above, it is proposed that ICANN's functions ought to be embodied into three administrative modules (that have limited discretion), and into three policy modules (that encapsulate highly discretionary, and often highly contentious, policy making.)
The administrative modules are:
DNS Root Administrator
IP Address Administrator
Protocol Parameter Administrator
The three policy making modules are:
ccTLD Policy Organization
gTLD Policy Organization
IP Address Policy Organization
The administrative modules are each focused around a single job. Each administrative job is expected to be one that will be unlikely to generate a great deal of demand for intense public participation. Consequently the limited discretion of these administrative modules is to be exercised through a notice-and-comment mechanism similar to that practiced by many administrative agencies in governments. This proposal leaves open the question of what kinds of external oversight and review mechanisms should be available to handle those (hopefully) extraordinary situations in which the exercise of discretion is arbitrary or capricious, or in which the discretion is exercised without adherence to proper procedures.
The larger policies that guide the administrative processes are established by the various policy organizations. Thus, for example, the DNS Root Administrator would use policies defined by the ccTLD Policy Organization to guide it through the process of transferring a ccTLD. And the gTLD Policy Organization would instruct the DNS Root Administrator as to the gTLDs that should be added.
As a general rule, an administrative module ought to derive its operational funding from those who use the administrative services and from the policy modules that interact with that particular administrative module. Thus the IP Address Administrator should obtain its funding from the RIRs and the IP Address Policy Organization.
Administrative modules will operate according to a Notice and Comment process.
Notice of proposed actions will be announced and posted on the world wide web in sufficient detail and with sufficient time that interested parties may respond with comments.
The administrator of the module must evaluate the comments before making a final decision and must demonstrate that such comments have been reviewed and considered.
The DNS Root Administrator oversees the operation of a DNS root and performs the DNS Administrative Duties defined previously.
The DNS Root Administrator will be responsible for the establishment of operational policies regarding the operation of the root servers. These policies will be established through a notice and comment process
The ccTLD Policy Organization will promulgate appropriate procedures, perhaps derived from those in RFC1591, for the DNS Root Administrator with respect to ccTLDs. It is anticipated that the policies regarding the recognition of new ccTLDs and the redelegation of existing ccTLDs will be the most complex and, at least initially, may require a close working relationship between the ccTLD Policy Organization and the DNS Root Administrator.
The gTLD Policy Organization will promulgate procedures for the DNS Root Administrator with respect to gTLDs. The gTLD Policy Organization will issue directives to the Root Administrator to create or remove gTLDs.
(Although it is possible to make the creation of new gTLDs a rather mechanical function, this issue has become one filled with emotion and is quite contentious. Consequently, this plan places the responsibility for decisions regarding gTLD creation into the gTLD Policy Organization, which will issue directives to the DNS Root Administrator so that the latter may make those directives manifest in the root zone.)
It is expected that the DNS Root Administrator will operate the DNS root servers initially via the loose federation of entities and individuals listed via http://root-servers.org/. However, over time the DNS Root Administrator may chose to take a more direct role and operate some or all of its root servers itself. Cost estimates for this are being prepared as part of a separate study to be published at a later date.
The DNS Root Administrator function will require staff and computing resources. Several of its jobs - such as monitoring the performance and availability of DNS root servers - may be contracted out. Preparation of the root zone file, while not a complex task and not one involving large amounts of data, is one that does require care and a large amount of double and cross checking to protect against human, procedural, or technical errors.
The IP Address Administrator's job is mainly to follow the procedures set forth by the IP Address Policy Organization.
It is expected that the staffing requirements will be minimal and essentially clerical. It is assumed that the job of maintaining the IP-to-name reverse lookup hierarchy will be delegated to the RIRs.
Because of its close ties to the IETF, this module may be more properly considered a part of the IETF rather than of the reformed ICANN.
The Policy Organizations are the containers for policymaking.
Each Policy Organization is expected to be self-funded. However, provision must be made to ensure that the public and public interest advocates are not precluded or hobbled by funding impositions.
This proposal does not delve deeply into the inner structures of the Policy Organizations.
The ccTLD PO focuses on the needs and issues of concern to those who provide and use ccTLDs.
The output of this organization are directives to the DNS Root Administrator regarding ccTLDs.
Such directives will generally be policy statements that instruct the DNS Root Administrator how to deal with requests for updates of ccTLD registration data - such as contact information and NS records.
This Policy Organization will be responsible for the creation of policies to decide when new ccTLDs should be created, old ones removed, and how transfers of control of ccTLDs should be accomplished.
The gTLD PO focuses on the needs and issues of concern to those who provide and use gTLDs.
The output of this organization are directives to the DNS Root Administrator regarding gTLDs.
This Policy Organization will be responsible for the creation of policies to decide when and how new gTLDs should be created, when gTLDs should be removed, how control is transferred, and the like.
There will be great pressure for this Policy Organization to engage in policy making about things that go beyond how the ICANN DNS root and its contents should be managed: We are likely to see pressures to create trademark related policies and registry/registrar business operation policies.
It is recommended here that the gTLD Policy Organization have explicit limitations in its organic documents to constrain the degree to which it may engage in what amounts to Internet lawmaking. And policies regarding business practices should be similarly constrained except for those needed to ensure that any failed DNS registrar or registry maintains enough recoverable assets and information so that a successor may pick up the pieces and resume services to the customers of the failed entity.
The IP Address Policy Organization focues on the needs and issues of concern to those who provide IP packet routing services and those who use IP addresses.
This Policy Organization will be responsible for the creation of Policies to decide how and under what conditions address blocks of IP addresses should be assigned and sub-delegated.
The output of this organization will be directives to the IP Address Administrator.
Each module is to be entirely distinct and separate from the other modules. Each module is to be embedded in a distinct legal structure separate from that encompassing any other module. There shall be no shared trustees, directors, managers, employees, or funding.
All communications between modules shall be in writing and be posted for public viewing on the Internet at or before the time the communication is made.
The job of the administrative modules is anticipated to such that the need for public involvement will be satisfied by a simple notice-and-comment process in which the comments are actually reviewed and considered without prejudice.
The policy organizations on the other hand, do require fully formed organs for public participation - not observation but full participation with at least a parity role with respect to other participants.
This public participation must be reasonably direct and not filtered through layers of intermediary representative structures. <<**more to be written**>>
<<**to be written**>>
DNS whois - is there a central focal point for "whois" queries? Is that the job of the DNS Root Administrator?
IP address whois - same question, where is the central locus from which inquiries may start. Is this the job of the IP Address Administrator?
What happens to RFC editor function - should that go to the Protocol Parameter Administrator or be tossed into the lap of the IETF?