[ga] 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
- 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
- (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
- Operation of DNS root server L
- Protocol port and parameter number and identifiers
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
- monitoring and enforcement of gTLD registry
- 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
- the Internet community at large
- technical expertise
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-
- 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
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
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.
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.
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.
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.
IANA provides specific technical services. It is financed by the
IANA users: TLD registries (both ccTLD and gTLD), IP registries
and standards development organizations.
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.
This message was passed to you via the firstname.lastname@example.org list.
Send mail to email@example.com to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html