Final Report

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

Contents

1. Background

2. Public Comments 

    2.1 Public comments on terms of reference, December 2003

     2.2 Public comments on Initial Report, June 2005

3. Summary of Constituency Statements

   3.1. Overview of statements

   3.2. More detailed review of constituency statements

      3.2.1. Fast Track or Quick Look Process

      3.2.2. Detailed Review Process

      3.2.3. Roles of Various Participants

      3.2.4. Appeals Process 11

      3.2.5. Assessment of Process Cost

4. ICANN staff input

5. Recommendations

   5.1. Approval Process

   5.2. Appendix (Reconsideration process in ICANN bylaws)

   5.3. Appendix (Independent Review Process from ICANN Bylaws)

6. Analysis of impact of the recommended policy on each constituency

7. Appendix A (Constituency Statements)

   7.2. A1: Non-commercial users constituency statement

   7.3. A2: Commercial and business users constituency

   7.4. A3: Intellectual Property Constituency

   7.5. A4: Internet Service Provider and Connectivity Providers Constituency

   7.7. A5: Registrars Constituency

   7.8. A6: Gtld registries constituency

8. Appendix B (At Large Advisory Committee statement)

The Issues Report (updated 2 Dec 2004) may be found at:

http://www.icann.org/gnso/issue-reports/registry-svcs-report-19nov03.htm

On the basis of the issues report the GNSO Council initiated the policy development process on 2 Dec 2004, and decided to manage the process as a Committee of the whole GNSO Council. The terms of reference for the policy are detailed at:

http://gnso.icann.org/issues/registry-services/tor-revised.html

ICANN has agreements with registry operators (for unsponsored gTLDs) and sponsors (for sponsored gTLDs). In the agreements, ICANN designates the operator (or sponsor) as the sole operator (or sponsoring organization) for the TLD. In exchange, the operator or sponsor agrees that the gTLD registry will be operated according to various specifications, policies, and other requirements. These agreements constrain the freedom of a gTLD registry or sponsor to make changes in the architecture or operation of the registry that would not conform with those agreements, absent ICANN's prior consent. Under these agreements, ICANN has agreed that it will not unreasonably withhold or delay this consent.

Some examples of where operators and sponsors must obtain ICANN's consent include changes to the maximum fees for registry services, changes to the list of domain names registered to the registry operator, and certain changes to the functional or performance specifications included in a registry agreement.

Where ICANN is required to give consent to a change, registry agreements require ICANN to make decisions using a timely, transparent and predictable process. Under the unsponsored registry agreements, (e.g., .com, .net, .org, .biz, .info, .name), ICANN is also required to not unreasonably restrain competition and, to the extent feasible, promote and encourage robust competition; and not apply standards, policies, procedures or practices arbitrarily, unjustifiably, or inequitably and not single out a Registry Operator for disparate treatment unless justified by substantial and reasonable cause.

With respect to sponsored gTLD (sTLD) registry agreements (e.g., .aero, .coop, and .museum), 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 purpose of this policy development process 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.

2.1 Public comments on terms of reference, December 2003

After the initiation of the policy development process, the terms of reference were published and public comments were sought on the issue in December 2003.

The public comments are archived at:

http://www.gnso.icann.org/mailing-lists/archives/tor-reg/

Jonathan Weinberg, Professor of Law, Wayne State University, draw the Council's attention to a paper on Sitefinder and Internet Governance (available at: http://www.law.wayne.edu/weinberg/sitefinder.new.PDF), and stated:

"The lesson of Site Finder is that there needs to be an effective institutional mechanism for protecting the domain name space infrastructure from unilateral change that bypasses the protections and consensus mechanisms of the traditional Internet standards process. The existing domain-name architecture and standards process are subject to substantial pressure from an aggressively for-profit VeriSign. Even a flawed ICANN may be better suited than any other existing institution to protect against that danger. Yet we should endorse ICANN regulatory authority only with extreme caution, and the same mechanisms should not apply to everyone. ICANN oversight should certainly not apply beyond the for-profit unsponsored registries. Even within this group, it may be that the rules should be different for "dominant" and "non-dominant" players -- perhaps, for VeriSign and all others. "

Marilyn Cade, on behalf of AT&T stated that:

"AT&T supports the need to have a standard set of procedures to guide how requests from registry operators are handled by ICANN since their actions are undertaken within a sole source environment. AT&T is aware that there have been contributions that question why anyone other than registries and ICANN should have input into a process or defined procedures related to the introduction of new registry services. As users of the Internet, and as a company that supports over 4 million enterprise users, and over 40 million consumers, all of whom are increasingly reliant upon the Internet's stable, predictable, and reliable operation, we note that certain constituencies cannot claim special positions related to the impact of registry services; indeed, users are as affected as are providers of services. Reinforced by the community's experiences with Sitefinder, all understand that the majority of the Internet's hosts are operated by commercial enterprises and NGOs of all sizes -- all of whom are affected by changes in registry services, particularly when undertaken without notice and appropriate opportunity for remediation. Thus, in the process of developing policy, ICANN must take appropriate steps to ensure that the impact of new registry services upon the broad Internet community are examined and understood. We therefore appreciate and applaud ICANN's introduction of the PDP process.

AT&T's view is that the stability of the DNS is a paramount priority to ICANN's mission. Our views on the importance of protecting innovation are also well documented. We support the need for establishing effective processes that provide certainty to both gTLD registries and to the user community. "

The At-Large Advisory Committee (ALAC) also submitted comments, available in Appendix B. The ALAC encourages developing a neutral, objective process that provides opportunities for relevant parties to participate

Following the public comment period, there was also a public comment provided by Jeff Neuman on behalf of NeuLevel (the operator of .biz), which is archived at:

http://www.gnso.icann.org/mailing-lists/archives/reg-com/msg00003.html

NeuLevel welcomed the steps by ICANN and the GNSO Council towards making the Internet more secure and stable, and offered its support to co-operate in development of a predictable and timely procedure for ICANN to handle requests for consents required by the registry agreements or related contractual amendments. NeuLevel proposed an approval process for consideration by the committee.

2.2 Public comments on Initial Report, June 2005

As part of the GNSO's Policy Development Process, ICANN staff prepared an initial report which was the subject of a public comment period from 1 - 20 June 2005. Comments were solicited for the Public Comment Forum on the Initial Report v4; Process for use by ICANN in considering requests for consent and related contractual amendments to allow changes in the architecture operation of a gTLD registry.

The public comments are archived at:

http://forum.icann.org/lists/registry-services/

Of the six comments submitted to the public comment forum, two were on-topic. One relevant comment was received before the deadline. Bruce Tonkin of Melbourne IT, summarizing discussion on the mailing list of the Registrars' Constituency of the GNSO, stated:

"The report has been discussed on the registrar constituency mailing list.

Postings include:



Tim Ruiz:

http://www.gnso.icann.org/mailing-lists/archives/registrars/msg02862.html

http://www.gnso.icann.org/mailing-lists/archives/registrars/msg02891.html



Bruce Tonkin:

http://www.gnso.icann.org/mailing-lists/archives/registrars/msg02887.html



Champ Mitchell:

http://www.gnso.icann.org/mailing-lists/archives/registrars/msg02888.html



The main areas that have been highlighted are:

- before deciding to send the proposal to the Security Panel or to an

external competition regulator, the ICANN staff need to make a judgement

and may seek expert advice,

- the process for seeking the initial expert advice needs to be

clarified,

- with respect to competition issues, registrars feel that some

registrars should be consulted to provide input as part of the expert

advice.



It would appear to me that in addition to a Standing panel on security,

there may also need to be a standing panel on competition issues. One

or more members of the standing panel could be consulted to provide "expert advice" when ICANN makes its preliminary determination."

One relevant comment was received shortly after the deadline. Arthur Prokosch, an Internet Services Engineer and member of the At-Large Community stated:

"I respectfully submit that due to nature of registries as critically necessary for operation of the DNS and hence the Internet, and the character of their operations s a "single point of failure" for that operation, that NO changes to the contracts or operations of registries be allowed by simple request of the registry. Simply put, any changes to such operations should be proposed, discussed, and brought to consensus or rejection identically whether they come from the groups represented by CBUC, IPC, ISPSP, NCUC, or even the At Large representation."

3.1 Overview of statements

The constituency statements are archived at: http://www.gnso.icann.org/issues/registry-services/constituency-statements.html and are included in full in the attached appendices.

Five Constituency Statements were received, and one from the At-Large Advisory Committee, regarding this PDP.

Commercial and Business User Constituency

The CBUC supports the need for a clear, defined process, with attention given to considerations of introduction and assessment.

Intellectual Property Constituency

The IPC outlines a transparent process that calls for significant community involvement.

The Internet Service Provider and Connectivity Provider Constituency

The ISPCP supports the need for a defined process that is clear in its criteria and is based on community involvement in how and why decisions are reached.

Non-Commercial User Constituency

The NCUC emphasizes ICANN's role in technical coordination and supports a clear, well-defined process.

Registrars Constituency

The Registrars Constituency supports a defined, predictable process that gives appropriate consideration to competition concerns arising from the unique position of registries in the operation of the DNS.

Gtld registries constituency

The gtld Registry Constituency favors development of a simple, transparent and timely procedure for ICANN staff to handle any requested changes in the registry agreements.

All of the statements submitted agreed that the development of a defined, transparent, predictable process for the consideration of changes to gTLD registry services is within ICANN's purview, and will be beneficial for the community.

Areas of agreement about the process specified by two or more constituencies:

• Timeliness: the process should not hinder innovations from being introduced
• "Quick-Look," or "Fast-Track": the process would benefit from having a two-track or multi-track review that would allow certain types of changes to be implemented without difficulty
• Transparency: the process should be transparent, and that there should also be mechanisms for preserving proprietary information
• Predictability: the process should be defined and predictable with clear criteria of evaluation
• Definitions and Criteria: defining terms and criteria for evaluation is essential to producing a useful process
• 3^rd Party Review: self-assessment by a Registry is insufficient to determine the scope of technical or competition harm
• Review Process Reporting: the process should include reporting mechanisms that show the reasoning and rationale for a given decision
• Remedies: the Registry should be given concrete recommendations on remedies to offset identified technical and/or competition harm
• Specific Timeline: there should be a defined a timeline for the review process
• Appeals: there should be an appeals process for decisions regarding approval
• Community Participation: where appropriate, the ICANN community should be participants in the review process

For all of the above areas of agreement, there were still some considerable differences between the constituencies on the specifics of the issues involved. While all may agree that the process should be timely, most have different views on what that means. Also, there were some issues raised by a single constituency and not addressed at all by others, such as how much it will cost to implement a new process (CBUC), what recourse will exist for ICANN and the community if an evaluation fails to accurately assess harm (ISPCP), and whether the process should be different for dominant/non-dominant TLDs (NCUC).

3.2. More detailed review of constituency statements

The staff manager has taken the responses in the constituency statements and grouped the main points into broad categories of related concerns.

3.2.1. Fast Track or Quick Look Process

a. Criteria for Quick Look Process

Description: each response to the PDP suggested that there must be clear guidelines for the application of a quick look or Fast Track process. This is intended to accelerate the review process for non-controversial or trivial service changes.

Response summary:

• At Large: "Whether or not market feedback can provide an accurate barometer of the desirability of the proposed change should be a crucial test within the initial quick look analysis of any proposed change that ICANN assesses."
• CBUC: "30 working days for simple or straight forward change, 90 working days for complex change". All proposed changes should go through a quick look process. "It is not sufficient for registries to self-determine whether a new service is compliant with existing contracts, nor whether a new service will impact the stable and secure operation of the Internet." And, "In those cases where the registry believes that its new service will have no or minimal impact on the Internet, a streamlined process can be followed." The constituency provides a detailed approval procedure including specific timelines and notification requirements.
• IPC: Tier one review completed in 10 days. All proposed changes should go through a quick look process. "ICANN staff should immediately conduct an initial review to determine whether the registry request should be implemented or referred on to the "quick look" procedure for further review." And, "ICANN staff should consider whether the proposed change 1) is consistent with the current registry contract; 2) requires a contract modification; or 3) requires ICANN approval."
• ISPCP: "The ISPCP believes that the "Quick Look" provision of the Staff Manager's report currently raises a number of concerns. In particular, the ISPCP would like to make the following suggestions: The "Quick Look" process needs to be explicitly spelled-out so that all parties have a common understanding of exactly what 'Quick Look' means." And, "Some metric needs to be established that effectively and deterministically decides if a service proposal is eligible for the "Quick Look" procedure. This metric should be based on full community consultation.
• NCUC: The constituency asks whether there should be distinctions made between sponsored and non-sponsored registries (with a negative appraisal), and between dominant and non-dominant registries (with a positive appraisal).
• Registrars: All proposed changes should go through a quick look process that should take no longer than 14 days. "In general changes that do not relate to the registry-registrar agreement or Registry Services could be subject to the fast track process." And, "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 registrar constituency provides a draft list of criteria.

3.2.2. Detailed Review Process

a. Technical Review of New Proposals

Description: many responses to the PDP suggested that there be a review for potential technical harm in introducing the new or changed service. This technical review is intended to weigh the technical impact of a proposed change in service, and to recommend possible remedies to offset harm.

• CBUC: 3rd party technical experts, under NDA, will be retained by ICANN to review technical characteristics of the proposal and provide a detailed report. The constituency also proposes a timeline for any such technical review.
• NCUC: "We support clear, well-defined specifications for registry operation that make DNS a neutral platform for Internet functions."

b. Competition Review of New Proposals

Description: each response to the PDP suggested that there be a review for potential competition harm in introducing the new or changed service. This competition review is intended to weigh the competition impact of a proposed change in service, and to recommend possible remedies to offset harm.

• Registrars: "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."
• NCUC: Constituency is "not convinced of ICANN's ability to engage in competition policy-related forms of regulation."

c. Criteria for Detailed Review

Description: each response called for a deterministic process for deciding whether or not the Quick look process applies to a given proposal. As a result, these criteria also give a clear indication whether or not the detailed process should apply.

• At-Large: "Any privately beneficial activity should be allowed unless it is shown to be publicly detrimental; those who want to forbid an activity bear the burden of proving public harm." And "preference should, wherever possible, be given to designs in which similar services can be provided by multiple parties; designs which permit market-based pricing of services should be preferred over designs that lead to monopoly pricing."
• CBUC: "Registries wishing to introduce any new services which impact the core of the DNS should be required to provide notice, full technical and administrative description/explanation, and remedy opportunities in order for a proper assessment of impact." And "Distinction may be required between new registry services in restricted/sponsored TLDs and unrestricted/unsponsored gTLDs." The constituency poses three questions: 1. Will implementation of the registry operator's requested change harm the legitimate interests of third parties? 2. Will implementation of the registry operator's requested change threaten stability or security of the Internet? 3. Will implementation of the registry operator's requested change violate an existing ICANN policy?
• IPC: Tier two process completed in 24 days, and tier three process completed in 84 days. Total time in all three tiers: 118.
• NCUC: The constituency identifies the need for a Quick look process, and asks that clear criteria for its application be defined.
• Registrars: 30 day evaluation +14 day report preparation. "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 constituency provides suggestions for definitions of these key terms. Also, "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 constituency also outlines specific recommendations regarding registrar-registry competition issues.

3.2.3. Roles of Various Participants

a. ICANN Staff Role

Description: several responses described a clearly defined role for ICANN staff in the process. This included both limitations of their actions and explicit responsibilities.

• CBUC: ICANN staff and their retained experts have the authority to assess the implications of proposed changes in the Quick look process. required.
• IPC ICANN staff is responsible for notification, posting, and initial determination of the quick look process.
• NCUC: "Some issues will be too important to leave to ICANN staff." And, "We do not want ICANN staff to handle substantive policy issues on their own."

b. Third Party Expert Participation

Description: some responses called for independent, third-party, expert analysis of new proposals for services.

• CBUC: 3rd party experts play a role in both Quick look and detailed review processes.
• IPC: ICANN staff is responsible for conducting the Quick look process.
• Registrars: "A proposed change in the functional and performance specifications of a "Registry Service" should include impartial external advice from one or more technical experts." The constituency also proposes that 3rd party, independent, expert advice be used in the quick look process.

c. Community Participation including GNSO

Description: some responses called for clear processes involving gNSO participation in the review process.

• At-Large: "the process should provide opportunities for all relevant parties (including GNSO constituencies and Advisory Committees) to get involved, and should, in particular, incorporate opportunities for meaningful and early public comment."
• CBUC: "Should the registry seek an ICANN policy review then ICANN will seek to schedule such a review by the ICANN community at the earliest possible time. ... In the case of a sponsored gTLD registry, it may be more appropriate for the policy to be taken back to the sponsor's community for reconsideration." Also, the registry is responsible for requesting detailed review process if Quick look process determines that new service cannot be immediately approved.
• IPC: During detailed review a Task Force including representatives from all affected parties to consider the issues identified by ICANN staff during the quick look process. A detailed process and timeline is outlined for the work and recommendations of the task force.
• ISPCP: "Any "Quick Look" process should give a full explanation of what role the gNSO plays in the "Quick Look" activity."
• NCUC: "We wish to emphasize that public consultation, and consultation of constituencies, must be a regular part of dealing with the most important issues."
• Registrars: The constituency proposes that the ICANN Manager of Public Participation facilitate collection of comments from the general community regarding the proposed service change. In addition, a formal process for collecting comments from major affected stakeholders and gNSO constituencies is proposed.

d. Public Notice and Reporting

Description: several responses called for explicit reporting and public notice requirements during the review and evaluation of new proposals.

• At-Large "we generally believe in accountable, transparent and objective processes that ensure that policy is applied in a neutral manner."
• CBUC "Streamlined, clear, documented and transparent procedures (while ensuring the ability to maintain any needed documented and needed confidentiality) for prior assessment of any changes are required.
• IPC: The constituency outlines specific reporting and notice procedures with detailed timelines. They make allowance for the preservation of proprietary information.
• ISPCP: "The "Quick Look" process should have agreed and effective reporting mechanisms in the interest of transparency."

3.2.4. Appeals Process

a. Appeals of Quick look Process

Description: some responses suggested that there be clear procedures in place for appeal of decisions made during the Quick look process.

• CBUC: The registry proposing a new service provides detailed descriptions of how their analysis of the proposed service addresses the issues raised in the denial of the approval. ICANN identifies a 3rd party to hear the appeal. This applies to all the potential appeal processes.
• ISPCP: "In the event that the "Quick Look" process fails to accurately assess the impacts of a new service on the Internet, there must be an effective form of recourse for ICANN and the community."

b. Appeals of Final Outcome

Description: some responses suggested that there be clear procedures in place for appeal of the final outcome of the complete evaluation process.

• CBUC: "An appeals process should be available if the interpretations are considered to be too onerous or if the registry operator can demonstrate that there is no significant negative impact on the Internet by the proposed service."
• IPC: The constituency provides for a structured appeals process at the conclusion of the detailed review, only.
• ISPCP: "Any decision made by the community as a whole must have a process for appeals. If a registry feels that a "service" has received an unfair hearing in the community and will have no impact on the stability and reliability of the Internet, there must be a mechanism to appeal those circumstances."
• Registrars: "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."

3.2.5. Assessment of Process Cost

a. Assessment of Process and Evaluation Costs

Description: some responses suggested that an examination needed to be made of the costs associated with both the Quick look and Detailed Review processes.

• CBUC: "The cost of introducing new services into the registry should be borne by the registry that will benefit from the addition of the new services. There should be a set fee for convening a panel, and that fee should be assessed against the registry." The registry should bear the cost of any appeals process.
• IPC: "In the event the registry operator was successful, each party would bear their own costs. In the event the panel decided in ICANN's favor, the registry operator would be responsible for ICANN's reasonable costs for preparing its appeal position paper."

In response to the draft available at: http://www.icann.org/tlds/gtld-initialreport-registryapproval.htm

The ICANN staff carried out a review of previous requests for changes at:

http://www.gnso.icann.org/issues/registry-services/L-PDP-registry-services-ver3-28nov04.pdf

The ICANN staff found that

• The vast majority of actual registry offerings were "simple" or "straightforward" in nature. This is because most offerings did not require public review or expert analysis. Some did not require ICANN Board Approval.
• Time to evaluate registry offerings can be reduced through collaboration between the registry offering a product and ICANN. As proxy for the community, ICANN can advise the registry early in the product development cycle regarding the anticipated approval process. Through product or process modification, approval can take place at an earlier time than if the product is placed into the approval process at the end of the product development cycle.

Based on the early work of the GNSO committee, ICANN incorporated an approval process into the draft .net agreement.

See:

http://www.icann.org/tlds/dotnet-reassignment/draft-net-agreement-9mar05.pdf

A diagram of the approval process is available at:

http://gnso.icann.org/meetings/review-process-registry-change-requests25apr05.pdf

The Committee of the whole GNSO Council has developed its recommendations for 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 the form of a series of process flow diagrams. The diagrams are:

1. Review process (see http://gnso.icann.org/meetings/review-process-registry-change-requests25apr05.pdf)

The GNSO recommends that parties affected by an ICANN decision use the existing reconsideration processes in the ICANN bylaws. Information on these processes is included in appendices.

Note that where the term "ICANN" is used in the Recommendations -- it refers to the legal entity: "Internet Corporation for Assigned Names and Numbers, a California non-profit public-benefit corporation". ICANN is the party which enters agreements with gTLD registries. ICANN employs staff which will follow the process specified below.

5.1 Approval process

Step 1: Registry Operator or Sponsoring Organisation prepares to make a change

A Registry operator or sponsoring organisation at any time may decide to change the architecture or operation of an existing tld registry service or introduce a new tld registry service.

Step 2: Does the change require ICANN review

A gtld registry operator or sponsoring organisation will determine whether a change to a service would require approval based on the contract between ICANN and the registry operator. In most cases a change that does not impact the users of the service provided by a TLD operator (for example registry-registrar provisioning system, WHOIS service, or DNS nameservice), and is not specifically covered by the contract, would not require approval. The aim of the new approval process is to create an environment that encourages gtld registry operators to discuss any changes that may impact third parties with ICANN before they are made.

Step 3: Deliver to ICANN information on a proposed change

The gtld registry operator or sponsoring organisation should provide ICANN with sufficient information on a change to allow ICANN to assess whether the change should be subject to the approval process. The information should include a technical description of the change as would be seen by external users, and an assessment of the impact on external users. If the registry operator or sponsoring organisation has sought feedback from external parties and the community, details of the process and the results of that feedback should be included. At this stage in the process the information should be regarded by ICANN staff as confidential.

Step 4: Quick Look Process to determine whether further examination is required

ICANN will assess whether approval is required under the agreement between ICANN and the registry operator or sponsoring organisation. As a quick look process, ICANN shall have 15 calendar days to make a "preliminary determination" whether a Registry Service requires further consideration by ICANN because it reasonably determines such Registry Service: (i) could raise significant Security or Stability issues or (ii) could raise significant competition issues.

If ICANN determines during the 15 calendar day "preliminary determination" period that the proposed registry service, does not raise significant Security or Stability (as defined below), or competition issues, registry operator or sponsoring organisation shall be free to deploy it upon such a determination.

ICANN may seek expert advice during the preliminary determination period (from entities or persons subject to confidentiality agreements) on the competition, Security or Stability implications of the registry service in order to make its "preliminary determination." To the extent ICANN determines to disclose confidential information to any such experts, it will provide notice to

Registry Operator (or sponsoring organisation) of the identity of the expert(s) and the information it intends to convey. For Security or Stability implications, ICANN may draw an expert from the Standing Panel of Experts described in Step 6 below.

Step 5: If ICANN believes that there may be a competition issue

ICANN should consider whether the change would lesson competition amongst registrars providing services to registrants, or lesson the fair competition amongst registrants for specific domain names.

In the event ICANN reasonably determines during the 15 calendar day "preliminary determination" period that the change might raise significant competition issues, ICANN shall refer the issue to the appropriate governmental competition authority or authorities with jurisdiction over the matter within five business days of making its determination, or two business days following the expiration of such 15 day period, whichever is earlier, with notice to Registry Operator.

Any such referral communication shall be posted on ICANN's website on the date of transmittal.

Following such referral, ICANN shall have no further responsibility, and registry operator or sponsoring organisation shall have no further obligation to ICANN, with respect to any competition issues relating to the registry service.

If such a referral occurs, the Registry Operator will not deploy the Registry Service until 45 calendar days following the referral, unless earlier cleared by the referred governmental competition authority.

Step 6: Detailed Review process if ICANN believes that there may be an issue with stability or security issues

In the event that ICANN reasonably determines during the 15 calendar day "preliminary determination" period that the proposed change might raise significant Stability or Security issues (as defined below), ICANN will refer the proposal to a Standing Panel of Experts (as defined below) within five business days of making its determination, or two business days following the expiration of such 15 day period, whichever is earlier, and simultaneously invite public comment on the proposal.

The Standing Panel shall have 45 calendar days from the referral to prepare a written report regarding the proposed change's effect on Security or Stability (as defined below), which report (along with a summary of any public comments) shall be forwarded to the ICANN Board. The report shall set forward the opinions of the Standing Panel, including, but not limited to, a detailed statement of the analysis, reasons, and information upon which the panel has relied in reaching their conclusions, along with the response to any specific questions that were included in the referral from ICANN staff.

Upon ICANN's referral to the Standing Panel, the registry operator or sponsoring organisation may submit additional information or analyses regarding the likely effect on Security or Stability of the change.

Upon its evaluation of the proposed change, the Standing Panel will report on the likelihood and materiality of the proposed registry service's effects on Security or Stability, including whether the proposed registry service creates a reasonable risk of a meaningful adverse effect on Security or Stability as defined below:

Security: An effect on security by the proposed Registry Service shall mean

1. the unauthorized disclosure, alteration, insertion or destruction of Registry Data, or
2. the unauthorized access to or disclosure of information or resources on the Internet by systems operating in accordance with all applicable standards.

Stability: For purposes of this Agreement, an effect on stability shall mean that the proposed Registry Service

1. is not compliant with applicable relevant standards that are authoritative and published by a well-established, recognized and authoritative standards body, such as relevant Standards-Track or Best Current Practice RFCs sponsored by the IETF or
2. creates a condition that adversely affects the throughput, response time, consistency or coherence of responses to Internet servers or end systems, operating in accordance with applicable relevant standards that are authoritative and published by a well-established, recognized and authoritative standards body, such as relevant Standards-Track or Best Current Practice RFCs and relying on Registry Operator's (or sponsoring organisation's) delegation information or provisioning services.

Following receipt of the Standing Panel's report, which will be posted (with appropriate confidentiality redactions made after consultation with Registry Operator or sponsoring organisation) and available for public comment, the ICANN Board will have 30 calendar days to reach a decision.

In the event the ICANN Board reasonably determines that the proposed Registry Service creates a reasonable risk of a meaningful adverse effect on Stability or Security, Registry Operator or sponsoring organisation will not offer the proposed Registry Service.

An unredacted version of the Standing Panel's report shall be provided to Registry Operator upon the posting of the report. The Registry Operator may respond to the report of the Standing Panel or otherwise submit to the ICANN Board additional information or analyses regarding the likely effect on Security or Stability of the Registry Service.

The Standing Panel shall consist of a total of 20 persons expert in the design, management and implementation of the complex systems and standards-protocols utilized in the Internet infrastructure and DNS (the "Standing Panel"). The members of the Standing Panel will be selected by its Chair. The Chair of the Standing Panel will be a person who is agreeable to both ICANN and the registry constituency of the supporting organization then responsible for generic top level domain registry policies. All members of the Standing Panel and the Chair shall execute an agreement requiring that they shall consider the issues before the panel neutrally and according to the definitions of Security and Stability.

For each matter referred to the Standing Panel, the Chair shall select no more than five members from the Standing Panel to evaluate the referred matter, none of which shall have an existing competitive, financial, or legal conflict of interest, and with due regard to the particular technical issues raised by the referral.

5.2. Appendix (Reconsideration process in ICANN bylaws)

Given that the Reconsideration Process already exists within the ICANN Bylaws, the GNSO Committee felt that this process should be used in appealing any decisions by the ICANN staff or Board associated with the approval process. Adding an additional appeal process would not remove the availability of the Reconsideration Process (unless the ICANN bylaws were changed), and the additional complexity for the ICANN community of adding additional appeal processes was not seen by the Committee as useful.

The authoritative source for information on the Reconsideration process is the ICANN bylaws (see Article IV: Section 2 http://www.icann.org/general/bylaws.htm#IV). The reconsideration applies to staff actions that contradict an ICANN policy, or to an ICANN Board action taken without consideration of material information. Information on past reconsideration processes is available: http://www.icann.org/committees/reconsideration.

The section is provided for the benefit of the ICANN community to describe the flow of the reconsideration process so that it may be considered as part of the overall approval process.

Step 1: Submit request for reconsideration to Reconsideration Committee

Any person or entity may submit a request for reconsideration or review of an ICANN action or inaction ("Reconsideration Request") to the extent that he, she, or it have been adversely affected by:

• one or more staff actions or inactions that contradict established ICANN policy(ies); or
• one or more actions or inactions of the ICANN Board that have been taken or refused to be taken without consideration of material information, except where the party submitting the request could have submitted, but did not submit, the information for the Board's consideration at the time of action or refusal to act.

The Reconsideration Committee consists of not less than three ICANN Board directors.

The request must include at least the following information:

All Reconsideration Requests must include the information required by the Reconsideration Committee, which shall include at least the following information:

• name, address, and contact information for the requesting party, including postal and e-mail addresses;
• the specific action or inaction of ICANN for which review or reconsideration is sought;
• the date of the action or inaction;
• the manner by which the requesting party will be affected by the action or inaction;
• the extent to which, in the opinion of the party submitting the Request for Reconsideration, the action or inaction complained of adversely affects others;
• whether a temporary stay of any action complained of is requested, and if so, the harms that will result if the action is not stayed;
• in the case of staff action or inaction, a detailed explanation of the facts as presented to the staff and the reasons why the staff's action or inaction was inconsistent with established ICANN policy(ies);
• in the case of Board action or inaction, a detailed explanation of the material information not considered by the Board and, if the information was not presented to the Board, the reasons the party submitting the request did not submit it to the Board before it acted or failed to act;
• what specific steps the requesting party asks ICANN to take-i.e., whether and how the action should be reversed, cancelled, or modified, or what specific action should be taken;
• the grounds on which the requested action should be taken; and
• any documents the requesting party wishes to submit in support of its request.

Step 2: ICANN publishes request on website

ICANN will publish the request on the ICANN website.

Step 3: Is request complete and within 30 days of staff/Board action/inaction.

All Reconsideration Requests must be submitted to an e-mail address designated by the Board's Reconsideration Committee within thirty days after:

• for requests challenging Board actions, the date on which information about the challenged Board action is first published in a preliminary report or minutes of the Board's meetings; or
• for requests challenging staff actions, the date on which the party submitting the request became aware of, or reasonably should have become aware of, the challenged staff action; or
• for requests challenging either Board or staff inaction, the date on which the affected person reasonably concluded, or reasonably should have concluded, that action would not be taken in a timely manner.

Step 4: Publish decision with reasons to decline the request

The Reconsideration Committee shall review Reconsideration Requests promptly upon receipt and announce, within thirty days, its intention to either decline to consider or proceed to consider a Reconsideration Request after receipt of the Request. The announcement shall be posted on the Website.

The Reconsideration Committee announcement of a decision not to hear a Reconsideration Request must contain an explanation of the reasons for its decision.

To protect against abuse of the reconsideration process, a request for reconsideration may be dismissed by the Reconsideration Committee where it is repetitive, frivolous, non-substantive, or otherwise abusive, or where the affected party had notice and opportunity to, but did not, participate in the public comment period relating to the contested action, if applicable. Likewise, the Reconsideration Committee may dismiss a request when the requesting party does not show that it will be affected by ICANN's action.

Step 5: Publish decision to consider the request

The Reconsideration Committee shall review Reconsideration Requests promptly upon receipt and announce, within thirty days, its intention to either decline to consider or proceed to consider a Reconsideration Request after receipt of the Request. The announcement shall be posted on the Website.

The Reconsideration Committee shall have the authority to:

• evaluate requests for review or reconsideration;
• determine whether a stay of the contested action pending resolution of the request is appropriate;
• conduct whatever factual investigation is deemed appropriate;
• request additional written submissions from the affected party, or from other parties; and
• make a recommendation to the Board of Directors on the merits of the request.

If the Reconsideration Committee requires additional information, it may elect to conduct a meeting with the party seeking Reconsideration by telephone, e-mail or, if acceptable to the party requesting reconsideration, in person. To the extent any information gathered in such a meeting is relevant to any recommendation by the Reconsideration Committee, it shall so state in its recommendation.

The Reconsideration Committee may also request information relevant to the request from third parties. To the extent any information gathered is relevant to any recommendation by the Reconsideration Committee, it shall so state in its recommendation.

The Reconsideration Committee shall act on a Reconsideration Request on the basis of the public written record, including information submitted by the party seeking reconsideration or review, by the ICANN staff, and by any third party.

Step 6: Any ICANN staff comments on the request to be made public

The Reconsideration Committee may ask the ICANN staff for its views on the matter, which comments shall be made publicly available on the Website.

Step 7: Is a stay of action appropriate pending resolution of the request?

The reconsideration committee can determine whether a stay of the contested action pending resolution of the request is appropriate.

Step 8: Recommend to Board to play stay on action

If the reconsideration committee determines whether a stay of the contested action pending resolution of the request is appropriate, it will make a recommendation for the ICANN Board to do so.

Step 9: ICANN Board publishes decision

The ICANN Board will publish its decision on whether to place a stay on the contested action in response to the advice of the reconsideration committee. The Board shall not be bound to follow the recommendations of the Reconsideration Committee.

Step 10: Make and publish recommendation to the Board

The Reconsideration Committee shall make a final recommendation to the Board with respect to a Reconsideration Request within ninety days following its receipt of the request, unless impractical, in which case it shall report to the Board the circumstances that prevented it from making a final recommendation and its best estimate of the time required to produce such a final recommendation. The final recommendation shall be posted on the Website.

Step 11: Board considers recommendation

The Board shall not be bound to follow the recommendations of the Reconsideration Committee.

Step 12: Board publishes decision

The final decision of the Board shall be made public as part of the preliminary report and minutes of the Board meeting at which action is taken.

5.3. Appendix (Independent Review Process from ICANN Bylaws)

The independent review process of Board actions is a further level or review provided for in the ICANN Bylaws, Article IV, Section 3. (http://www.icann.org/general/bylaws.htm#IV). It provides for an independent third-party review of Board actions alleged by an affected party to be inconsistent with the Articles of Incorporation or Bylaws.

This section has been provided for completeness to give an overall view of the appeal options associated with a decision around approval of a change requested by a gtld registry.

Step 1: Submit request for reconsideration to Independent Review Panel

Any person materially affected by a decision or action by the Board that he or she asserts is inconsistent with the Articles of Incorporation or Bylaws may submit a request for independent review of that decision or action.

Requests for such independent review shall be referred to an Independent Review Panel ("IRP"), which shall be charged with comparing contested actions of the Board to the Articles of Incorporation and Bylaws, and with declaring whether the Board has acted consistently with the provisions of those Articles of Incorporation and Bylaws.

The IRP shall be operated by an international arbitration provider appointed from time to time by ICANN ("the IRP Provider") using arbitrators under contract with or nominated by that provider.

The IRP shall have the authority to:

• request additional written submissions from the party seeking review, the Board, the Supporting Organizations, or from other parties;
• declare whether an action or inaction of the Board was inconsistent with the Articles of Incorporation or Bylaws; and
• recommend that the Board stay any action or decision, or that the Board take any interim action, until such time as the Board reviews and acts upon the opinion of the IRP.

Step 2: Either party may elect to use a 3 member panel instead of a 1 member panel

Either party may elect that the request for independent review be considered by a three-member panel; in the absence of any such election, the issue shall be considered by a one-member panel.

Step 3: Is a stay of the action appropriate pending resolution of the request?

The Independent Review Panel may recommend that the Board stay any action or decision, or that the Board take any interim action, until such time as the Board reviews and acts upon the opinion of the Independent Review Panel.

Step 4: Recommend to Board to stay action

Independent Review Panel recommends that the Board stay any action or decision, or that the Board take any interim action

Step 5: Board publishes decision

The ICANN Board will publish its decision on whether to place a stay on the contested action in response to the recommendation of the Independent Review Panel.

Step 6: Make final recommendation to the Board

Declarations of the Independent Review Panel shall be in writing. The IRP shall make its declaration based solely on the documentation, supporting materials, and arguments submitted by the parties, and in its declaration shall specifically designate the prevailing party.

Step 7: Board publishes decision

Where feasible, the Board shall consider the Independent Review Panel declaration at the Board's next meeting, and publish its decision in the minutes of the meeting.

A response from each constituency is required here.

7.1.

7.2. A1: Non-commercial users constituency statement

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

NCUC observes that by initiating this procedure, ICANN is assuming that its contracts alone are not sufficient to provide a predictable and stable basis for the industry. It is assuming that it needs an ongoing form of oversight to supplement its contracts and contractual modifications, because the contracts cannot deal with all possible developments in the future. Thus, ICANN is expanding into additional areas of industry regulation, although no one wants to admit that.

In formulating its response, NCUC begins by asking: How are non-commercial domain name users specifically affected by this change? The answer, NCUC believes, is that there is no commercial/non-commercial angle to this issue. It is more a question of:

a) consumer protection; i.e., how users/consumers relate to suppliers and what kind of regulatory procedures are needed to protect consumers given the high switching costs associated with changing registry suppliers after a domain name is well-established.

b) technical coordination; i.e., what kind of technical regulation or specifications are needed to protect third parties using domain names on the Internet from harmful changes made in registry operation, while preserving as much as possible the freedom of suppliers to respond to the market and innovate.

NCUC notes that whether consumers or users are commercial or non-commercial has little bearing on these issues.

We also note that a) and b) are distinct policy issues. a) Involves protection of the parties buying service from a gTLD registry, who may have options, while b) involves protection of third party users of a domain name, who probably do not have any options if they want to connect to the party using the affected registry. We also note that a) involves economic forms of regulation which also involves competition policy concerns, while b) is more a matter of technical coordination.

NCUC strongly recommends that the PDP distinguish clearly between a) and b) in its consideration of the new process. Is the object of the process economic regulation or technical coordination?

The document we are asked to comment on proposes no policies, so our comments can only suggest questions or problems for the PDP process to consider.

1. One question the PDP should consider is whether all issues related to a) above should be handled by national regulatory authorities instead of ICANN. We support ICANN's need for technical coordination related to matters under b). We are less confident of ICANN's ability and right to engage in a). We are also not convinced of ICANN's ability to engage in competition policy-related forms of regulation.

We recognize, however, that it may be difficult for consumers to obtain adequate protection in a transnational business context.

Additionally, registries and registrars can and do hide behind their contracts with ICANN. The structure of ICANN's contracts allows a willful registry or registrar to "hide the ball" by pointing to a different contracting party as responsible for the conduct the registrant complains of. Thus, registries maintain that contracts imposed by ICANN bar them from certain courses of action, registrars likewise claim that contract provisions imposed by ICANN prevent them from acting, and ICANN says it is not a regulator and that any remedy lies in the contracts which it claims are negotiated freely. At this moment, when we discuss the introduction of new regulatory procedures,

ICANN has to make clear what its position precisely is vis-à-vis consumer protection. The new procedures developed in this PDP should certainly not worsen the situation described in this paragraph.

While there is a case for a global governance regime, we note that ICANN invested most of its effort in protecting trademarks and domain name supplier interests, and has shown very little interest in protecting consumers and users. For ICANN to become an effective consumer protection agency significant changes would have to be made in its representational structure and decision making processes.

2. The PDP document refers to a "quick look" process followed by a more involved process if a change fails the "quick look."

A question the PDP needs to face squarely is: What is a subject to a "quick look" and what is not? What is a "new registry service"?

How is that defined? Who will make that determination initially?

What happens when the registry and ICANN disagree on that issue?

If a process is created, there should be guidelines as to when an issue is important enough to put it before ICANN bodies, invite public comment etc. Some issues will be too important to leave to ICANN staff.

3. The NCUC recognizes the danger that a registry can make damaging changes, such as in the Sitefinder case. We support clear, well-defined specifications for registry operation that make DNS a neutral platform for Internet functions. We also recognize a threat that innovative changes will be stifled by a central organization such as ICANN which may have incentives to prevent useful changes in order to maintain its control over the industry.

4. The PDP should consider whether there should be a distinction between policies applied to sponsored and unsponsored TLDs. NCUC believes the answer will be usually no. There have to be good reasons to make a distinction. If the justification for regulation is economic; i.e, that users are locked in to a supplier and cannot switch service providers without incurring damaging costs, then the same fundamental economic problem applies regardless of whether the registry is sponsored or not. In some respects, switching costs are more serious with sponsored TLDs, since they are supposed to represent a community identity and not just an individual company/organization's identity. If the justification for the review process is technical, the answer is the same: there is no relevant technical distinction between sponsored and un-sponsored registries. We do, however, believe that sponsored TLDs could be and should be required to consult their "community" before making changes in operation of the sort contemplated by the PDP.

5. The PDP should consider whether there should be a distinction between the treatment of dominant and non-dominant TLDs? In this case NCUC believes there is a stronger case for a distinction. A major dominant registry may have the power to move the entire industry and technology, whereas smaller ones would not. However, the lock-in problem of consumers applies regardless of whether the registry is dominant or not. As the Internet and DNS grow, larger numbers of users will be affected by TLD registries regardless of their overall share of the market. Thus, the policy must identify carefully what problem it is trying to solve.

6. We wish to emphasize that public consultation, and consultation of constituencies, must be a regular part of dealing with the most important issues. We do not want ICANN staff to handle substantive policy issues on their own.

7.3. A2: Commercial and business users constituency

Introduction

In the latter half of 2003, registry operators introduced new registry services at the registry level of the domain name system (DNS) without notice to Internet users.

The Internet Community has called for a defined, predictable process for the consideration of new services or other such changes in the architecture or operation of a gTLD registry prior to any changes being introduced. The Commercial and Business User Constituency (BC) supports this call wholeheartedly.

Commercial and Business User Interest

Stability and security of the DNS core of the Internet provides the platform for innovation

Business users are today engaged in building, networks, services and applications at the "edge" of the DNS. Reliable, stable and predictable operation of the DNS is essential to the stability and security of the Internet, and to the ability of businesses, regardless of their size, to innovate in services and applications and to use the Internet.

The DNS is reliable, when it operates according to the technical protocols that guide its functioning, but it is vulnerable, when someone purposely or accidentally violates these operational assumptions. The Internet purposefully has a distributed architecture. Largely, innovation originates and belongs at the edge of the Internet, not at the core. Introducing abrupt changes into the core of the DNS creates an unpredictability which directly threatens the Internet's stability.

The Internet is essential to the way the world communicates today

Today, over half a billion users are on the Internet; and there are already close to 200 million hosts that are largely provided by enterprises, including BC members. As important as the Internet has become already to communications and information access, its full value is only beginning to emerge. Increasingly, the Internet is an infrastructure that is relied upon for information and transactions by NGOs, enterprises, individuals and governments.

The registry monopoly brings rewards and responsibilities

Registry functions are a small, but critical part of the core infrastructure of the global Internet. They are one of the elements where stable operation is key, so that other functions can operate reliably. The gTLD registry operations are the result of a contract award by ICANN to a single entity to manage the registry service for a single generic TLD. Such awards are a "natural monopoly": monopoly status brings specific responsibilities, benefits and certain limitations.

Therefore, the BC supports the need for a clear, defined process to determine whether, when, and how new registry services may be introduced, and what notice and remedy may be necessary.

The rational for an ICANN policy in this area

ICANN's by-laws tell us its stated mission is "in particular to ensure the stable and secure operation of the Internet's unique identifier systems." Improperly managed change to these systems disrupts this stable and secure operation.

ICANN, as an international body, is responsible for the framework for policy development governing the gTLD registries and provides and enforces the contracts that allocate the responsibility of operating a registry service for the gTLDs. Of particular importance is the recognition that registries are not necessarily the most affected parties by changes in their operation.

ICANN facilitates consensus. A stable and secure Internet to date results from the established practice that changes that will affect the operational reliability of the DNS take place only after extensive discussion within the Internet technical community, so that bugs can be worked out and a consensus can emerge for or against the change, including how to incorporate it across the Internet.

Initial recommendations

1. TOR. The GNSO task force Terms of Reference identify four main tasks. The BC have propose some modification to the Out-of-scope constraints of the TOR.
2. Notice is required. Registries wishing to introduce any new services which impact the core of the DNS should be required to provide notice, full technical and administrative description/explanation, and remedy opportunities in order for a proper assessment of impact.
3. Impact self-assessment is not sufficient. It is not sufficient for registries to self-determine whether a new service is compliant with existing contracts, nor whether a new service will impact the stable and secure operation of the Internet.
4. Streamlined, clear, documented and transparent procedures (while ensuring the ability to maintain any needed documented and needed confidentiality) for prior assessment of any changes are required.
5. Appeals. An appeals process should be available if the interpretations are considered to be too onerous or if the registry operator can demonstrate that there is no significant negative impact on the Internet by the proposed service.
6. Sponsored gTLDs. Sponsors have established mechanisms within their community of interest, similar to ICANN, to develop and consider changes in the architecture or operation of their gTLD. However, matters, which affect the Internet security and stability at-large are of essence for this PDP. Distinction may be required between new registry services in restricted/sponsored TLDs and unrestricted/unsponsored gTLDs.
7. Cost. Consideration must be given to costs and how they are to be funded.

Annex 1

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

The GNSO Task Force Terms of Reference identifies four main tasks.

Detailed Recommendations

(1) Develop guidelines for when approval is required to make a change based on the existing registry agreements. (for action by ICANN staff in consultation with registry operators and sponsors)

Notice should always be given to the ICANN staff on the intent to introduce new registry services.

In those cases where the registry believes that its new service will have no or minimal impact on the Internet, a streamlined process can be followed. Documentation from the registry should be technically and administratively complete, sufficient to enable a rigorous assessment of the request, at the time of submission to ICANN.

ICANN should acknowledge receipt of the request for review within 3 business days, including advising the registry if more information will be needed, and within 10 business days of receipt of a request, should advise the registry of which timeline¹ will be followed - 30 day fast track, or 90 day assessment and consultation.

Explicit Approval must be sought when:

A) a gTLD registry's action is likely to:

1. violate an existing ICANN policy

2. violate or change an explicit or implicit, accepted, de-facto or de-jure, Internet protocol, standard, practice or assumption of operation

3. affect the operational stability of other widely used existing applications and services

4. affect applications and services across multiple organisational or market boundaries

5. replace multiple existing applications with a centralised single application

OR

B) a gTLD registry's database gives it substantial market power in the gTLD market [alternate: substitute "substantial market power" with a defined % market share, eg. "more than 20% market share of the gTLD DNS."

OR

C) a gTLD registry could expect that its actions would give rise to genuine technical, competition, or legal concerns.

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

A check list of relevant issues should be developed during the PDP process.

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

The objective of the process should be to provide a predictable, timely and transparent (ultimately) process.

The registry decides to introduce a new service at the registry level:

1. a) submit a request for a quick-check approval

OR

b) submit a request for a full Internet Community review by ICANN

2. A quick-check request by a registry would have the characteristics of:

a) an expectation that it will be granted.

b) including sufficient information supporting the planned change such that ICANN staff and their retained experts can fully assess the implications of the planned changes such that they could give approval.

c) being conducted entirely in confidence between the registry and ICANN.

d) being accompanied by a fee sufficient to cover the cost of undertaking the quick-check (ie. a scale of fees may be set dependent on the nature of the planned change)

3. A quick-check would be undertaken by the ICANN staff using the expertise of retained international experts in the fields of technology, competition, law and international public policy. Depending on the complexity and potential impact of the planned change, a quick-check would be expected to be completed in:

a) 30 working days - for simple or straight forward change

b) 90 working days - for a complex change

4. At the conclusion of a quick-check a report of the staff/experts considerations, findings and conclusions will be provided to the requesting registry. If the conclusion is approval of the request, the process is complete. If the conclusion is rejection or recommendation for amendments to the planed changes, then the registry has the option of:

a) forgoing the planned change

b) undertaking and committing to the recommended amendments, then implementing the amended planed change once the amendments have been approved by ICANN staff, after confirmation with appropriate experts described above.

c) reconfiguring the planned change and requesting a completely new approval

d) requesting that ICANN undertake a policy review of the planned change

e) requesting that ICANN's independent review process be instigated

5. Should the registry seek an ICANN policy review then ICANN will seek to schedule such a review by the ICANN community at the earliest possible time. Such a review would be fully transparent and time bound (time to be determined during the PDP process. 120 days is suggested). In the case of a sponsored gTLD registry, it may be more appropriate for the policy to be taken back to the sponsor's community for reconsideration.

6. Should the registry seek a review by the ICANN independent review process (see below)

7. When a change in a gTLD registry's architecture or operations are implemented the report from the ICANN "quick chec" review must be posted on both the ICANN and registry's website. Such a report may have commercially confidential information expurgated, by mutual agreement between the registry and ICANN; however, the confidential information must be provided to ICNAN, and must be available for review and consideration by experts, should they be retained by ICANN. Such experts should sign appropriate non disclosure agreements related to that confidential information. (Should the SECSAC need to review such materials, a working group of the SECSAC can be convened, and can be provided with confidentiality agreements as appropriate.)

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

In order to ensure that valid business interests are not adversely affected, the appeals process should be established with a two stage time frame. One, as an expedited process that both parties must agree to and the second, a longer time frame, when the expedited process is not feasible due to complexity, or other factors. [Editorial note: e.g. introducing a new service over an extended international holiday period may introduce a matter of two weeks of needed delay in order to ensure that resources, both internal and external within ICANN, the ICANN community and within the registry, are available.]

Expedited appeals process: The registry should be responsible for preparing and presenting detailed descriptions of the service, its technical impact on the DNS, and addressing in detail, those issues that were defined by ICANN in its denial of approval to introduce the service. Such materials should be in English and should be delivered in complete detail, to the designated contact for the appeals procedure, as well as to ICANN's designated contact.

ICANN should be responsible for acknowledging the receipt of the materials, and for identifying any further or clarification that may not be included in the submission, based on the reasons for the denial.

ICANN should be responsible for identifying an appropriate neutral entity to hear the appeal, including seeking public comment on the proposed appeals process and procedures for empanelling an appeals panel.

Questions to be answered:

Who pays for the request or appeals process?

To date, ICANN has spent considerable financial resources, both internally and externally in dealing with Sitefinder. The cost of introducing new services into the registry should be borne by the registry that will benefit from the addition of the new services. There should be a set fee for convening a panel, and that fee should be assessed against the registry.

Options: The fee should be cost based and cannot include the reimbursement of ICANN's time but can include the reimbursement and funding of fees and travel for experts who are asked by ICANN to supply evaluations. Experts who are serving as volunteers to ICANN but who have established neutrality and expertise can be retained as experts for this process (including members of the SECSAC). During such time, they should not fulfil their volunteer duties.

¹ Throughout these policy recommendations where specific timeframes are noted, it is recognised that there are likely to be possible instances where the timeframes are not met. In such instances the staff must write to the registry applicant (and ICANN community if also involved) prior to the expiration of policy timeframe, clearly stating why the timeframe is not going to be met and providing an estimate of a new timeframe to completion.

7.4. A3: Intellectual Property Constituency

I. INTRODUCTION

The Intellectual Property Constituency (the "IPC") is pleased to have this opportunity to provide input into the procedure to be used by ICANN when considering requests from registry operators for changes to the architecture or operation of a gTLD registry. The Terms of Reference posted by the GNSO counsel specifically state that:

The purpose of this policy development process 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.

With this stated goal in mind, the IPC submits the following comments for consideration.

II. COMMENTS

In the Staff Manager's Report posted on November 19, 2003, the Staff Manager described the current informal process that the ICANN staff has historically used when considering requests from registry operators to alter the architecture or operation of the registry. In the past, ICANN staff conducted an initial review to determine whether the change proposed by the registry operator required ICANN approval or a modification of the relevant gTLD agreement. The outcome of this initial staff review then determined how the process would proceed. The Staff Manager's Report concluded that the current informal process has led to inconsistent decisions and insufficient justification for these decisions.

In order to improve the current situation, the IPC suggests that ICANN adopt a three-tiered procedure for considering registry operator's requests to alter the architecture or operation of a registry. The IPC believes that the structured approach set forth below will provide the consistency and transparency that ICANN seeks to achieve.( (3) In some instances, the procedures suggested by the IPC are merely a formalization of the "informal" process described in the Staff Manager's Report))

Given that speed and efficiency are two paramount concerns expressed in the Staff Manager's Report, the timelines recommended below are suggested in order to facilitate the timely resolution of registry requests. That being said, the IPC is fully aware that the suggested timelines set forth in this proposal may need to be adjusted in order to reflect the fact that many of the participants in the ICANN process are volunteer-based organizations that may require timelines that take it into account this reality. ((4 A summary of the timeline for this proposal may be found at the end of this paper.))

A. FIRST TIER - INITIAL REVIEW

The IPC believes that all requests for changes in the architecture or operation of a registry be submitted to ICANN's President for consideration by appropriate ICANN staff. Immediately upon receipt of such a request, ICANN staff should provide public notice on the ICANN web site that ICANN has received a request from a registry operator. ICANN should also forward a copy of this pubic notice to each supporting organization. This public notice should be posted and distributed within 24 hours of receiving the registry operator's request. This public notice should contain a summary of the requested change(s) and provide the deadline for ICANN staff's Preliminary and Final Initial Review Reports (discussed below).

Upon disseminating the public notice, ICANN staff should immediately conduct an initial review to determine whether the registry request should be implemented or referred on to the "quick-look" procedure for further review. In making this determination, ICANN staff should consider whether the proposed change 1) is consistent with the current registry contract; 2) requires a contract modification; or 3) requires ICANN approval. The results of the initial review should be posted on the ICANN web site in a Preliminary Initial Review Report and forwarded to each supporting organization no later than 48 hours from the posting of the initial public notice. The Preliminary Initial Review Report should contain an explanation for ICANN staff's determination and set forth a deadline for interested parties to submit comments regarding the determination set forth in the Preliminary Initial Review Report. The deadline for comments should be no less than 5 days from the posting of the Preliminary Initial Review Report on the ICANN web site.

Within 48 hours of the close of the comment period, ICANN staff should post a Final Initial Review Report on the ICANN web site and forward a copy of this report to each supporting organization. This report should contain the final determination of ICANN staff's initial review (i.e., whether the registry operator's request will require a "quick-look" analysis) an explanation of this determination and a summary of and response to the relevant comments received during the public comment period.

If the ICANN staff determines that the proposed change is consistent with the current contract, does not require modification of the current contract and does not require ICANN approval, ICANN staff should advise the requesting registry operator that it may implement the requested change. ICANN staff should post public notice of its communication with registry operator on the ICANN web site and forward a copy of this public notice to each supporting organization.

In contrast, should ICANN staff determine that the registry operator's requested alteration is inconsistent with the current contract, requires modification of the current contract or requires ICANN approval, ICANN staff should advise the registry operator that it will conduct a "quick-look" analysis of the registry operator's requested changes. Here again, ICANN staff should post public notice of this communication on the ICANN web site and forward a copy of this public notice to each supporting organization.

B. SECOND TIER - "QUICK-LOOK" ANALYSIS

Within 7 days of advising the registry operator of its decision and posting notice of this communication on the ICANN web site, the ICANN staff will post a Preliminary Quick-Look Analysis Report on the ICANN web site and forward a copy of this report to each supporting organization. This report should set forth ICANN staff's determination on the following questions:

1. Will implementation of the registry operator's requested change harm the legitimate interests of third parties?

2. Will implementation of the registry operator's requested change threaten stability or security of the Internet?

3. Will implementation of the registry operator's requested change violate an existing ICANN policy?

If the answer to any of these questions is affirmative, the ICANN staff should recommend that the registry operator's request proceed to the third tier for more comprehensive evaluation and consultation with affected parties. In addition, the Preliminary Quick-Look Analysis Report should provide deadline for receiving public comments on the determinations set forth in the report. The deadline for comment should be no less than 10 days from the posting of the Preliminary Quick-Look Analysis Report on the ICANN web site.

Within 7 days from the close of the public comment period, ICANN staff should forward a Final Quick-Look Analysis Report to the requesting registry operator, post a copy of the report on the ICANN web site and forward a copy of the report to each support organization. The Final Quick-Look Analysis Report should set forth the ICANN staff's final determinations and advise whether the registry operator's request will be forwarded on for a more comprehensive evaluation. The Final Quick-Look Analysis Report should also contain an explanation of the ICANN staff's determinations, a summary of comments received during the public comment period and a response to all relevant comments received during the public comment period. If it is determined that no further evaluation of the registry operator's request is required, ICANN staff should work with the registry operator to implement the necessary changes within 120 days from the date of the Final Quick-Look Analysis Report.

C. THIRD TIER - EVALUATION AND CONSULTATION

Within 7 days of posting a Final Quick-Look Analysis Report requiring further evaluation of a registry operator's request, ICANN staff should post a Preliminary Evaluation Notification Report identifying the issues to be explored during the more detailed evaluation, identify those parties that it believes will be affected by the proposed change requested by the registry operator and any areas that require the input of outside expert advice. This preliminary report should also set forth a deadline, no less than 7 days from the posting of the report, for a public comment period. This preliminary report should be posted on the ICANN web site and forwarded to each supporting organization.

Within 5 days from the close of the public comment period, ICANN staff should post a Final Evaluation Notification Report setting out its determinations regarding the issues to be considered during the further evaluation, a final list of affected parties and the issues that will require outside expert advice. The Final Evaluation Notification Report should also contain a call for all affected parties identified in the final report to appoint a designated representative(s) to participate in a Task Force to further evaluate and consider the issues identified therein. In addition, the Final Evaluation Notification Report should list the names of the outside experts that will be consulted during the process. Each affected party should be allowed 5 days from the posting and distribution of the Final Evaluation Notification Report to advise the ICANN staff of the names of the designated representative(s) appointed to serve on the Task Force.

The appointed Task Force should have an evaluation period not to exceed 35 days from the close of the 5-day period for appointment of Task Force representatives. During this evaluation period, the Task Force should carefully consider the issues/sub-issues set out in the Final Evaluation Notification Report and consult with the identified outside experts on the issues set out in the final report. The Task Force should prepare a Preliminary Evaluation Task Force Report that should be posted on the ICANN web site and forwarded to each supporting organization. This preliminary report should clearly identify the issues and sub-issues considered by the Task Force, set forth the Task Force's conclusions with regard to each issue/sub-issue and clearly explain the Task Force's reasoning for its determinations. The Preliminary Evaluation Task Force Report should also set deadline for public comment on the preliminary report. The deadline for public comment to the Preliminary Evaluation Task Force Report should be no greater than 10 days for the posting and distribution of the preliminary report.

Within 15 days of the close of the public comment period, the Task Force should post a Final Evaluation Task Force Report on the ICANN web site, forward a copy of the report to the requesting registry operator and forward a copy to each supporting organization. This Final Evaluation Task Force Report should clearly identify the issues and sub-issues considered by the Task Force, set forth the Task Force's conclusions with regard to each issue/sub-issue, thoroughly explain the Task Force's reasoning for its determinations, summarize all relevant comments received in the public comment period and respond to each relevant comment received during the public comment period. The Final Evaluation Task Force Report should also contain a recommendation from the Task Force to ICANN's President setting out its recommendation of whether ICANN should take the necessary steps to implement the changes requested by the registry operator. Provided the registry operator does not lodge an appeal (see below), the ICANN President should present the Final Evaluation Task Force Report to the ICANN Board along with the recommendation of the Task Force. In the event an appeal is lodged, the ICANN President would await the outcome of the appeal before making any presentation to the ICANN Board.

The suggested timelines set forth above are designed to allow the entire three-tier process to conclude in less than 120 days for initiation by a registry operator's request to the ICANN President.

D. PRESERVATION OF PROPRIETARY INFORMATION

The IPC also realizes that the consideration of certain registry operator requests will require that review and evaluation of proprietary information. For this reason, ICANN should develop a procedure whereby the registry operator is required in its initial request to advise the ICANN President that its proposed change(s) will include the use of proprietary information and request that appropriate action be taken to preserve the proprietary nature of this information.

Once identified by the registry operator, ICANN staff should be allowed to provide high-level summaries of such information in all public notices regarding the registry request. In the event a registry request requires consideration at the third tier, such proprietary information should only be disclosed to Task Force members that demonstrate they have no conflict of interest and sign the required confidentiality and non-disclosure agreement. In addition, minutes of all Task Force discussions of such proprietary information should only contain very high-level summaries of the discussions and all discussion of proprietary information during Task Force meetings should be held off line; provided, however, that a written summary of such discussions is available for public inspection.

E. APPEAL

The IPC supports the development of an appeal process whereby a registry operator may appeal a decision denying its request for a change to the architecture or operation of a TLD. In keeping with the goal of streamlining the decision process, the IPC believes that any appeal process should be completed within 60 days from the posting of the Final Task Force Evaluation Report. This appeal would take place only on paper. Each party would submit a written paper arguing its position on appeal. All appeals could then be considered and decided by a panel consisting of one representative from the GNSO, the ccNSO and the ASO. In the event the registry operator was successful, each party would bear their own costs. In the event the panel decided in ICANN's favor, the registry operator would be responsible for ICANN's reasonable costs for preparing its appeal position paper.

III. CONCLUSION

The IPC believes that the formalization of a procedure for considering registry operator requests seeking changes to the architecture or operation of a gTLD registry will assist ICANN in managing the process in an efficient, open and transparent manner. Additionally, the IPC believes that a formalized procedure will provide the certainty sought by the registry community. Lastly, the IPC believes that the three-tiered approach and appeals procedure outlined above provide ample opportunity for participation by the Internet stakeholder community including, but not limited to the GNSO constituencies, by providing numerous public comment periods and a Task Force populated with representatives of parties identified as being most affected by any requested registry changes.

TIMELINE SUMMARY

TIER ONE

Registry Request sent to ICANN President.

Public Notice of Request posted and sent to supporting organizations within 24 hrs.

Preliminary Initial Review Report posted and sent to supporting organizations within 48 hours of posting of Public Notice.

Comment Period for a minimum of 5 days from posting of Preliminary Initial Review Report.

Final Initial Review Report posted within 48 hours of close of Comment Period. If no further review required, implementation begins. If further analysis required, move to Tier Two.

Total days in Tier One: 10

TIER TWO

Preliminary Quick-Look Analysis Report posted and sent to supporting organizations within 7 days of posting of Final Initial Review Report.

Comment Period for a minimum of 10 days from posting of Preliminary Quick-Look Analysis Report.

Final Quick-Look Analysis Report posted and sent to supporting organizations within 7 days of close of Comment Period. In no further analysis required, ICANN should work with requesting registry operator to implement change within 120 days from the posting of this report. If further analysis required move to Tier Three.

Total days in Tier Two: 24

Total days in Tier One & Two: 34

TIER THREE

Preliminary Evaluation Notification Report posted and sent to supporting organizations within 7 days of posting of Final Quick-Look Analysis Report.

Comment Period no less than 7 days from posting of Preliminary Evaluation Notification Report.

Final Evaluation Notification Report posted and sent to supporting organizations within 5 days from close of public comment period. Appointment of Task Force representatives from each affected party have 5 days from the posting of Final Evaluation Notification Report to appoint representative to Evaluation Task Force.

Preliminary Evaluation Task Force Report posted and sent to supporting organizations within 35 days from close of appointment period.

Comment Period of no less than 10 days from Posting of Preliminary Evaluation Task Force Report.

Final Evaluation Task Force Report posted and sent to supporting organizations within 15 days from close of Comment Period.

Total Tier Three days: 84

Total days Tiers One - Three: 118

APPEALS

Conclusion Of Appeal: 60 days from posting and dissemination of the Final Evaluation Task Force Report.

7.5. A4: Internet Service Provider and Connectivity Providers Constituency

Introduction

One of the central commitments of the ISPCP constituency is to help ensure the stability, reliability and consistency of services in the Internet. ISP customers demand that naming and numbering services in the Internet be consistent and reliable. A common theme of our work in this area is the "principle of least astonishment." As new services appear in the Internet they should only do so in ways that leave existing services unchanged or improved.

Recently, this fundamental principle was violated by the introduction of "services" that fundamentally altered the behavior of key Internet applications. This was done without notice to users, ISPs or application developers. The result was contrary to our goal of a stable, reliable and consistent Internet.

Many in the Internet community have joined together to demand a well- articulated, well-defined process for the consideration, testing and implementation of new changes to the fundamental architecture of the Internet. Specifically, the ISPCP Constituency welcomes the call for consideration of a deterministic, well-defined process for changes in the names space.

Can ICANN Make Policy in This Area?

The ISPCP constituency believes that it is essential for ICANN to develop policies that govern the introduction of new "services" in the Internet's names space. The constituency believes that policies relating to the stable operation of the Internet's name space form an essential part of the organization's mission.

Recent events have clearly shown that solely relying on negotiation and implementation of contracts with key operators of names related services in the Internet to achieve this goal, is insufficient and cannot guarantee success. ICANN must remain a consultative international body that builds policy through bottom-up consensus. It implements that consensus through its contracts and external operational policy. As circumstances change, that same consultative, consensus oriented approach must be followed to address new "services" or situations.

It is essential to understand that registries are only the providers of the service, they are not the essential consumers of the service. The broader ICANN community represents the parties most affected by gTLD policies and services.

It is clear then that it is not merely possible for ICANN to make policies regarding new gTLD "services." In fact, it is essential.

Recommendation: Registries should not work in Isolation

Under no circumstances should a registry be allowed to determine -- on their own -- whether a new "service" is compliant with existing contracts or policies, or determine if a new "service" will have any impact on the stability and reliability of the Internet.

Recommendation: Transparent Consideration

Any process regarding new services must provide an effective means for notifying those impacted. Those suggesting fundamental changes to the architecture or behavior of the Internet must give prior, effective, disclosure and allow examination by the responsible technical bodies. Proposed "services" must be vetted for their administrative, architectural and stability impacts, with applicants for change bound by those results.

Recommendation: Quick Look

The ISPCP believes that the "Quick Look" provision of the Staff Manager's report currently raises a number of concerns. In particular, the ISPCP would like to make the following suggestions:

• The "Quick Look" process needs to be explicitly spelled-out so that all parties have a common understanding of exactly what 'Quick Look' means.
• Any "Quick Look" process should give a full explanation of what role the gNSO plays in the "Quick Look" activity.
• The "Quick Look" process should have agreed and effective reporting mechanisms in the interest of transparency.
• In the event that the "Quick Look" process fails to accurately assess the impacts of a new service on the Internet, there must be an effective form of recourse for ICANN and the community.
• Some metric needs to be established that effectively and deterministically decides if a service proposal is eligible for the "Quick Look" procedure. This metric should be based on full community consultation.

As a constituency, we currently remained concerned about the "Quick Look" provisions unless these issues are covered.

Recommendation: Recourse and Determinism

Any decision made by the community as a whole must have a process for appeals. If a registry feels that a "service" has received an unfair hearing in the community and will have no impact on the stability and reliability of the Internet, there must be a mechanism to appeal those circumstances.

A registry should be able to count on an assessment of a proposed service in a delimited time with a specific, well-understood process (neither open-ended nor open for modification while under consideration).

Recommendation: Terms of Reference

The ISPCP understands that another constituency has proposed modifications to the Terms of Reference provided in December 2003.

At the current time, the ISPCP makes no comment on moving items from the "Out of Scope" list to the "In Scope" list. The ISPCP Constituency reserves the opportunity to comment on the Terms of Reference as the PDP is pursued further.

Conclusion

These comments currently represent the views of the ISPCP and are offered as an input into to on-going discussions. The editor of the comments draft is the ISPCP Constituency Secretariat,

Mark McFadden [ ispcp-activity@21st-century-texts.com ]

7.6.

7.7. A5: Registrars Constituency

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/

• Registrars constituency meeting in Carthage, Tunisia - Tuesday 28 Oct 2003
• Teleconference - 11 Dec 2003
• Following the teleconference a draft statement was submitted to the registrars mailing list on 17 Dec 2003
• A first draft of a constituency statement was submitted to the registrars mailing list on 9 Jan 2004
• A second draft of a constituency statement was submitted to the registrars mailing list on 16 Jan 2004

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

7.8. A6: Gtld registries constituency

Revised Draft

This Registry Constituency statement relates to the GNSO Policy Development Process (PDP) on a procedure for use by ICANN in considering requests made by registry operators or sponsors for consents or related amendments to the agreements these entities have with ICANN. In accordance with Section 7(d) (1) of the GNSO Policy Development Process, ICANN initiated a PDP to develop a predictable procedure to handle such requests. The GNSO Council voted to initiate the PDP subject to additional Terms of Reference (TOR). Both changes to the rights and obligations under the agreements between ICANN and the registries/sponsors under the agreements and non-contractual discussions between registries/sponsors and ICANN are explicitly "out-of scope" of the TOR. This statement does not address procedures relating to the adoption of consensus policies.

Each constituency has appointed a rapporteur to solicit constituency views and submit the constituency position in writing to the Council.

Introduction

This document provides a joint Position Statement by the Registry Constituency, including the operators of the unsponsored gTLDs as well as the sponsors of the three Sponsored TLDs about the development of this Procedure. It is intended for submission by the Registry Constituency rapporteur as the definitive position of the entire Registry Constituency.

Position Statement

As a Constituency, we welcome the appropriate steps by ICANN and the GNSO Council towards the development of a fair, predictable and timely procedure for ICANN to handle requests for authorizations, approvals or consents required by our contracts or related contractual amendments in which we are interested.

The implementation of a fair, predictable and timely procedure by ICANN to handle such requests is in the best interest of our Constituency. Such a procedure would reduce the uncertainty, substantially decrease the time and effort required for the review of proposed changes , and encourage both the unsponsored registries and the communities served by the sponsored registries to improve the gTLDs.

Although we believe it is important to develop a predictable procedure for contractual approvals and amendments, specific contractual changes (or changes in the relationship between the registries and ICANN) should not be considered as part of this Policy Development Process.

We present here certain concerns, which must be considered by the GNSO Council when developing the Procedure.

1. The procedure should be simple, transparent, and understandable by all stakeholders. We believe that the procedure should be a procedure for the ICANN staff to follow. Except in unusual circumstances, as determined by ICANN staff, the procedure should not involve other constituencies. We favor the use of "post-fact reporting" in cases where changes are of an administrative nature and their impact on the Internet community is limited. Any procedure should be in writing, published on ICANN's web site, and satisfy certain minimum requirements which will be detailed in a separate statement by this constituency.

2. The procedure should be cost-effective and timely. Both the Registry and ICANN will have to employ resources for a period of time to process a request. A procedure should be developed which minimizes the resources on both sides required to submit and review a request. The effort required for the procedure should be commensurate with the change requested.

3. The procedure should take into consideration the characteristics of the TLD in which the request is being made. One size does not fit all, and the same change in one TLD may have a completely different impact than the same change in another TLD. The procedure must take into account the nature and the size of a TLD when measuring the impact of the change.

4. The procedure should not impede development and innovation. If the previous concerns are addressed, then the procedure developed will be simple enough so that it will provide cost-efficient and timely confirmation of new processes for each TLD. Individual differences in the TLDs will be considered during early steps of the review process, and decisions will enable the Registries to develop and offer new services desired by the Internet community quickly and efficiently.

5. The procedure should recognize that the Sponsor represents the views of the sponsored community. It is important to differentiate between changes, which will affect users of a given TLD and changes which will affect the Internet community at large. One of the primary reasons to establish an sTLD is the desire of a specific community to manage its own domain according to its community-specific requirements. Sponsors obtained support of their respective communities and entered into agreements with ICANN to manage the TLD and to develop certain policies for and on behalf of their communities.

Sponsored TLDs have developed mechanisms to consider views of the sponsored community when developing its policies. It would be redundant, costly, and inappropriate to try to replicate the process at the ICANN level in situations where the sponsored community has expressed its views already and impact on Internet users at large is limited. Also, as outlined in the FAQs prepared by ICANN staff, certain aspects of the procedure, while not applicable to Sponsored TLDs at the ICANN level, may serve the sTLD communities well as a recommended practice to employ by the Sponsor when dealing with requests from the Registry Operators of sTLDs.

6. The procedure must not diminish the ability of registry operators to operate reliable, secure and stable service to the Internet community. Operation of the DNS is essential to the stability and security of the Internet, and many individuals and businesses, regardless of their size, rely on this operation for their livelihood. In the event of an unexpected situation that threatens the very nature of the service, or may cause serious discomfort to Internet users, Registry Operators must be able to act quickly and at their discretion to ensure continuity of the service while making reasonably and timely effort at keeping ICANN informed.

Conclusion

The Registry Constituency favors development of a simple, transparent and timely procedure for ICANN staff to handle any requested changes in the registry agreements.

We strongly believe that the implementation of such a procedure must take into account appropriate differences among TLDs, respect the role of the sponsored communities in sTLDs, appreciate the different levels of impact a change will have on different Internet constituencies, and favor development and innovation while maintaining the stability and security of the Domain Name System.

Introduction

In the present document, we will focus on substantive criteria to be used by ICANN in evaluating requests to review proposed changes to the architecture or operation of a gTLD registry. We are, however, not stating any opinion about the kinds of requests that ICANN currently has the authority (or obligation) to consider.

Procedural remarks

On the procedural side, we generally believe in accountable, transparent and objective processes that ensure that policy is applied in a neutral manner. In particular, the process should provide opportunities for all relevant parties (including GNSO constituencies and Advisory Committees) to get involved, and should, in particular, incorporate opportunities for meaningful and early public comment.

Substantive remarks

Burden of proof; principles. --- As a fundamental principle, what some call the "first law of the Internet" should be applied to proposed registry changes: Any privately beneficial activity should be allowed unless it is shown to be publicly detrimental; those who want to forbid an activity bear the burden of proving public harm.

In this scheme, bad ideas are not forbidden, but tried, and doomed to - maybe unexpected - failure. Whether a proposed change is "good" or "bad", or wanted by the Internet community, is not decided by some body a priori, but measured by market success - or failure: Where the community's interest is measurable in market terms, "regulatory" decisions can and should be avoided.

Conversely, where market feedback cannot accurately define the community's interest because of the absence of a competitive market, or because of the imposition of spillover costs, the community's interest must be defined in another way. For example, imagine that a registry imposes a change in behavior affecting all incumbent registrants. Those registrants would have to incur high switching costs in order to change to another TLD; that fact distorts the market's response to the registry change. For another example, imagine that a change in the DNS responses returned by the registry leads to a change of software behavior for users who have not changed their software or configuration. Since users, in their roles as consumers of DNS data, cannot control this change through their purchasing decisions, they cannot provide market feedback. And they are stuck with the changed software behavior, since reconfiguring or modifying their client software will likely be unacceptably costly to them.

Whether or not market feedback can provide an accurate barometer of the desirability of the proposed change should be a crucial test within the intial quick-look analysis of any proposed change that ICANN assesses. Where a proposed change fails this test, it should be the registry's burden to prove that no harm is caused by the proposed change.

Harm. --- We focus on three areas of significant harm that can be caused by changes to registry architecture or operations: Changes that affect the network's openness for innovation; changes that cause cost at the edges but benefits for the registry; and changes that enable registries to leverage their monopoly position into different markets where they can then compete unfairly.

One of the key elements in keeping the network open for innovation is the protocol neutrality of the naming and addressing framework: When new protocols are introduced, the DNS protocol in general needs no change - it is flexible enough to provide naming services for new protocols. The introduction of HTTP, for instance, required no change to the DNS.

It is extremely rare that the DNS has special provisions for specific protocols, the most prominent example being MX records which enable e-mail service for domain names which are not mapped to IP addresses themselves. These special provisions, though, are designed so they do not interfere with the behavior of the DNS protocol as used by other protocols; they can be introduced without causing harm to (in fact, without even being noticed by) Internet users at large, and they do not harm the Internet's openness.

Harm is caused, though, when registries introduce new services and change DNS behavior in a way which caters to the needs of some specific protocol, but makes the DNS less useful for other existing protocols, and for future innovation. As one committee member put it, the protocol-neutral, end-to-end net - of which the protocol-neutral DNS is a key ingredient - offers a neutral background for line drawing, oil painting, and collage. Sure a grid on the blank canvas would help those making mechanical drawings at the right scale, but it's just noise to the rest, who now need to paint an extra layer to cover it up.

A more general characteristic of harmful registry changes is to cause cost at the network's edge, while benefitting the registry, by , e.g., breaking existing expectations, specifications, or implementations. Effectively, such scenarios would mean that registries attempt to profit without bearing the actual cost of rolling out a change; the economics here are analogous to those of environmental pollution. Just as environmental pollution can be completely rational behavior (unless penalized by law or liability), it is rational for registries to attempt to profit, while shifting the cost to others. ICANN should strive to prevent this from happening.

Registries should not be allowed to leverage their monopoly position for wholesale domain name registrations into other markets. Such leverage can occur in many ways, and it is crucial that ICANN engage in thorough and thoughtful analysis of these questions.

To give just one example, a registry replacing error responses by pointers to a registry-operated service is using its monopoly to override end users' choice about how they want errors to be handled. Error handling, as implemented in client software, is no longer the object of competition with this change implemented. Additionally, the registry would invade the pay-per-click search engine market through a route available only to the registry. At t he same time, routes into that market which are based on end-user decisions (browser plugins, for instance), are disabled.

Also, registries should not be permitted to establish new monopolies where this can be avoided. Instead, preference should, whereever possible, be given to designs in which similar services can be provided by multiple parties; designs which permit market-based pricing of services should be preferred over designs that lead to monopoly pricing.