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

[Mawaki Chango <ki_chango@xxxxxxxxx>]

You're right about definition relating to DNS vs ICANN, etc.
However, the need to have such definition arose while we were
discussing contracts, so we may need to have a two-fold
definition including: i) the technical-infrastructural aspect,
and ii) the political-institutional one.

I don't have time now to do this, but we may have to revisit how
all the so-called generic TLDs have been referred to, with
consistency, in ICANN's legal instruments (bylaws?, MoUs,
agreements, contracts, etc.). I imagine those who came up with
the 3-letter suffixes in 1984 and called them "generic," had
some idea in mind and I suspect it has been written somewhere...
has that idea/concept evolved (notably, through the legal
instruments) and how? 

E.g., I'm personally quite ignorant of the special conditions
with .mil, .edu and .gov, other than observing they're used in
only one country by some types of institutions. I don't know if
there are any conceptual/formal/legal/political grounds for that
usage, or if this is a "black box." In any case, as a policy
development body, if the GNSO ever attempts to define gTLD, it
would be good:
a) not to have an abridged and truncated definition that will be
useful only for one specific PDP, but a concept definition for
all our purposes;
b) to have it clarify what the different categories of gTLDs are
or may be, based on the current state of knowledge, and what is
predictable about them - namely, for the general user to know
(beyond the ccTLDs that are dealt with elsewhere) who have
access (registration) to what corner of the DNS and under what
general conditions.

My two cents

Mawaki

--- Ross Rader <ross@xxxxxxxxxx> wrote:

> I would like to see the definition of any TLD (g, cc, or
> other) framed
> up in terms of its relationship with the global DNS
> infrastructure, and
> not its relationship with ICANN. ICANN is a political
> construct, whereas
> a TLD, the root and the DNS are technical constructs.
> Furthermore, lets
> not forget that gTLD and ccTLD are arbitrarily defined subsets
> of TLDs.
> 
> Mawaki Chango wrote:
> > 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.
> >>
> >>
> > 
> 
> 
> Regards,
> 
> Regards,
> 
> -- 
> 
>                         -rr
> 
> 
> 
> 
> 
> 
> 
> 
>                  "Don't be too timid and squeamish about your
> actions.
>                                             All life is an
> experiment.
>                              The more experiments you make the
> better."
>                          - Ralph Waldo Emerson
> 
> 
> Contact Info:
> 
> Ross Rader
> Director, Research & Innovation
> Tucows Inc.
> t. 416.538.5492
> c. 416.828.8783
> 
> Get Started: http://start.tucows.com
> My Blogware: http://www.byte.org
>