[ga] DRAFT: Skeleton structure and split responsibilities

[Alexander Svensson <alexander@svensson.de>]

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.

--
This message was passed to you via the ga@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html