ICANN ICANN Email List Archives

[pdp-pcceg-feb06]


<<< Chronological Index >>>    <<< Thread Index >>>

[pdp-pcceg-feb06] Applicability of policy recommendations of PDP-Feb06

  • To: <pdp-pcceg-feb06@xxxxxxxxxxxxxx>
  • Subject: [pdp-pcceg-feb06] Applicability of policy recommendations of PDP-Feb06
  • From: "Bruce Tonkin" <Bruce.Tonkin@xxxxxxxxxxxxxxxxxx>
  • Date: Tue, 5 Dec 2006 01:59:58 +1100

Hello All,

I believe I have covered this in multiple verbal discussions during
Council meetings and I believe also physical PDP-Feb 06 meetings.   This
material was covered when the Council chose to initiate the PDP during a
meeting in Washington, so it is not new information.  Nor is there any
change resulting from the recent .com decision.   There has been
consistent community interest in discussing the topics in the PDP-Feb06
and seeing if any consensus might emerge.  In fact the recent
communication from Vint Cerf to the GNSO Council stated:

"http://www.gnso.icann.org/correspondence/biz-info-org-agreements-21nov0
6.pdf"

"The Board looks forward to the conclusion of the Council's work on the
very important PDPs now underway"


I will re-state in writing for clarity.


1.0 The ability for ICANN to enforce an ICANN policy on a registry is
limited by the terms of ICANN's contract with the registry.


2.0 The registry agreements constrain what new ICANN policies can be
applied to a registry operator under an existing agreement.   This has
been called the "picket fence".

Dan Halloran provided the following advice on this topic to the GNSO
Council as follows:

From:
http://www.gnso.icann.org/mailing-lists/archives/council/msg02918.html 

"Recent agreements have identified five main policy areas where a
Registry Operator has a contractual obligation to comply with new or
revised policies:

(1) issues for which uniform or coordinated resolution is reasonably
necessary to facilitate interoperability, Security and/or Stability of
the Internet or DNS;

(2) functional and performance specifications for the provision of
Registry Services;

(3) Security and Stability of the registry database for the TLD;

(4) registry policies reasonably necessary to implement Consensus
Policies relating to registry operations or registrars; or

(5) resolution of disputes regarding the registration of domain names
(as opposed to the use of such domain names).


This compares with the six main topics of PDP-Feb06:

1. Registry Agreement Renewal

2. Relationship between registry agreements and consensus policies

3. Policy for price controls for registry services

4. ICANN fees

5. Uses of registry data

6. Investments in development and infrastructure

The majority of the topics above seem to relate to the framework of the
registry agreement itself, rather than to the set of five topics areas
where a Registry Operator must comply with new or revised policies after
the signing of the agreement. The topics above would appear to be most
relevant in the development of a new framework registry agreement for
future negotiations."


3.0 In addition to the text on the picket fence, some registry
agreements also have additional limitations on the impacts of new
policies.

E.g from the .net agreement:

"In addition to the other limitations on Consensus Policies, they shall
not: 

(A)  prescribe or limit the price of Registry Services; 

(B)  modify the standards for the consideration of proposed Registry
Services, including the definitions of Security and Stability (set forth
below) and the standards applied by ICANN; 

(C)  for three years following the Effective Date, modify the procedure
for the consideration of proposed Registry Services; 

(D)  modify the terms or conditions for the renewal or termination of
this Agreement; "



4.0 Some of the registry agreements also have restrictions on how ICANN
can renew an agreement.

E.g from the .net agreement:

"Upon renewal, in the event that the terms of this Agreement are not
similar to the terms generally in effect in the Registry Agreements of
the 5 largest gTLDs (determined by the number of domain name
registrations under management at the time of renewal), renewal shall be
upon terms reasonably necessary to render the terms of this Agreement
similar to such terms in the Registry Agreements for those other gTLDs.
"



5.0  The effect of:

- picket fence

- additional restrictions regarding changes to pricing/renewal
provisions

- provisions relating to renewal of the existing agreements

means that any new policies approved by the ICANN Board in areas such as
renewals, pricing, and consensus policy limitations are unlikely to be
able to be applied to a registry operator with an agreement to operate
an existing gTLD.

Note how a specific policy recommendation would impact a specific
registry agreement would need to be looked at on a case-by-case basis by
the General Counsel's office as each agreement has different terms, so
these comments are intended to set expectations for the applicability of
a policy in this area.


If ICANN terminated an agreement for an existing gTLD, or a registry
operator chose not to renew their gTLD agreement with ICANN, then the
policies could apply to a new agreement that ICANN creates with a new
registry operator for that existing gTLD.




6.0 Note also that one of ICANN's core values is:

" Making decisions by applying documented policies neutrally and
objectively, with integrity and fairness.",  which would have an impact
on how ICANN could treat a new agreement for an existing gTLD with
respect to the existing agreements.   Note that some of the existing
agreements include a specific obligation for ICANN  that is consistent
with this core value:

From: http://www.icann.org/tlds/agreements/net/net-agreement-new.html

"Equitable Treatment. ICANN shall not apply standards, policies,
procedures or practices arbitrarily, unjustifiably, or inequitably and
shall not single out Registry Operator for disparate treatment unless
justified by substantial and reasonable cause. "


I hope this is now clear.

Regards,
Bruce Tonkin












(




<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy