[council] Registry constituency statement

[Bruce Tonkin]

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. 
	
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gtldregcon.statement.doc
Type: application/msword
Size: 49664 bytes
Desc: gtldregcon.statement.doc
URL: <http://mm.icann.org/pipermail/council/attachments/20040303/8ecdf914/gtldregcon.statement.doc>