[council] DRAFT: Skeleton structure and split responsibilities
Skeleton structure and split responsibilities Draft for discussion 0.3 -- Alexander Svensson Note to readers: This document is a draft proposal and only represents the views of the author. It consists of two parts: The first part is a hopefully less controversial layered skeleton structure. Additionally, there is a proposal on splitting responsibilities into three recognizable parts which separate budgets. Be prepared to like the first and dislike the second part or vice versa. Please see http://www.icannchannel.de/skeleton03.pdf (135 kB) for a visualization of the proposal. A. A skeleton structure Currently, ICANN performs work related to - technical operations (e.g. changing TLD name servers in the DNS root zone file) - non-technical services (e.g. accrediting a new gTLD registrar) and - policy input and development (e.g. proposing, collecting input on and preparing a Redemption Grace Period for domain holders). However, there is little clear distinction between these areas except for the historical "IANA" label attached to changes in the DNS root zone file. This skeleton structure attempts to separate the layers and make them more transparent. 1. Technical operation Some of ICANN's tasks do not include policy development, but only policy implementation by technical operation. This has historically been labelled the "IANA function". Such tasks are mainly - (Operational) addition of new and change of existing ccTLD and gTLD entries in the DNS root zone file - (Operational) delegation of top-level IP address blocks and AS numbers to regional Internet registries - Operation of DNS root server L - Protocol port and parameter number and identifiers registry 2. Non-technical duties and services Some of ICANN's tasks are neither policy development nor technical operation. They reflect ICANN's role in the gTLD namespace and include - accreditation of gTLD registrars - monitoring and enforcement of gTLD registrar contracts - monitoring and enforcement of gTLD registry contracts - UDRP administration supervision - Internic information 3. Policy coordination/development Policy is not developed uniformly in all current ICANN areas: ICANN has devoted most of its resources to gTLD domain names while protocol parameter and port numbers have not been especially controversial discussion topics. ccTLD registries have expressed their concern about ICANN's lack of attention to ccTLD issues and positions. Although both protocol and IP address issues have not been controversial until now, IP addressing may become a more important and controversial issue, while ICANN's role regarding protocols is merely that of a clerk. It seems therefore sensible to have policy coordination/development mechanisms for four areas: - protocol parameter and port number related issues - (inter-regional) IP address allocation issues, - (inter-national) country code top level domain issues and - generic top level domain issues. This skeleton structure does not attempt to decide whether Policy Councils, Supporting Organizations or any other form of mechanism is best suited. However, there is a consensus among the DNSO Names Council (and in the view of the author also in the DNSO General Assembly and wider ICANN community), that policy is to be developed in a bottom-up process, not top-down. 4. Policy input For efficient and legitimate policy development, any policy development mechanism has to collect and use certain policy input. The three most important sources of input which have to be taken into account by the policy development mechanism are - governments (in areas where public policy issues are concerned) - the Internet community at large - technical expertise 5. Oversight Despite the bottom-up process, there is a need for oversight of staff, policy and budget. This oversight is provided by a Board (be it of directors or of trustees). An independent review mechanism which judges whether Board actions are in accordance with its Bylaws and Articles of Incorporation might prevent wrong decisions, litigation and unnecessary interventions. B. Structure-related budget elements All the layers mentioned above lead to certain costs: - Even though the directors/trustees do not receive a salary, there are travel and meetings costs. - Even though policy input comes voluntarily, collecting such input leads to costs (information, outreach and participation cannot entirely depend on compulsory fees and can thus only be partly self- funding). - Efficient policy development requires professional staff support for secretariat, web services, meeting organization and the like. - Technical operation and the non-technical duties and services are costly since they also depend on professional staff. C. Budget divisions (proposal) Not all ICANN tasks and services are relevant for everyone. Consequently, not everyone is willing to pay for everything. It would however be possible to divide the tasks and responsibilities into three recognizable parts: ICANN, IANA and InterNIC. All three of them would have separate staff and budgets (or rather separated budget items within the overall ICANN budget). 1. InterNIC InterNIC would be the entity responsible for gTLD contracts and enforcement. If e.g. a new company wants to become an accredited registrar, it contacts InterNIC staff. InterNIC does not make policy, but instead implements existing agreements. 2. IANA IANA would be the entity responsible for technical operation. If e.g. a change in the DNS root zone file is necessary, a ccTLD or gTLD registry manager contacts IANA and requests such a change. IANA does not make policy, but instead implements existing RFCs and, if applicable, ICANN consensus policies. 3. ICANN ICANN would be the forum where policy coordination and development takes place. ICANN staff supports the collection of policy input and the policy development through a bottom-up process. The policy coordination and development mechanism differ according to subject matter and organization: E.g. IP registries are already organized regionally and have their own processes in place -- for them, ICANN is mainly relevant for coordinating RIR and IANA policies. The ccTLDs also have regional organizations and are now in the process of founding their own organization within and outside ICANN. The situation is again completely different for gTLDs. Because of this, the policy coordination/development mechanisms need not and should not be identical throughout all four areas. D. Funding sources (proposal) Having three recognizable entities which are responsible for a part of ICANN's work does not only result in clearer responsibilities and budget, it also makes it possible to assign parts of the budget to specific contributors. 1. InterNIC An efficiently working InterNIC is in the interest of gTLD registries, registrars and registrants. However, InterNIC does not provide any services to ccTLD registries, RIRs or SDOs. Therefore, the InterNIC budget is financed entirely through the gTLD registry/registrar/registrant system. 2. IANA IANA provides specific technical services. It is financed by the IANA users: TLD registries (both ccTLD and gTLD), IP registries and standards development organizations. 3. ICANN Policy coordination and development necessarily leads to costs. However, the lack of policy coordination and development can equally lead to costs which may be significantly higher. A bottom-up policy development process requires information, outreach and professional support. These costs must be shared by all groups involved. |