Hello All, Attached is the registry constituency statement as a word document, and below is the text equivalent. Regards, Bruce REVISED DRAFT 2 March 04 Registry Constituency Statement 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) (http://gnso.icann.org/issues/ registry-services/tor-revised.shtml). 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.