ICANN ICANN Email List Archives

[At-Large Advisory Committee]


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

[alac] FW: [gtld-council] Outcomes of the Brussels meeting on policies for contractual conditions

  • To: ALAC <alac@xxxxxxxxx>
  • Subject: [alac] FW: [gtld-council] Outcomes of the Brussels meeting on policies for contractual conditions
  • From: Bret Fausett <bfausett@xxxxxxxxxxxxxxxx>
  • Date: Thu, 18 May 2006 08:06:25 -0700


-----Original Message-----
From: "Bruce Tonkin" <Bruce.Tonkin@xxxxxxxxxxxxxxxxxx>
To: gtld-council@xxxxxxxxxxxxxx
Sent: 5/18/06 4:21 AM
Subject: [gtld-council] Outcomes of the Brussels meeting on policies for 
contractual conditions


Hello All,

The following were areas of agreement amongst the participants in the
Brussels meeting for policy guidelines that relate to contractual
conditions.   These will be incorporated into an initial report.  The
intent will also be to include a "model" or "reference" agreement that
complies with these guidelines to assist in providing a practical
example of how the guidelines may be applied.


Use "gTLD licence holder" instead of "Registry Operator" as this has a
range of meanings.

"gTLD" = "a generic TLD that has a contract with ICANN, includes but is
not limited to the current sponsored and unsponsored TLDs"


1.      There should be a frame agreement to provide some level of
consistency (e.g as for the registrars accreditation agreement), with
the ability for staff to have delegated authority to approve.

2.      Any material alterations to the frame agreement, subject to
public comments before approval by the ICANN Board.


3. The contract should strike the right balance between ensuring
certainty for market players and preserving flexibility of ICANN to
accommodate the rapidly changing market, technological and policy
conditions.

4. The initial term of commercially reasonable length (e.g default 10
years, although may be changed on a case-by-case basis).


5. There should be a renewal expectancy.     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 the 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.

6. There should be an ability to terminate the contract if the gtld
licence holder has  been found in repeated non-performance of the
contract.

7. During the term of the agreement, the registry must comply with new
or changed consensus policies to one or more of the following areas:
-       (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 (as defined in Section 3.1(d)(iii) below); 

-       (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). 

8. Any deviation from consensus policies should be explicitly stated and
justified in the agreement


9. Where a registry provides IDNs, the contract should require that the
registry adhere to IDN standards, and ICANN guidelines for IDNs.

10. Initially rely on the appropriate external competition/anti-trust
Government authorities to ensure compliance with laws relating to market
power or pricing power.   This can be reviewed after initial term.

11. ICANN should take a consistent approach with respect to registry
fees - taking into account differences in regional, economic and
business models

13. Use of Personal Data: limit it to the purpose for which it is
collected, and define the extent to which it is made available to third
parties.


Further work required to identify whether to address other forms of
registry data, such as traffic data, before any policy recommendation in
this area can be made.






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