DNSO Mailling lists archives


<<< Chronological Index >>>    <<< Thread Index >>>

[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
   -  (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

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-
    -  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
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.
    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.

    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.

<<< Chronological Index >>>    <<< Thread Index >>>