[pdp-pcceg-feb06] gTLD Registries Constituency Response to Straw Poll

["Neuman, Jeff" <Jeff.Neuman@xxxxxxxxxx>]

All,

 

Please find enclosed the response from the gTLD Registries constituency
to the straw poll for the Feb '06 PDP on contractual conditions for
existing registries.

 

++++++++++++++++++++++++++++++

 

The gTLD Registries Constituency (RyC) hereby provides its response to
the PDP Feb 06 Straw Poll Results on Draft Policy Recommendations.  As
stated on numerous occasions both orally during task force calls, as
well as in writing in previous RyC statements, the RyC believes that
most, if not all, of these recommendations are beyond the scope of the
Policy Development Process as documented in the ICANN Bylaws and the
gTLD Registry Agreements entered into by ICANN and the gTLD Registry
Operators. 

 

These responses have been thoroughly vetted by the entire gTLD Registry
Constituency on the constituency mailing list, a number of conference
calls, and at the face-to-face meeting in Sao Paulo, Brazil. 

 

  

 

TERM OF REFERENCE 1

 

ToR 1a. Registry agreement renewal

---------------------------------

Examine whether or not there should be a policy guiding renewal, and if
so, what the elements of that policy should be. 

 

Policy Recommendation A: There should be a policy guiding renewal. 

 

RyC: No.  There should not be a GNSO policy guiding renewal.  Provisions
regarding renewal are contractual conditions outside the scope of the
GNSO.  

 

Policy Recommendation B:  There should be a standard term for all gTLD
registries that is a "commercially reasonable length." 

 

RyC:  Subject to A above, the RyC believes all gTLD Registry agreements
should be of a commercially reasonable length.  We believe it is beyond
the expertise of the task force, however, to determine what would
constitute a "commercially reasonable" length.  That said, a good
starting point would be to look at the existing agreements.

 

Policy Recommendation C:  There should be a reasonable expectation of
renewal for all registry agreements.  

 

OR

 

Policy Recommendation D: There should be a renewal expectancy for all
registry agreements. 

 

OR

 

Policy Recommendation E: There should be a presumption of renewal for
all registry agreements

 

RyC:  E. As stated above, all RyC agreements should contain a
presumption of renewal as is currently documented in the .aero, .asia,
.biz, .cat, .com, .coop, .info, .jobs, .mobi, .museum, .net, .org, .tel
and .travel agreements.

 

 

 

 

1b. Registry agreement renewal standardization

----------------------------------------------

Recognizing that not all existing registry agreements share the same
Rights of Renewal, use the findings from above to determine whether or
not these conditions should be standardized across all future
agreements. 

 

Policy Recommendation F:  The 'right of renewal' should be standardized
for all gTLD registry agreements.

 

OR

 

Policy Recommendation G: The 'right of renewal' should be standardized
for gTLD registry agreements except when there is an exceptional
situation, such as a

situation of market dominance or market power.  

 

RyC: ABSTAIN.  The RyC believed that the report provided insufficient
information on policy recommendation G to make its decision.  In
addition, the RyC does not believe it is appropriate to engage in
discussions on market dominance or power.

 

 

TERM OF REFERENCE 2

Relationship between registry agreements and consensus policies

 

2.a

 

Policy Recommendation H:  Consensus policies limitations are
inappropriate. 

 

OR

 

Policy Recommendation I: Consensus policies should always apply to all
gTLD registries.

 

OR

 

Policy Recommendation J: Consensus policies should always be applied to
all gTLD registries.  On an individual basis, during the contract
negotiation, a registry

could present a situational analysis and justification, which should be
posted for public comment before acceptance/inclusion in the contract,
for an exception/or modification from a particular consensus policy, due
to unique circumstances of how a particular policy would affect that
registry. Such an exception will not create

any prejudice for extension to any other gTLD registry. 

 

OR

 

Policy Recommendation K: The present limitations to Consensus policies
are appropriate and should continue.

 

RyC: K.

 

 

2b.

 

Policy Recommendation L:  Certain policy making responsibility should be
delegated to the sponsored gTLD operators, but variations can be made,
based on characteristics of the sponsoring community. Variations should
be discussed/disclosed in charter for public comment. Examples of policy
making responsibility to be delegated to the sponsored gTLD operators
include but may not be limited to:  

 

-      Charter and scope of 'sponsored community'

-      Eligibility to be in the 'sponsored category' 

-      Eligibility for a particular name

-      The concept of a conflicts/dispute process as a service to the
sponsored community

 

RyC: YES

 

 

TERM OF REFERENCE 3

Policy for price controls for registry services

 

 

RyC: WE HAVE INTENTIONALLY OMITTED FROM THE RYC RESPONSE ANY REFERENCES
TO THIS TERM OF REFERENCE.  WE BELIEVE THAT NOT ONLY IS THIS POLICY
"RECOMMENDATION" OUT OF SCOPE FOR THIS PDP, BUT WE BELIEVE IT RAISES
SUBSTANTIAL ANTITRUST CONCERNS.  THE RYC SPECIFICALLY DID NOT (AND WILL
NOT) ENGAGE IN ANY DISCUSSION ON THIS TOPIC.

 

 

TERM OF REFERENCE 4

ICANN fees

 

4a. Examine whether or not there should be a policy guiding registry
fees to ICANN, and if so, what the elements of that policy should be.

 

 

Policy Recommendation O:  In order to improve ICANN accountability and
effective business planning by registries, ICANN staff should
immediately implement a

system of ICANN fees from registries that avoids individual negotiations
of ICANN fees and provides consistency unless there is established
justification for disparate treatment. 

 

RyC: ABSTAIN.  We support the notion of creating more transparency and
accountability in the process of determining the fees for ICANN, but we
believe that there is no formula that could apply to all TLDs
recognizing that each TLD has its own business model.  However, the RyC
was split on this recommendation. Certain registries expressed the view
that no gTLD registry operator should be held hostage by ICANN on ICANN
fees and that they had little bargaining power to negotiate ICANN Fees. 

 

4b. Determine how ICANN's public budgeting process should relate to the
negotiation of ICANN fees. 

 

Policy Recommendation P:  The ICANN Board should establish a Task Force
or Advisory Committee to examine budgeting issues, including the manner
and allocation of

revenue collection, budget oversight, and budget approval processes.
This group should solicit and review public comments on the issues.

 

RC: No.  The RyC supports existing mechanisms (rather than the creation
of a new Task Force or Advisory Committee) to look at these issues
provided that there is more transparency into the process.

 

TERM OF REFERENCE 5

Uses of registry data

 

5a Examine whether or not there should be a policy regarding the use of
registry data for purposes other than for which it was collected, and if
so, what the elements of that policy should be. 

 

Policy Recommendation Q:  There should be a policy regarding the use of
registry data [which includes traffic data] for purposes other than that
for which it was

collected. 

 

RC: No.  The RyC believes that more work needs to be done on clarifying
the issues related to "registry data".  More specifically, the RyC was
unclear on the definitions of "Registry Data", "Traffic Data" and the
phrase "for purposes other than that for which it was collected."
Without further definition of these concepts, which are not simplistic
ones, we cannot support this recommendation.

 

5b. Determine whether any policy is necessary to ensure
non-discriminatory access to registry data that is made available to
third parties. 

 

Policy Recommendation R:   There should be a policy to ensure
non-discriminatory access to registry data that is made available, but
that policy should include

safeguards on protection against misuse of the data. 

 

Agreed by all the TF members that further work is needed at the Task
Force level. 

 

RyC: No.  For the same reasons cited for Q above, we do not believe
enough work has been done to support this recommendation.  In addition,
we do not necessarily believe that this Task Force is the appropriate
body to do more work on this issue.

 

 

TERM OF REFERENCE 6

Investment in development and infrastructure

 

6a. Examine whether or not there should be a policy guiding investments
in development and infrastructure, and if so, what the elements of that
policy should be.  

 

Policy Recommendation S: 

There should not be a policy guiding investments in development and
infrastructure. ICANN should, however, establish baseline requirements
for the security and stability of the registries and anything above that
would be negotiated on a case-by-case basis, if necessary. Such a
baseline requirements should be recommended to the

Board by the Security and Stability Advisory Committee ("SSAC") after
consultation with the gTLD registry operators. In determining these
recommendations, the SSAC also should solicit and consider public
comments.

 

Notes: Revised text developed by Jeff Neuman and Jon Nevett

 

RyC: YES.  The RyC supports the recommendation but recognizes that the
SSAC may not be the correct committee to do this work.  The RyC would
support a separate Board Committee that has the appropriate expertise to
examine this issue with the gTLD Registry Operators.

 

 

 

Jeffrey J. Neuman, Esq. 
Sr. Director, Law, Advanced Services  & Business Development 

NeuStar, Inc. 
Loudoun Tech Center 
46000 Center Oak Plaza 
Sterling, VA 20166 
p: (571) 434-5772 
f: (571) 434-5735 
e-mail: Jeff.Neuman@xxxxxxxxxx <mailto:Jeff.Neuman@xxxxxxxxxx>  

 

PRIVILEGE AND CONFIDENTIALITY NOTICE:  The information contained in this
e-mail communication and any attached documentation may be privileged,
confidential or otherwise protected from disclosure and is intended only
for the use of the designated recipient(s).  If the reader or recipient
of this communication is not the intended recipient, or an employee or
agent of the intended recipient who is responsible for delivering it to
the intended recipient, you are hereby notified that any review,
dissemination, distribution, copying or other use of this communication
is strictly prohibited.  If you have received this communication in
error, please immediately notify us by return e-mail and promptly delete
the original electronic e-mail communication and any attached
documentation.  Receipt by anyone other than the intended recipient is
not a waiver of any attorney-client or work-product privilege.