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

["Marilyn Cade" <marilynscade@xxxxxxxxxxx>]

Thanks, Mawaki.

Excellent points. However, we also need to be cautious about the term
"global". All TLDS resolve globally, and that is part of the end to end
principle and commitment of ICANN. We had a debate something like this very
early on at ICANN because there was a view that cc's were national only in
scope, and of course, while they have national characteristics, they resolve
globally.

It occurs to me that this definition will need vetting with the ccNSO/cc
fuller community. 


Marilyn Cade

-----Original Message-----
From: owner-gtld-council@xxxxxxxxxxxxxx
[mailto:owner-gtld-council@xxxxxxxxxxxxxx] On Behalf Of Mawaki Chango
Sent: Saturday, June 03, 2006 11:31 AM
To: Bruce Tonkin; gtld-council@xxxxxxxxxxxxxx
Subject: Re: [gtld-council] Outcomes of the Brussels meeting on policies for
contractual conditions

Hello Bruce & TF,

This is a contribution/reply to an old email... from Brussels.
I'd like to suggest the following definition for gTLD.

gTLD = a generic TLD is a top or first level Internet domain
name that is unique, global in scope and defined through an
exclusive contract with ICANN; it includes but is not limited to
the current sponsored and unsponsored TLDs.

You (esp. techies and policy staff; pls no lawyers ;)) may want
to confirm if "unique" and "exclusive contract" are Ok, as I see
them, but I'd like to insist having "global in scope" or
something like that (to mean they're geography-blinded, don't
pertain to any specific region). Because in my interactions, I
have come to realize that (a) signicant (number of) people in
the US seem to think gTLDs are american TLDs and the rest of the
world should be content with ccTLDs only. No offence... just
clarity.

Best,
Mawaki

--- Bruce Tonkin <Bruce.Tonkin@xxxxxxxxxxxxxxxxxx> wrote:

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