Skip to main content

A revamp of ICANN’s public comment process

comment forum grab

A vital part of ICANN’s processes is the opportunity for there to be public comment on each substantial piece of work before it is put forward for final approval.

However, the organisation has been criticised in the past for not flagging these public comment periods clearly enough, and it is fair to say that in many ways, the intended use of public comment forums has fallen into decline over time. It is not uncommon for there to be extremely few comments made in each forum, and for many of those comments to be unusable. To make matters worse, the useful comments that are supplied are given insufficient weight in ICANN’s processes, removing much of the value in writing a comment in the first place.

ICANN plans to break this vicious circle and has taken several steps to encourage wider and greater use of the public comment within the organisation’s processes. This post will outline what they are and what future changes are in store.

Ch.. ch.. ch.. changes

First, as a part of ICANN’s draft Management Operating Principles, the organisation has produced a Consultation Framework that outlines how it will approach consultation with the community.

Within that framework is an effort to: post a summary of comments at the end of each comment period and in the same place as the comments; post an analysis of the comments; and request explicit reference and discussion of that summary by the relevant body while discussing the topic under consideration. It is hoped that these three (together with the others) will demonstrate to the wider community the clear value in posting comments during a public comment period.

But where’s the info?

However, those changes in themselves will not make sufficient difference if people are unable to easily find out and review exactly what it is that ICANN has put out for public comment in the first place. All comment periods are official announced by ICANN on its main site (and you can sign up to an automated email service for ICANN announcements), and those announcements are then often pasted onto the many mailing lists that the community is signed up to. Nonetheless, it remains difficult for people to simply and easily find what it is that is currently up for discussion, and so we have produced a single webpage that will provide the community with that breakdown.

It will be up shortly, but the first iteration of that page is posted below in order to provide you all with an opportunity to review the approach taken and suggest what improvements could be made. Please feel free to use this blog’s comment function as a way of supplying your suggestions and ideas.

And the next step…

For your information: the next step in the making the public comment period more useful will be an effort to automate the process somewhat, thereby allowing individuals to receive personalised emails that cover the comment periods they are likely to be interested in (and important events within that comment period). This approach will take some serious development however and so in the meantime we would encourage everyone to increase their use of the comment period in order to make this development more worthwhile and hence a greater priority.

Do please note that the page below will not be updated and so will rapidly become out of date. The continually updated comment page can be found at and it is that page you should refer to if you are hoping to comment on a particular issue.

Public comment webpage

This page provides a full rundown of what ICANN is currently seeking comment on, along with the dates of that comment period and a brief summary of what the topic in question is. An archive of recently closed public fora is provided under that; and finally a full list of comment fora.

Open for comment now: Recently closed comment forums: Archived forums:
North American RALO formation (ends: 01 Aug 07) | .Name registry renewal agreement (ends: 29 Jul 07) | Draft Management Operating Principles (ends: 31 Aug 07) ICANN geographical regions report | Neustar new registry service | ICANN’s performance Click here for a full list of comment forums.

Open for comment now

North American RALO formation
Open: 11 Jul 07
Closed: 01 Aug 07

Explanation: The North American region of At-Large has reached a consensus on the contents of a Memorandum of Understanding (“MOU”) between the region and ICANN. This was duly signed by the representatives of the North American region and ICANN at the San Juan ICANN Meeting on 28th June 2007, contingent upon final approval following the completion of a public comment period. Those wishing to comment are suggested to make their comments not later than 1 August 2007 at 23:59 UTC.The NARALO MOU can be downloaded in English here [pdf]. Announcement | Comments | Add comment | Summary/analysis of comments

.Name registry renewal agreement
Open: 29 Jun 07
Closed: 29 Jul 07

Explanation: The proposed .Name renewal agreement is fundamentally the same as what was negotiated and approved for .Biz, also an unsponsored/restricted gTLD, in 2006. A marked version contrasting the approved .Biz agreement to the proposed .Name renewal agreement can be viewed here [pdf].There are elements of the proposed renewal agreement that vary from the current .Name agreement. This table [pdf], summarizes all the differences between the 2001 and proposed 2007 agreement. The substantive changes include:

  • .Name currently pays an annual fixed fee that has been subject to a maximum 10% annual increase since its inception. The proposed renewal agreement contains the same registry-level transaction fee schedule as the recently approved gTLD agreements.
  • .Name makes a distinction between traditional second and third-level registrations vs. bulk third-level registrations. Bulk is defined as sales of 50,000 names or more under .Name’s consumer mass-market approach to third-level registrations. .Name has said their mass-market approach to third-level registrations is needed for the consumer market to prosper and grow.
  • Bulk third-level registrations have a fee, as of the effective date of the agreement, roughly equivalent to 5% of revenue with: no minimum fee vs. second-level and traditional third-level registrations that have a fee minimum of $0.15US per registration: and a fee cap of $0.15US vs. other recently approved registry agreements that have a fee cap of $0.25US.

This fee structure is intended to facilitate the sale of third-level names via a special program, a form of innovation, intended to provide new consumer choices.

The proposed .Name renewal registry agreement can be viewed here [pdf], with its appendices downloadable here [pdf]. Announcement | Comments | Add comment | Summary/analysis of comments

Draft Management Operating Principles
Open: 23 Jun 07
Closed: 31 Aug 07

Explanation: As part of its commitment to continuously improving transparency and accountability, ICANN commenced a process of consultation with the community on the development of a set of Management Operating Principles.ICANN has a range of existing external legal and internal rule based accountabilities. Those accountabilities have never been outlined concisely and in collected form. For example, there has been no clear set of information disclosure principles, no clear participation framework, no clear translation framework and no organisational code of conduct. The draft principles and frameworks for accountability released on 23 June 2007 strive to achieve that purpose. They are presented in draft form for discussion and development with the community.

You can read them here, or as a pdf file here.

In considering these draft documents ICANN would like feedback on the following:

  • This is the first time that ICANN’s existing accountabilities have been collected in one place. Is this helpful?
  • Was there anything presented that was unexpected or unknown?
  • What more can be done to strengthen ICANN’s accountability?
  • What more could be done to improve upon the existing processes for the Strategic and Operating plans and the budget?
  • What more needs to be done to improve upon the draft translation framework?
  • What more could be done to improve participation and the draft framework?
  • Is the draft information disclosure policy suitable for ICANN’s needs?
  • Is the draft code of conduct suitable for ICANN’s needs?
  • Are the mechanisms for dispute resolution suitable for ICANN’s needs?

In answering the above, providing clear evidence to support assertions as well as identifying any organizations that have mechanisms beyond those that ICANN relies upon, will greatly assist in understanding what improvements can be made. Announcement | Comments | Add comment | Summary/analysis of comments

Recently closed comment forums

ICANN geographical regions report
Open: 22 Jun 07
Closed: 09 Jul 07

Explanation: The ICANN Geographic Regions form the basis of the regional structure of the ALAC and ccNSO, and are used to ensure the geographic diversity of the ICANN Board, ccNSO and GNSO Council.A ccNSO Working Group has been reviewing ICANN’s geographical regions and produced a report. It would appreciate input from ccTLD managers and other stakeholders, including the GAC, on the report generally and on the following questions in particular:

  1. Do the concerns as described in Section B of the report adequately represent the concerns? If not, please indicate what needs to change.
  2. Do you support the recommendations (Section D) of the Working Group?

At the ccNSO Lisbon meeting, the Working Group presented a progress report. Based on the feedback received, the draft report and its recommendations were further amended. Input would be appreciated on the following questions :

  1. Do the concerns as described in Section B of the report adequately represent the concerns? If not, please indicate what needs to change.
  2. Do you support the recommendations (Section D) of the Working Group?

You can read the full report here [pdf]. Announcement | Comments | Add comment | Summary/analysis of comments

Neustar new registry service
Open: 08 Jun 07
Closed: 29 Jun 07

Explanation: There is a proposed amendment to implement a new registry service by NeuStar. The service will offer Bulk Transfer After Partial Portfolio Acquisition (BTAPPA) to consenting registrars where one ICANN-accredited registrar purchases a portion but not all, of another ICANN-accredited registrar’s domain name portfolio in the .Biz top-level domain. NeuStar requested approval of the registry service at the request of two registrars.ICANN’s Board of Directors by a 11-0 vote approved Resolution 06.85 to implement the service. The resolution authorized the President and General Counsel to enter into an amendment of the .BIZ Registry Agreement with NeuLevel (now named NeuStar). ICANN and NeuStar have negotiated an amendment to implement the approved service. Under NeuStar’s Terms of Service for BTAPPA [pdf], protections for registrants may include:

  • The Gaining and Losing Registrars must have ICANN accreditation for .Biz at the time the Transfer Request is submitted.
  • The Gaining and Losing Registrars must each have a Registrar Agreement in effect with NeuStar and must be in good standing.
  • The losing registrar shall provide to all domain name registrants involved in the bulk transfer 15 days advance written notice of the bulk change of sponsorship.

The amendment provides for a new Section 7 in Appendix 7 of the .Biz Registry Agreement. The process for considering new registry services can be seen here. Absent significant objections, ICANN will enter into this amendment following the public comment period. All documentation regarding this approved service and corresponding comment fora is available here. Announcement | Comments | Add comment | Summary/analysis of comments

ICANN’s performance
Open: 08 May 07
Closed: 05 Jun 07

Explanation: As part of an ongoing interest in continuous improvement, ICANN is seeking community feedback about its performance.All responses are welcome. Targeted comments regarding several areas of performance, which have been drawn from the ICANN Strategic Plan, are of particular interest:

  • Is ICANN becoming more transparent, accessible and accountable? What improvements have been observed and what still needs to be done?
  • Has ICANN improved its operational performance? What improvements have been observed and what still needs to be done?
  • Has ICANN improved its performance in the development of Policy? What improvements have been observed and what still needs to be done?
  • Has ICANN increased international participation? What improvements have been observed and what still needs to be done?
  • Have there been improvements in participation and in efficiency of the ICANN multi-stakeholder model? What more needs to be done?
  • What plans and actions have been observed that position ICANN for more comprehensive transition of the technical coordination of the Internet’s system of unique identifiers. What more needs to be done?
  • What improvements have been made in dispute resolution and the application of fairness and equity in the management of complaints and other mechanisms of review that are available? These include the work of the reconsideration committee, the Ombudsman and independent review.

Discussion of this issue is also being encouraged on the ICANN blog, and ICANN’s public participation site. Announcement | Comments | Add comment | Summary/analysis of comments

Archived forums

For a full list of comment forums, please visit this webpage.


    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"""" is not an IDN."