1. Background 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.shtml 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 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 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 After the initiation of the policy development process, the terms of reference were published and public comments were sought on the issue. 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 cooperate 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. 3. Summary of Constituency Statements The constituency statements are archived at: http://www.gnso.icann.org/issues/registry-services/constituency-statements.shtml, 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 Intellectual Property Constituency The Internet Service Provider and Connectivity Provider
Constituency Non-Commercial User Constituency Registrars Constituency Gtld registries constituency 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:
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:
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.
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.
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.
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.
b. Third Party Expert Participation Description: some responses called for independent, third-party, expert analysis of new proposals for services.
c. Community Participation including GNSO Description: some responses called for clear processes involving gNSO participation in the review process.
d. Public Notice and Reporting Description: several responses called for explicit reporting and public notice requirements during the review and evaluation of new proposals.
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.
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.
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.
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: (a) Determine if approval is required A description of the steps in each process flow diagram is explained in more detail in the sections below. 4.1 Determine if Approval is Required
Step 1: Registry Operator prepares to make a change A Registry operator 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 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 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 has sought feedback from external parties, 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: ICANN Determine whether approval is required ICANN will assess whether approval is required under the agreement between ICANN and the registry operator. Step 5: Registry Operator decides whether to make the change A registry operator may make a business decision to go ahead and make a change, either as a result of determining itself that the change does not require approval, or after receiving advice from ICANN that ICANN does not need to approve the change. As stated in step 1 above, it is preferable in all cases where a change may affect external users, that the gtld registry operator discuss the change with ICANN first (on a confidential basis). Step 6: END A registry operator may make a business decision not to go ahead with a change. Step 7: Registry Operator decides whether to proceed with the approval process Upon being advised by ICANN that the change requires ICANN approval, the registry operator will make a decision as to whether to proceed with the review, or to not go ahead with the change. If the Registry Operator decides to proceed, ICANN will commence a quick look process. Alternatively if the change is significant and is likely to be controversial, a registry operator may instruct ICANN to immediately begin a full detailed public review. Step 8: Registry operator makes change With reference to step 5, above, if a registry operator decides to make a change, it should normally provide notice to its users (at least 30 days is preferred), and then make the change. Step 9: ICANN Community reviews impact and initiates the Reconsideration Process if the change should have been subject to the approval process If ICANN was not consulted prior to the registry operator making a change, and the change required approval under the agreement between ICANN and the registry operator, then ICANN staff may review any concerns raised by the ICANN community and request the registry operator to suspend the change until ICANN approval is provided. If ICANN staff believe that approval is not required, then the ICANN community may initiate the Reconsideration process as defined in 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, and this process is described in more detail in section 4.4. Step 10: Pursue processes outside of ICANN to reverse the change if necessary Where a change did not require approval under the agreement between ICANN and the registry operator, and the change impacted third parties, then those parties may pursue processes outside ICANN (e.g courts). One example where a third party may be impacted could be in the case of a patent infringement.
Step 1: Is the change likely to impact operational stability, reliability, security and global interoperability of the Internet? One of ICANN’s core values is to preserve and enhance the operational stability, reliability, security, and global interoperability of the Internet. In forming a view as to whether there is likely to be an impact, ICANN should consider the following points: Interoperability: The services provided by a gtld registry should maximise interoperability through use of industry standards. Generally this can be achieved by using Internet standards and consistency with the end-to-end Internet protocol principle, de facto industry standards, and open standards. The software required by users of the services should be available from multiple vendors (for example Internet browser software that uses the HTTP standard is available from multiple vendors). Stability: In general, changes to gtld services
should not impact applications currently using those services.
The end-users of gtld services, include registrars (which register
domain names on behalf of their customers using the registry-registrar
provisioning system), registrants (that use the domain ICANN staff should take advantage of outside expertise in the areas of operational stability, reliability, security and global interoperability of the Internet on a confidential basis during the initial review of a registry request. Step 2: Is the change likely to reduce the competition in the registration of domain names One of ICANN’s core values is promoting competition in the registration of domain names where practicable and beneficial in the public interest. In forming a view as to whether a change to a gtld service, or a new service is likely to impact on competition, 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. Where a new service is introduced, end-users should be able to choose whether to use that new service rather than have it imposed on them. This allows the market to operate to determine which services are useful and which are not. This is consistent with the ICANN core value that where feasible and appropriate, ICANN should depend on market mechanisms to promote and sustain a competitive environment. When considering competition in the registration of domain names, ICANN should also consider whether the change to an existing service or new service is likely to significantly impact end-users rights under significant multi-national treaties in areas such as privacy, trademarks, copyright, and patents. ICANN staff should take advantage of outside expertise in the area of international competition law on a confidential basis during the initial review of a registry request. Step 3: ICANN provides draft report to Registry Operator After ICANN has completed its quick review of the proposed change, it will provide a draft of its preliminary report to the gtld registry operator for comment. Step 4: Registry Operator comment period After the gtld registry operator receives the report from ICANN it will be given a period of time to comment before ICANN finalizes its preliminary report. The gtld registry operator may correct factual errors or provide more information to ICANN to assist the finalisation of the preliminary report. Step 5: ICANN provides preliminary report to Registry Operator ICANN will provide its preliminary report to the registry operator. Step 6: Is a detailed review required The preliminary report will either recommend that the ICANN Board approve the change, or ICANN may recommend a more detailed review if ICANN has concerns that the change is likely to impact operational stability, reliability, security and global interoperability of the Internet, or the change is likely to reduce the competition in the registration of domain names. At this stage the preliminary report is still confidential. Step 7: Registry Operator decides whether to proceed or modify the proposal If the preliminary report recommends that ICANN use the detailed review process, the gtlf registry operator may decide not to proceed with the change. In this case the preliminary report remains commercial in confidence. Alternatively the gtld registry operator may decide to change the proposal to address ICANN’s concerns. In this case the quick look process would start again. Step 8: Registry Operator decides whether to proceed If the preliminary report recommends that the ICANN Board approve the change, then the registry operator may still decide not to proceed with the change. In the case the preliminary report remains commercial in confidence. Step 9: END The registry operator has decided not to proceed with the change and the preliminary report remains commercial in confidence. Step 10: Registry Operator announces intent to make the change and ICANN staff publish recommendation to the ICANN Board at least 45 days prior to the next ICANN Board meeting Once the gtld registry operator publicly announces its intent to make the change, then ICANN will publish its recommendation to the ICANN Board on whether to approve the change. The timing of this announcement would be subject to a business decision by the registry operator and may occur sometime after the ICANN staff have completed the quick look process. At this point the preliminary report becomes a public document and is called the ICANN staff report. This publication should occur at least 45 days prior to the next ICANN Board meeting. This allows amply time for public analysis and comment, and allows the ICANN Board directors time to review the recommendation. Step 11: ICANN Board 30 day public comment period After the staff report is published, there will be a 30 day public comment period. This will be an opportunity for members of the ICANN community to raise any objections. If a member of the ICANN community has an objection on the basis that the change is likely to impact operational stability, reliability, security and global interoperability of the Internet, or the change is likely to reduce the competition in the registration of domain names, the member of the ICANN community should provide details and if possible evidence to substantiate the objection. At the end of the 30 day public comment period, the ICANN staff will summarise the comments for the ICANN Board to consider. Step 12: ICANN Board decides whether to grant approval The ICANN Board will make its decision based on the ICANN staff report and the public comments received prior to the Board meeting. Step 13: Registry Operator decides whether to invoke the Reconsideration Process If the ICANN Board does not approve the change requested by the gtld registry operator, then the operator may initiate the Reconsideration process as defined in 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. This process is described in more detail in section 4.4. Information on past reconsideration processes is available: http://www.icann.org/committees/reconsideration Step 14: gtld Registry operator accepts ICANN Board decision Step 15: Registry operator makes changes After the ICANN Board has approved the change, the registry operator may make the change. Step 16: ICANN community decides whether to invoke the Reconsideration Process A member of the ICANN community may invoke the Reconsideration process as described in step 13 above.
Step 1: ICANN publish preliminary public notice of detailed review identifying the issues to be explored and questions for which it seeks answers This process is invoked at the choice of the registry operator, either after receiving advice from ICANN in the preliminary report as part of the quick look process, or the registry operator may decide to invoke the detailed review without the quick look process to save time. The detailed review is a full public review, with extensive ICANN community input. This review would be appropriate for a significant change in the operation of the registry-registrar provisioning systems, the WHOIS service, or the DNS nameservice. ICANN will publish a public notice with information supplied
by the registry operator on the change, any preliminary report
produced so far, and any issues identified that may impact operational
stability, reliability, security and global interoperability of
the Internet, or may reduce the competition in the Step 2: 7 day public comment period There will be a short 7 day public comment period, where members of the ICANN community may suggest additional issues to be considered, or seek further clarification from ICANN or the gtld registry operator on the proposed change. Step 3: ICANN publish final public notice of detailed review Taking into account any public comments, ICANN will finalise the public notice of the detailed review process for the proposed change. Step 4: Managed 30 day public comment period using the ICANN Manager of Public Participation A 30 day public comment period will commence. The ICANN Manager of Public Participation (as referenced in the ICANN Bylaws: http://www.icann.org/general/bylaws.htm#V, article III, section 3) will manage the process. Step 5: Facilitate briefings of major stakeholders most likely to be affected by the change by registry operator and independent experts ICANN will facilitate briefings by the gtld registry operator and independent experts of major stakeholders (e.g the constituencies of the GNSO) that may be affected by the change. These briefings may take the form of teleconferences and/or physical meetings. ICANN may appoint independent experts to assist with the detailed review. These may be in the areas of international competition law, or registry technical systems. Step 6: Collect constituency impact statements ICANN staff will request and collect impact statements from each constituency. Step 7: Seek statements from the Advisory Committees – such as SSAC and ALAC Seek advice from the Advisory Committees – such as the security and stability advisory committee and the at-large advisory committee. Step 8: ICANN provide a draft report for registry operator ICANN will consolidate all the public input and advice from advisory committees and independent outside experts, and make a recommendation to the ICANN Board on the same basis as the quick look process in a draft report. See steps 1 and 2 of the quick look process. To recommend approval, ICANN will need to be satisfied that no issues with the change have been raised by the ICANN community that are likely to impact operational stability, reliability, security and global interoperability of the Internet, or likely to reduce the competition in the registration of domain names. The draft report will be provided to the registry operator for comment. Step 9: Registry operator comment period The gtld registry operator will have the opportunity to correct any factual inaccuracies in the draft report, and also have the opportunity to address any issues that have been raised. Step 10: ICANN decide whether any changes to proposal made by registry operator to address any issues identified should be subject to further full review If the gtld registry operator makes changes to its proposal to address concerns raised by the community, ICNAN will decide whether the changes address the concerns raised, or if this is uncertain, may agree with the registry operator to undertake further public review. Step 11: ICANN staff publish recommendation to the ICANN Board at least 45 days prior to the next ICANN Board meeting After receiving comments from the registry operator, ICANN will publish its recommendation to the ICANN Board. This publication should occur at least 45 days prior to the next ICANN Board meeting. This allows amply time for public analysis and comment, and allows the ICANN Board directors time to review the recommendation. Step 12: ICANN Board 30 day public comment period After the staff report is published, there will be a 30 day public comment period. This will be an opportunity for members of the ICANN community to raise any objections. If a member of the ICANN community has an objection on the basis that the change is likely to impact operational stability, reliability, security and global interoperability of the Internet, or the change is likely to reduce the competition in the registration of domain names, the member of the ICANN community should provide details and if possible evidence to substantiate the objection. At the end of the 30 day public comment period, the ICANN staff will summarise the comments for the ICANN Board to consider. Step 13: ICANN publish final recommendations to the ICANN Board At the end of the 30 day public comment period, the ICANN staff will summarise the public comments and incorporate them into a final report for the consideration of the ICANN Board. Step 14: ICANN Board decides whether to grant approval The ICANN Board will make its decision based on the ICANN staff report and the public comments received prior to the Board meeting. Step 15: Registry operator makes changes After the ICANN Board has approved the change, the registry operator may make the change. Step 16: ICANN community decides whether to invoke the Reconsideration Process A member of the ICANN community may initiate the Reconsideration process as defined in 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. This process is described in more detail in section 4.3. Information on past reconsideration processes is available: http://www.icann.org/committees/reconsideration Step 17: Registry Operator decides whether to invoke the Reconsideration Process If the ICANN Board does not approve the change requested by the gtld registry operator, then the operator may initiate the Reconsideration process as defined in 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. This process is described in more detail in section 4.3. Information on past reconsideration processes is available: http://www.icann.org/committees/reconsideration
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:
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:
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:
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:
If the Reconsideration Committee requires additional information, it may elect to conduct a meeting with the party seeking Reconsideration by telephone, email 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. 4.5 Independent Review Process
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 ben 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:
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. 5. Analysis of Impact of the Recommended Policy on Each Constituency A response from each constituency is required here.
Appendix A (Constituency Statements) 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 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 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. 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 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 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. 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 timeline1 will be followed
- 30 day fast track, or 90 day 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 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 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 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 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. 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 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:
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] This registrar constituency statement relates to the GNSO Policy Development Process on a Procedure for use by ICANN in considering requests for consent and related contractual amendments to allow changes in the architecture or operation of a gTLD registry, in accordance with Section 7(d) (1) of the GNSO Policy Development Process. (1) A vote on this statement was held on <insert date>, with the following result <insert results>. (2) The registrar constituency carried out discussions on the topic via its public mailing list at: http://gnso.icann.org/mailing-lists/archives/registrars/ and via the following meetings or teleconferences:
(3) Analysis of how the registrars constituency is affected by the issue Changes in the architecture or operation of a gTLD registry can affect members of the registrars constituency in the following ways:
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 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:
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 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 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 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. 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. Appendix B (At Large Advisory Committee Statement) 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 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 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. Comments concerning the layout, construction and functionality of this site should be sent to webmaster@icann.org. (c) 2004 The Internet Corporation for Assigned Names and Numbers All rights reserved. |
