[pdp-pcceg-feb06] Final working draft from Rapporteur for Group A/still taking edits from Group A members

["Marilyn Cade" <marilynscade@xxxxxxxxxxx>]

Dear colleuges, I have taken the recommendations, and the discussion and
tried to create a document that can be used for the discussion at the Task
Force level. Glen is preparing a short document that shows the members of
both Rapporteur Groups and their in person attendance at the meetings;
however, it is important to remember that the purpose of the Rapporteur
Groups was to advance work and put forward draft recommendations to finally
and further discuss at the Task Force level. The document pasted below is
drawn from the discussions [you can find transcripts of all the Group A
calls in the archieves], the materials provided by staff, and contributions
of members of the Rapporteur Group. 

Thanks to everyone, especially  the NCUC for a further elaborated updated
contribution of their positions. other members of the Group A who dedicated
their energy and brainpower to the effort, as well as the Rapporteur of
Group B and the chair of the TF who participated ex officioAnd thanks to
Glen, Liz, Dan, and Denise who provide ongoing support to the work of the
Rapporteurs. 

The document may receive further edits and clarification, or even additions
form the members of the Group A in the next 24 hours. 

 

If someone has an extensive addition that can't be accommodated or
integrated, I would propose to add it as a minority opinion and have it
presented at the full TF meeting at the appropriate time.

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

Final working draft document

Created October 26, 2006 

 

 

 

Policies for Contractual Conditions: 

Existing Top Level Domains 

Rapporteur Group A:  Working Materials

A.
Background..................................................................
...................................... 2

B. Term of Reference 1 - Registry Agreement
Renewal........................................ 4

C.  Term of Reference 2 - Relationship between registry agreements and
consensus policies       8

D. Term of Reference 5  --  Uses of registry
data.................................................. 10

 




 Rapporteur Group A used several documents as the basis for consideration,
including staff's initial document entitled Policies for Contractual
Conditions: Existing Top Level Domains Rapporteur Group A: Working
Materials; the table from Annex 3 to PDP Feb06 Issues Report; the draft
comparison of ICANN-registry agreements 20061009, the General Counsel's
letter to Bruce Tonkin, Chair, GNSO Council 27 September 2006. Annex A: GNSO
Policy Development Process is an additional resource to the Rapporteur Group
A, and was provided by the Rapporteur.  The Rapporteur group also used the
list of questions submitted to the TF and all expert materials provided by
the staff.

 

Background

 

1.       Group A is analyzing Terms of Reference 1, 2 and 5.  Group B is
analyzing Terms of Reference 3, 4 and 6.  

2.       There is some overlap of policy implications between the two
Rapporteur Groups. Each Rapporteur has served ex officio as member of the
other Rapporteur Group.

3.       The chair of the TF has served ex officio of the two Rapporteur
groups. 

4.       Transcripts have been provided for Rapporteur Group A.

5.       Expert Materials are found at GNSO working documents section at
http://gnso.icann.org/drafts/pdp-feb-06-expert-materials.pdf. Other relevant
documents provided by staff are part of the overall TF materials and are not
listed in this report by the Rapporteur Group. 

6.       The Rapporteur reviewed the expert materials, and members of the
Rapporteur Group undertook their own individual review. 

7.       Tuesday, October 24, 2006, was the final working conference call
meeting of the Rapporteur Group A. 

8.       Based on discussion of the draft recommendations, a straw poll, as
taken during the call, supported by discussions during the calls, formed the
basis for the report to the full Task Force, which was drafted by the
Rapporteur.  In most situations, choices are presented on the
recommendations.  In some cased, there was agreement on a recommendation. 

9.       The Rapporteur Group met and eliminated and 'fine tuned' some of
the options presented in earlier drafts during their final working call,
10/24/06. 

10.   The draft report was prepared by the Rapporteur. Any written
recommendations or minority reports received regarding this final working
document will be included in the final report to the full Task Force.  

11.   Note: a separate attachment prepared by the Secretariat documents
participation in the calls of the Group; it also identifies other members
who were following the work of the Rapporteur Group, but not able to join
the working calls. 

 





 




B. Term of Reference 1 - Registry Agreement Renewal


 

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

 

The majority of those who participated in the working effort agree that
there should be a policy guiding renewals and voted yes on the straw poll.
One participant abstained from the straw poll.

 

Recommendation : There should be a policy guiding renewal. 

 

 

 

Based on the recommendation for a policy, the participants in the Rapporteur
Group then discussed what the elements of that policy should be and
discussed the time frame for the renewal policy and the 'rights of the
registry' regarding renewal. In the discussion of the Rapporteur Group, no
other specific elements were identified. 

 

A question regarding other elements should be asked of the full TF, and
possibly included for the public comment period. 

         

         

Time Frame:  The participants then discussed several options for the time
frame for contract terms, including typical situations in adjacent markets;
there was Generally agreement that there should be a standard term, and that
the term should be 'commercially reasonable'. There was no definitive
agreement about what that term should be, but discussion included mention of
terms of 5-7 years; 10 years; and 10-20 years. The participants also
discussed the synergy with the PDP 05 recommendations. 

 

There was not clarity of whether the recommendations should be consistent
with the renewal terms of PDP 05, or whether there is justification for
having different terms for contracts awarded prior to the establishment of
policy for new gTLDs.  This topic needs further discussion. 

 

One of the participants referenced the .us contract which provides for a
clause for cancellation for 'convenience'. Other comments include staff
questions regarding what the typical terms are in adjacent markets.

 

Recommendation:

 

There should be a standard term for all gTLD registries that is a
"commercially reasonable" length. "Commercially reasonable: means ____. 

 

 

 

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

Renewal Expectancy: The discussion of the group examined distinctions
between renewal expectancy and presumptive renewal, with, or without rebid.
The group also discussed whether sponsored registries and non sponsored
registries should have different 'rights of renewal' and rejected that
concept.  There was also discussion of PDPDec05 4.4. This presently
references 'renewal expectancy'  and that definition is provided by the
rapporteur below from the draft and does not include a competitive rebid
process. For this reason, the Rapporteur has changed the term used in PDP06
Group A, for clarity. 

 

For example, an existing registry that has done an excellent could be given
XX point award that is applied to the overall rating of the registry
contract. Such actions are customary in government procurement bids.
Government procurement at the national and 'state' level in most countries
regularly hold competitive bid processes for services and systems that serve
government agencies, including highly secure networks that serve the US
Government. 

 

 

 

 

Definitions provided by the rapporteur and subject to edits by the members
of Group A: 

A 'reasonable renewal expectation' is not an automatic right of renewal, but
includes a competitive bid. However, a registry that has fulfilled the terms
of the registry contract with excellence should have a reasonable
expectation of renewal. The competitive bid would include adoption of any
new framework agreement, and any consensus policies in place, as well as an
agreement to adopt consensus policies within a reasonable time frame. 

 

Presumptive renewal: the agreement has a specified term of years, but there
is no competitive rebid. A contract would be renewed provided that the
license holder is not in material breach of the contract or has not been
found in repeated non-performance of the contract and provided that license
holder agrees to any new framework contract conditions that are reasonably
acceptable. Any new framework contract would take into account the Consensus
Policies in place at that time. [this definition is from PDP05 4.4. ] 

 

Automatic presumption of renewal for all registry agreements: there would be
a commercially reasonable term, with evaluation of contract breach, and if
no contract breach, the contract would be rewarded to the original operator.


 

The support of the group was spread across all three options below. Two
members supported an expectation of renewal, and one each supported the
other two definitions.

 

Rapporteur Notes: These definitions were developed by the Rapporteur from
discussion and notes and members of the Group A who offered comments are
invited to improve the definitions.  

 

Recommendation: there should be a reasonable expectation of renewal for all
registry agreements.  OR

Recommendation: there should be a renewal expectancy for all registry
agreements. OR

Recommendation: there should be a presumption of renewal for all registry
agreements




 

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

1b. 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.

There was reference to ICANN bylaw, Article 2, Section 3, which addressed
discriminatory treatment. In general, there was discussion of two options:
having standardized 'rights of renewal' for all registry agreements, and
having the option of treating registry agreements differently, based on some
other criteria, such as market dominance or market power. The Rapporteur
Group took note of the bylaw regarding discriminatory treatment [Article 2,
Section 3, which says '                       '. 

 

 

Using  the document* provided by Dan Halloran, the following summary
describes the present situation:  Presumptive Renewal exists for the
following categories of gTLDs:

 

*      Sponsored gTLDs :   Yes

*      Non sponsored gTLDs: It depends: .com had a form of presumptive
renewal that was created by contract negotiations in 2001. [the two other
versions of the .com agreement also have presumptive renewal]. .net
negotiated presumptive renewal in 2005. Other non sponsored gTLDs do not
have presumptive renewal - e.g. biz; .info;.name;.org; and .pro

 

*      There are proposed contracts for .biz; .info; and .org that would
create presumptive renewal. There is no visible effort to change the .name
and .pro agreements.  

:-.info and .biz contracts lapse in the fall of 2007; .org does not lapse
until 2009.

 

*Source: see Table from Annex 3 to PDP Feb 06 Issues Report




 

There was split support between the two options. Option 1 received support
from two participants and option 2 received support from 3. Thus, both are
presented in the report to the Task Force. 

 

Recommendation: 

1. The 'right of renewal' should be standardized for gTLD registry
agreements. OR

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

 

 

 

 

 

 

 


C.  Term of Reference 2 - Relationship between registry agreements and
consensus policies


2a. Examine whether consensus policy limitations in registry agreements are
appropriate and how these limitations should be determined.

 

Statement from Registry Constituency rep: consensus policy is not within
scope of GNSO, or this PDP. [Rep from R'y Constituency to edit this for
accuracy

 

The group participants discussed consensus policy limitations, the current
situation related to limitations of consensus policy. Initially, the Group A
had expected to see a second document that the Council had requested from
the Assistant General Counsel's office identifying which and how picket
fence elements were applied to the various contracts. Two documents prepared
by the Staff were helpful resources.  

 

The support of the group was split across three options, which are presented
below. Option 1 had one person supporting; 2 had three supporters, and 3 had
support from one person. 

 

Recommendation options: 

 


1. Consensus policies limitations are inappropriate. Consensus policies
should always apply to all gTLD registries. OR

 

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

3.The present limitations to Consensus policies are appropriate and should
continue. 

 

Summary from Rapporteur: 2 had support from three of the four participants.
1 and 3 had support from one participant each. 

 

 

2b. Examine whether the delegation of certain policy making responsibility
to sponsored TLD operators is appropriate, and if so, what if any changes
are needed.

 

The registry constituency representative expressed a reservation that any
discussion is not within scope of existing sponsored gTLD agreements, but
noted that in PDP 05, it is possible to discuss new agreements, new
obligations.[invitation to Reg'y rep to edit this statement if it is not
factually stated.]

 

Definition provided by the Rapporteur: 'sponsored gTLD operator" is assumed
to mean the holder of the string contract with ICANN and is not the 'back
end operator'.  The Rapporteur Group did not discuss the issues of whether
existing sponsored names are fully representative of the community it
serves. The topic of what is 'a sponsoring community' is presently a topic
of discussion within PDP-05  related to new gtld strings.

 

Today, certain policies are delegated to the sponsored registries. Staff
could be asked to asked to provide further information on these to the Task
Force, to support the final consideration and discussion of the Task Force. 

 

Recommendation: 

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

 

 

 


 


 


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


D. Term of Reference 5  --  Uses of registry data


 

Registry data is available to the registry as a consequence of registry
operation. Examples of registry data could include information on domain
name registrants, information in domain name records, and traffic data
associated with providing the DNS resolution services associated with the
registry.

 

Rapporteur's note: .com 25 May 2001 .com Registry Agreement Definitions, 7.
"Registry Data" means all registry Database data maintained in electronic
form in the Registry Database and shall include Zone File Data, all data
used to provide Registry Services submitted to registrars in elections form
and all other data used to provide Registry Services concerning particular
domain name registration or name servers maintained in electronic form in
the Registry Database. 

 

During the Rapporteur Group, it was proposed that this be the 'definition'
for registry data and acknowledged that registry data includes traffic data,
as referenced in the new agreements.  Traffic data is referenced in the new
agreements as described in for example, the .info;.org ;.biz proposed
agreements as, for example, .info agreement (f.). A paraphrase of that
section is:, the Registry operator can make commercial use of and collect
traffic data regarding names and non existent names for a variety of
purposes, including the sale of domain  name, but also for various
identification of concerns about security.  This section makes it clear that
the process of introduction of Registry Services shall not apply to traffic
data. It also provides that if traffic data is made available it must be on
non discriminatory terms. [Exact language can be found in the various
agreements]. 

 

Rapporteur NOTE:  The obligation to deposit all registry data into escrow is
assumed to continue and to apply to all registries and not be the subject of
this TOR.

  

After some discussion, which included raising topics such as what safeguards
exists when data is provided to third parties by the registries under 'non
discriminatory conditions', and further concerns about the change in the
role of the registry that seems contemplated in allowing the registry to
gather and use data about non registered domain names, possibly to seek to
assign a per name value on non registered names, the Rapporteur Group
members suggested that this area deserves further thought and examination
for its implications. However, there was strong support for a policy
regarding the use of registry data, which includes traffic data, for
purposes other than that for which it is collected.  The group supports
further discussion and work on this topic to determine what the elements of
such a policy would entail. 

 

Considerations presented, but not developed in sufficient depth included
ensuring that any data that is collected must be clearly defined in registry
agreements and in agreements between registrars and registries; clarifying
that WHOIS consensus policy applies to that part of registry data that is
specific to WHOIS; identifying whether certain data related to security and
stability of the Interne should also be made available to other parties, who
are affected or at risk, due to 'risks' that are identified from said data;
limiting the use of registry data, and traffic data in creating unique
pricing domain name by domain name, since that is not the purpose of the
registry operation. .

 

For both 5a and 5b, in general, there is support for the need for policy,
but acknowledgement that there is not yet enough detail discussion on these
two questions to present a more detailed recommendation. The NCUC has
proposed a separate Task Force to target this topic. 

 

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

 

Recommendation: 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. 

 

The development of what the elements should be should be discussed at the
Task Force level. 

 

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

Recommendation: 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. 

 

Further work is needed at the Task Force level.