Skip to main content

WEBINAR: Cross Community Working Group (CWG) On Naming Related Functions Public Consultation on Draft Transition Proposal

Following the request of the National Telecommunications and Information Administration (NTIA) for ICANN to "convene a multistakeholder process to develop a plan to transition the U.S. government stewardship role" with regard to the IANA Functions and related root zone management, a Cross Community Working Group (CWG) was tasked with developing a consolidated transition proposal for the elements of the IANA Functions relating to the Domain Name System (DNS). The CWG has now published its draft transition proposal for public comment. Comments can be submitted until 22 December at 23:59 UTC.

In order to brief the community on the contents on this draft transition proposal and encourage community feedback, the CWG will be organizing three identical webinars at different times to facilitate participation across time zones. The webinars will take place on:

  • 3 December from 7:00 – 8:30 UTC (time zone converter here)
  • 4 December from 12:30 – 14:00 UTC (time zone converter here)
  • 4 December from 16:00 – 17:30 UTC (time zone converter here)

Webinar Details & How to Attend

The webinars will be run in an Adobe Connect room. If you are interested in attending the webinar and would like to receive dial-in details, please send an email to grace.abuhamad@icann.org and indicate which day / time you would like to attend the webinar. Please note that the webinar will be conducted in English and will be recorded and transcribed. Subsequently the transcripts will be translated in the 5 UN languages and posted on the CWG Wiki here.


The Draft Transition Proposal

The CWG structured its draft transition proposal based on the IANA Stewardship Transition Coordination Group (ICG) Request for Proposals. These are:

1 Description of Community's Use of IANA Functions
2A Existing, Pre-Transition Arrangements – Policy Sources
2B Existing, Pre-Transition Arrangements – Oversight and Accountability
3 Proposed Post-Transition Oversight and Accountability Arrangements
4 Transition Implications
5 NTIA Requirements
6 Community Process

Sections 1, 2A and 2B describe the current situation.

Section 3, which is the heart of the transition proposal, is still a work in progress as not all details have been ironed out as of the publication of this consultation. Although lacking some details, the information provided in this section should be sufficiently detailed to allow the communities to comment on all key components. In summary, section 3 proposes the creation of 4 new entities to replace the current NTIA arrangements. These are:

  1. Contract Co. – This primary function of this entity (likely a non-profit corporation) is to be signatory to the contract with the IANA Functions Operator. This entity should be lightweight and have little or no staff.
  2. Multistakeholder Review Team (MRT) – The MRT would be a multi-stakeholder body with formally selected representatives from all of the relevant communities (exact composition TBD). The operation of the MRT would be based on the concept of maximum public transparency. The responsibilities of the MRT will include:
    • Developing the detailed contract terms for the agreement between Contract Co. and the IANA Functions Operator, based on the key contract terms proposed as part of this proposal and set forth as Annex 3
    • Making key decisions for Contract Co. (e.g., whether or not to enter into a rebidding (RFP) process for the operation of the IANA Naming Functions)
    • Conducting the IANA Functions Operator Budget Review
    • Addressing any escalation issues raised by the Customer Standing Committee (CSC) including the possibility of engaging in enforcement
    • Performing certain elements of administration (including periodic performance reviews) currently set forth in the IANA Functions Contract and currently being carried out by the NTIA
    • Managing a re-contracting or rebidding (RFP) process for the operation of the IANA Functions, both as an enforcement option and as part of a regular rebidding procedure
    The CWG is in the process of discussing whether there is an additional enforcement role for the MRT related to policy implementation by the IANA Functions Operator; specifically, whether the MRT should be able to commence a proceeding before the Independent Appeals Panel.
  3. Customer Standing Committee (CSC) – While the exact composition is still to be determined, the CSC would primarily be made up of a number of representatives of registry operators, including ccTLD and gTLD registries. Input from the CSC would feed into and inform the work of the MRT. It is possible that the CSC would also include additional individuals with relevant expertise and/or liaisons (or representatives) from other SO/ACs. The CSC would:
    • Work with the MRT to establish Service Levels and Performance Indicators for the performance of the IANA Naming Functions
    • Receive reports from the IANA Functions Operator including regular performance reports.
    • Review these reports against established service levels and escalate any significant issues to the MRT
  4. Independent Appeals Panel (IAP) – The CWG recommends that all IANA actions which affect the Root Zone or Root Zone WHOIS database be subject to an independent and binding appeals panel. The Appeals Mechanism should also cover any policy implementation actions that affect the execution of changes to the Root Zone File or Root Zone WHOIS and how relevant policies are applied. This need not be a permanent body, but rather could be handled the same way as commercial disputes are often resolved, through the use of a binding arbitration process using an independent arbitration organization (e.g., ICDR, ICC, AAA) or a standing list of qualified people under rules promulgated by such an organization.

Sections 4, 5 and 6 are currently in development and are directly dependent on the final choices that will be made for section 3.

For further details, you are encouraged the review the draft transition proposal in its entirety, available here.


Further information

For further information about the CWG's work, please see https://community.icann.org/x/37fhAg.

For further information about the ICG and the IANA Stewardship Transition, please see https://www.icann.org/stewardship.


More Announcements
Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."