The narrow technical mission of the White Paper achieved rough consensus in the Internet community. Such a mission would not need the overhead that is currently being consumed. To be specific, the narrow technical mission as envisioned in the White Paper would not necessitate nearly the structure of the current ICANN, and definitely would not necessitate the even larger structure that has been proposed by ICANN's president. The mission itself must be de-structured back to its original scope.
Access to the Internet is quickly becoming the touchstone for success in the business world, the political world, and the world of individuals. In order to properly balance the public and the private interests in the Internet, the following changes and procedures are recommended:
The first and most important change in the structure of ICANN must come by carefully defining its mission. For this, we look back at the mandate of the White Paper, which achieved rough consensus from the Internet community. Four major points were enumerated as the mission for that "newco" would provide:
- set policy for and direct allocation of IP number blocks to regional Internet number registries;
- oversee operation of the authoritative Internet root server system;
- oversee policy for determining the circumstances under which new TLDs are added to the root system; and
- coordinate the assignment of other Internet technical parameters as needed to maintain universal connectivity on the Internet.
This mission can more clearly be defined into three specific duties:
- Technical parameters
- IP Address Space
- Domain Name Matters
These three duties can easily be performed by three separate entities, each responsible for a subset of the narrowly defined mission as prescribed by the White Paper. The advantage to separate entities is that "capture" becomes less of an issue. With the proper series of bylaws and procedures for each entity, inclusiveness, transparency, accountability, and bottom-up procedures can be ensured.
IP Numbering Authority – IPNA
The duties of the IPNA would include the following administrative and policy functions:
- 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 define overall policies for IP address allocations and apply those policies to guide the allocation of address blocks to RIRs and other entities.
Technical Parameters Authority – TPA
The duties of the TPA would include the following functions:
Domain Naming Authority – DNA
- 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.
The duties of the DNA would include the following administrative and policy functions:
- 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.
- To define what terms and conditions a ccTLD may be established or transferred to a new operator.
- To define and apply the rules to establish or transfer gTLDs.
- To define the rules to establish or transfer infrastructure TLDs (such as .arpa or .int.)
- To define rules pertaining to the registration of domain names within gTLDs
While the three entities charged with fulfilling the White Paper's mandates are to be legally separate and distinct, with no shared employees, trustees, directors, management or funds, each module must employ similar structures for ensuring bottom-up management, accountability and inclusive participation. Those structures must include:
- Notice and comment periods. 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 specific entity must evaluate the comments before making a final decision and must demonstrate that such comments have been reviewed and considered.
- Public meetings. The public must be allowed access to the vast majority of meetings of the boards of any of these three entities. Minutes of meetings will be made available on the web in an expedited manner.
- Members may vote to remove board members of any of the three entities.
- Governments, as such, will not be permitted direct participation in any of the three entities.
- Appeal process. An appeals process for interested parties should be created, for those cases where it is found that normal mechanisms are unsatisfactory, similar to the function of an Ombudsman, who has a free hand to act independently from any entity's board or staff.
- Bylaws changes must require a supermajority of the board.
- No current non-elected board members, officers, staff or trustees of the current ICANN will be allowed positions in any of the three entities for a period of five years.
- Strict conflict of interest procedures must be implemented and adhered to.
Specifics of the IP Numbering Authority
The IP Address Policy Organization focuses 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 an IP Address Administrator who will directly implement decided policies.
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.
Specifics of the Technical Parameters Authority
This particular group would act as liaison to groups such as the IAB and IETF regarding technical implementation necessary to smooth operation of the Internet, simply administering the registries of parameter and protocol values according to the guidance given by those technical bodies.
Specifics of the Domain Name Authority
For better or worse, this will be the most complicated of the entities to structure, due to the inherent policy matters that are integral to decisions regarding top level domains, country code top level domains, intellectual property interests, etc. While the following structure may at first seem large, it is much less so than the current mechanisms within ICANN.
Within the Domain Name Authority, there will be a more pronounced division between policy and implementation, with separate funding for each. We will look at policy and implementation modules separately.
Domain Name Policy
Within the domain naming policy module, it seems necessary to have separation between the gTLDs and the ccTLDs given history, differences in usage, difference in authorities, points of contention, etc.
The ccTLD policy organization focuses on the needs and issues of concern to those who provide and use ccTLDs. The output of this organization are directives to an elected 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 policy organization focuses on the needs and issues of concern to those who provide and use gTLDs. The outputs of this organization are directives to an elected 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, how control is transferred, and the like.
There will be great pressure for this policy 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.
To avoid many of the pitfalls that spelled failure for the original ICANN, 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.
Administration of DNS Policies
The DNS Root Administrator oversees the operation of a DNS as previously listed. 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. It is anticipated that the policies regarding the recognition of new ccTLDs and the re-delegation 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.
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.
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. As with each module of each authority segment, technical requirements must be in balance with fiscal responsibility.
Domain Name Rights Coalition
Email: admin at netpolicy dot com.