Skip to main content

Registrar Constituency Statement on New gTLD Services

This registrar constituency statement relates to the GNSO Policy Development Process on a Procedure for use by ICANN in considering requests for consent and related contractual amendments to allow changes in the architecture or operation of a gTLD registry, in accordance with Section 7(d) (1) of the GNSO Policy Development Process.

(1) A vote on this statement was held on <insert date>, with the following result <insert results>.

(2) The registrar constituency carried out discussions on the topic via its public mailing list at: http://gnso.icann.org/mailing-lists/archives/registrars/ and via the following meetings or teleconferences:

(3) Analysis of how the registrars constituency is affected by the issue

Changes in the architecture or operation of a gTLD registry can affect members of the registrars constituency in the following ways:

  • a change may affect the commercial viability of many registrars with the result of an overall reduction in the level of competition and consumer choice
  • a change may affect a registrar's customers (which may be individuals, organisations, or intermediaries that provide domain name services), which often results in higher customer support costs, particularly in regard to sudden unexpected changes in operation
  • a change may require changes in a registrar's business processes, which typically requires additional software development work and thus additional expense. Additional software development work that does not either reduce a registrar's costs, or increase a registrar's revenue will ultimately result in higher prices for its customers.

As a separate issue, the registrars' constituency recommends that ICANN review its funding model, and consider how to levy its fees more broadly across different registry services rather than the present model which is based on the number of domains under management.

Addressing the terms of reference for the policy development process, the registrars' constituency notes the purpose of the policy development is to create a policy concerning the essential characteristics of the process by which ICANN considers registry operator or sponsor requests for consent or related contractual amendments to allow changes in the architecture or operation of a gtld registry.

The registrar constituency addresses each of the tasks of the PDP below.

(1) Develop guidelines for when approval is required to make a change based on the existing registry agreements.

It would assist the industry to have a simple set of guidelines for when it is necessary for a registry operator (particularly unsponsored) to seek approval from ICANN. The following is a simplified list of areas where approval is required based on the unsponsored registry agreement.

(a) Changes to reports provided to ICANN

(b) Changes to schedule, content, format and procedures for data escrow

(c) Changes to the specification for the publication of data or changes to query based access or bulk access concerning domain name and name server registrations (ie WHOIS service)

(d) Changes to the Registry-Registrar agreement

(e) Material changes and additions in the functional specifications for "Registry Services"

(f) Changes in the performance specifications for "Registry Services"

(g) Changes to the zone file access agreement

(h) Changes in the maximum price for "Registry Services"

(i) Changes in the Registry Operator's Code of Conduct

(j) Changes in the registration of domain names for a registry operator's own use

With regard to unsponsored gtlds, the registrars constituency notes that although portions of the policy-development authority for each sTLD are delegated to the designated sTLD sponsor, there are some situations in which an sTLD's sponsor will request amendments to, or approvals under, the sponsorship agreement it has with ICANN. Although approval and amendment requests are much more common in the case of unsponsored TLDs than for sTLDs, the overall goals (e.g., predictability, timeliness, transparency) of the procedures for handling gTLD and sTLD requests are similar, even though there are differences in the provisions of the underlying agreements that must be observed.

The areas of particular concern for registrars relate to changes in the Registry-Registrar agreement and changes in the performance, specification and prices of "Registry Services". The registrars constituency recommends that ICANN adopt a consistent definition of registry services to guide the industry in determining when ICANN approval is required. The registrars constituency favours the definition used in the .biz agreement ie

"Registry Services" means services provided as an integral part of the operation of the Registry TLD, including all subdomains in which Registered Names are registered.

In determining whether a service is integral to the operation of the Registry TLD, consideration will be given to the extent to which the Registry Operator has been materially advantaged in providing the service by its designation as such under this Agreement. (this consideration should be added to any registry agreements that do not currently have it.)

The development of technology, expertise, systems, efficient operations, reputation (including identification as Registry Operator), financial strength, or relationships with registrars and third parties shall not be deemed an advantage arising from the designation.

Registry Services include:

  • receipt of data concerning registration of domain names and nameservers from registrars,
  • provision to registrars of status information relating to the Registry TLD,
  • dissemination of TLD zone files,
  • operation of the Registry TLD zone servers,
  • dissemination of contact and other information concerning domain-name and nameserver registrations in the Registry TLD, and
  • such other services required by ICANN.

Registry Services shall not include the provision of nameservice for a domain used by a single entity under a Registered Name registered through an ICANN-Accredited Registrar.

(2) Develop a check list of issues to consider when approving a change

ICANN should refer to its mission and its core values taken from the ICANN bylaws in formulating the check list of issues to consider when approving a change.

Mission: to coordinate, at the overall level, the global Internet's systems of unique identifiers, and in particular to ensure the stable and secure operation of the Internet's unique identifier systems.

Three of the core values of particular relevance are:

Core value 1: Preserving and enhancing the operational stability, reliability, security, and global interoperability of the Internet.

Core value 5: Where feasible and appropriate, depending on market mechanisms to promote and sustain a competitive environment.

Core value 6: Introducing and promoting competition in the registration of domain names where practicable and beneficial in the public interest.

The challenge for ICANN is allowing registry operators to innovate and evolve their services while ensuring that the operational stability, reliability, security, interoperability of the Internet is preserved, and ensuring that there is a healthy competitive market in the provision of domain name registration services by registrars.

When approving a change ICANN must determine whether:

(a) The change requires ICANN approval. Where there is a change related to the functional, performance or prices of a service, ICANN will need to first determine if the service fits under the definition of "Registry Service".

(b) Whether to use a fast track or a more time-consuming approval process. In general changes that do not relate to the registry-registrar agreement or Registry Services could be subject to the fast track process.

(c) The change is likely to affect operational stability, reliability, security and global inter-operability of the Internet. The fact that an effect is likely should not be a bar to the new service; rather these factors and a registry's ability to minimize risks must be weighed in considering whether, and under what conditions, to approve a service. This should be fairly straight forward for most of the proposed changes, however a proposed change in the functional and performance specifications of a "Registry Service" should include impartial external advice from one or more technical experts. Where there is a possibility of an issue associated with operational stability, reliability, security and global inter-operability of the Internet, ICANN staff should use a more comprehensive approval process. The terms "operational stability", "reliability", "security" and "global interoperability" should be more clearly defined in the context of domain name registries, with examples of changes that could cause problems. The ICANN Security and Stability Advisory Committee could assist in providing clarification of these terms. The following is some suggestions for clarifying these terms:

a. Operational stability - The three main components of registry operation relate to the provisioning system whereby registrars provide instructions to the registry via the registry-registrar protocol to register and maintain domain name records, the DNS nameservice provided to Internet users via the DNS protocol, and the domain name holder information provided to Itnernt users via an interactive web page and the port 43 Whois protocol. Sudden changes to the behaviour of any of these systems can impact the stability of applications that make use of these systems. For example a change to the registry-registrar protocol could result in accidental deletion of domain name records, or incorrect configuration of nameserver information associated with a domain name record. A change in the behaviour of the DNS nameservice such as the introduction of wildcard behaviour, may result in failure of some applications that rely on that behaviour. The general approaches to maintaining operational stability are :

i. ensure that changes are backward compatible,

ii. ensure that the old and new environments are supported in parallel for a suitable period

iii. and ensure that sufficient notice period is provided.

The length of time for operating parallel environments or providing a notice period should be proportional to the significance of the change. A registry operator should also provide a test environment prior to putting a change into production to ensure that users can check that there software will continue to operate. This should apply to the provisioning environment, the DNS nameserver environment, and the WHOIS service.

b. Reliability - reliability typically relates to the availability of the registry operator systems, but it also related to the reliability of the applications that use the service. For example a change in the behaviour of the DNS nameservice may reduce the reliability of other important applications such as email that use the Internet.

c. Security - again security relates both to the security of the information maintained by the registry operator, as well as the security of applications that use the registry systems. For example, digital certificates may be used based on the information available in the WHOIS service. If this information is either no longer available, or is incorrect, then it can affect the security of applications that use the digital certificate.

d. Global Interoperability - where possible Internet user application should be able to work with any of the gtld registry systems. For example, all the gtld registries should aim to use the same core registry-registrar protocols, WHOIS and DNS protocols. A recent innovation that requires coordination is the introduction of internationalised domain names. The IETF has recently converged on a standard for encoding characters used in different languages into ASCII text (Punycode). Before giving permission to change a core protocol or data format, ICANN should seek to facilitate cooperation amongst registries and registrars to agree on a common protocol or data format.

(d) The change is likely to reduce the competition in the registration of domain names. This is often a controversial issue because often changes will affect the business models of one or more registrars, or their intermediaries. For example, a change in the way a registry operator allocates domain names that have been deleted will directly affect those registrars that rely on registrations of previously registered names as their main source of revenue. Where ICANN staff believe that a registrar business model could be affected by a change in the registry systems, ICANN should seek impartial advice from a competition expert with a strong understanding of the domain name industry structure. Where there is a possibility of an issue associated with the overall competition (as distinct from an individual competitor) in the domain name industry, ICANN staff should use a more comprehensive approval process. The issue should be considered from the point of view of the "long term" interests of end users. In general the long term interests are best serviced by a healthy competitive industry amongst domain name registrars because every registry is a natural monopoly in a particular TLD. A registry has a substantial degree of market power for registrants within that tld, as the switching costs for a registrant are often high to move to another tld. Therefore, vigorous competition among registrars is the only way that the market can be certain of providing the best prices and services. Registrars need to be able to differentiate their product offerings and add value, otherwise the value of a domain name will mostly reside with the registry operator and there will be little incentive to operate as a registrar. This will result in a return to a single provider for a particular domain name space. Where a new "Registry Service" is proposed, ICANN should consider whether the same service can be effectively provided by registrars or their intermediaries. For example, if a registry operator chose to limit the nameservers available to be associated with a domain name to only nameservers operated by the registry operator this would constrain competition. Another example could be the provision of an email service that was only available from the registry operator (e.g name@gtldname). Where possible registrars should have access to unbundled service offerings.

If registrars cannot provide the service effectively, ICANN staff should not deny the registry operator the right to launch the service, although they may place certain conditions on the service in order to safeguard competitive offerings by the registrar sector.

If registrars can effectively provide the service, ICANN staff should not allow the registry operator to provide the service as a bundled product, at a price point that takes advantage of the registry operator's monopoly position, or in a manner that claims a better offer by the registry operator by virtue of being the registry operator.

(3) Develop a process and timeline for responding to a request including "quick-check" phase, and more comprehensive phase.

The essential characteristics of a process to consider registry operator or sponsor requests for consent or related contractual amendments to allow changes in the architecture or operation of a gTLD registry are the following:

(a) Confirm that the change needs ICANN approval. This should include legal and/or technical advice in the case of determining with a service is a "Registry Service"

(b) Determine whether the change is likely to likely to affect operational stability, reliability, security and global inter-operability of the Internet, or competition in the registration of domain names. This should include impartial technical expert advice or competition expert advice. If there is no possibility of any issue, then proceed to approve within 14 days. If there is clearly a problem than deny approval within 14 days. This is the fast track process.

(c) If there is uncertainty about the impact of the change on operational stability, reliability, security and global inter-operability of the Internet, or competition in the registration of domains names, notify the applicant within 14 days that a more extensive public process will be used and allow the option for the applicant to withdraw the request.

(d) The more comprehensive process should consist of a 30 day consultation period consisting of

a. collecting public comments facilitated by the ICANN Manager of Public Participation

b. facilitating briefings for major affected stakeholders (e.g registrars when a change is proposed to provisioning system, or ISPs if a change is proposed to the DNS nameservice)

c. collecting constituency statements from each GNSO constituency

d. collecting statements from the ALAC, GAC, SECSAC as appropriate

(e) At the end of the 30 day consultation period, ICANN staff would have 14 days to prepare a report and provide a decision to the applicant. In cases where the change is rejected, the ICANN report should provide guidance on what alterations to the proposal could be made to allow ICANN to approve the change. For example ICANN staff may recommend safeguards to preserve competition in the registration of domain names, or safeguards such as longer notice periods to preserve the operational stability of the Internet.

(4) Develop a process and timeline for an appeals procedure for use by registry operators

Access to the appeals procedure should be available to all members of the ICANN community rather than just registry operators. There is an existing procedure for reconsideration under section 2 of Article IV of the ICANN bylaws which is open to any person or entity that is materially affected by an action by ICANN. The timeline for the procedure in the ICANN bylaws is:

(a) A request for reconsideration must be submitted within 30 days of the decisions

(b) The reconsideration committee has 30 days to announce whether it will proceed to consider the request

(c) The reconsideration committee has a total of 90 days to make a final recommendation.