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

["Anthony Harris" <harris@xxxxxxxxxxxxx>]

I am uneasy about the following:

> 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).
If this is to apply to sTLDs, both '.asia' and '.cat' could
scarcely be qualified as being "geography blinded", and
certainly pertain to specific regions. The same applies
to .eu (I know, this is called a ccTLD, but well...)

Regards

Tony Harris

----- Original Message ----- 
From: "Mawaki Chango" <ki_chango@xxxxxxxxx>
To: "Bruce Tonkin" <Bruce.Tonkin@xxxxxxxxxxxxxxxxxx>; 
<gtld-council@xxxxxxxxxxxxxx>
Sent: Saturday, June 03, 2006 12:30 PM
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.