ICANN ICANN Email List Archives

[gnso-rn-wg]


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

RE: [gnso-rn-wg] gTLD Reserved Names Chart

  • To: "'Tim Ruiz'" <tim@xxxxxxxxxxx>
  • Subject: RE: [gnso-rn-wg] gTLD Reserved Names Chart
  • From: "Ray Fassett" <ray@xxxxxxxxx>
  • Date: Thu, 3 May 2007 13:04:56 -0400

These are good questions, Tim.  Let me try to respond prior to our call.
First, I think it is important to appreciate that the reservation of gTLD
strings is a contractual condition and not a policy.  PDP 05 is a policy
setting process.  If the sub-group is to make a recommendation (in theory to
PDP 05) to create "new policy" that is to change the status quo for gTLD
reserved names, then there needs to be evidence to support its doing so
(strong support could work in lieu of empirical evidence).  Second, the
reservation of gTLD strings is an existing contractual condition, which is
different than your parallel examples of the IP community and ISP's (or
registrar names).  If an existing contractual condition is going to be
changed as a recommendation from the sub-group's work, then there is a
burden for which to do so (more on this below).  Conversely, if a new
reserved category is desired to be created (such as for IP or ISP interests
or registrar names), then there is a burden to achieve for which to do so
(for example, see Controversial Names category).  

 

The initial work of the gTLD reserved names category resulted in the need
for a 30 day extension for the reason that conflicting opinions resulted
from the initial work.  As the chair of this subgroup, I examined the
initial findings and took the approach of:  Can gTLD strings be unreserved
for registration? vs. should gTLD strings continue to be reserved from
registration?  From the initial work, including the conflicting opinions,
there appeared reasonably strong support to the idea that gTLD strings can
be unreserved as matter of contract.  There really has not been a dissenting
opinion to this notion.

 

Comments obtained from within the RyC members clearly favor the preservation
of this reserved names category.  The sub group must accept this as expert
advice, objectively while also examining the motivations for such advice.
Some individual members of the registrar constituency offered the same
opinion as RyC members, and for the same reasons i.e. potential user
confusion.  Is there evidence of user confusion?  I don't know of a study
that indicates that there is, just as there is not a study that indicates
that there is not.  Objectively, the burden falls on the latter, not the
former, because the reservation of gTLD names is an existing condition, not
one looking to be created or added new.  While opinions may arise that all
gTLD strings should simply be unreserved for new TLD's, the burden was not
achieved for this recommendation by the sub-group.  What I believe has been
achieved is that gTLD names can be unreserved.  Given this is true, we had
to look at the reason - or place - ICANN was taking to restrict - by
contract - the registration of gTLD strings.  Certainly a technical security
and stability issue would suffice.  Examining this question found that a
recent opinion by the RSTEP stated that there is not, in its view, a
security and stability issue to TLD.TLD.  Objectively then, why is ICANN in
the middle of this reserved names category as a contractual condition and,
more importantly, should ICANN continue to be for new TLD's?  Clearly
evidence indicates ICANN should not be.  With this said, ICANN Core Value 3
is applicable:   

 

To the extent feasible and appropriate, delegating coordination functions to
or recognizing the policy role of other responsible entities that reflect
the interests of affected parties.

 

My own examination of the findings led me to 2 clear, objective conclusions:
1) There is strong support that gTLD strings can be unreserved and 2) ICANN
should not be contractually binding itself as the party to require approval
from.  The recommendation accomplishes these 2 conclusions: 1) enables the
release of gTLD strings for registration as a matter of contract (which
today is not the case) and 2) enables release in a manner that does not
require ICANN's approval (as it does today).

 

While I have shared the above thinking with the 2 members of this sub-group
(Edmon Chung and Patrick Jones), we are still in discussion ourselves and
what is stated above is in my own words.  I am glad you asked the questions
as discussion and dialogue is what this is about.

 

Ray

 

  _____  

From: Tim Ruiz [mailto:tim@xxxxxxxxxxx] 
Sent: Thursday, May 03, 2007 11:29 AM
To: Ray Fassett
Cc: gnso-rn-wg@xxxxxxxxx
Subject: RE: [gnso-rn-wg] gTLD Reserved Names Chart

 

If this is going to be the recommendation, then I would like to add to that
the business names of then existing Accredited Registrars. And I am sure
that the IP community would then like to add the well known names of other
Internet services providers (search engines, ISPs, etc., etc.).

 

I cannot imagine a registry giving a competitor permission to register the
equivalent of its gTLD string at the second level. In fact, I think
investigation of antitrust and other anti-competitive laws and regulations
should be done before we consdier making such a recommendation.

 

What is the is actual evidence of potential harm to justify this
recommendation, or the existing policy regarding these reservations? What is
the justification to continue to expand the existing imbalance regarding the
registrations of such names? All this does is make an ever growing number of
valuable and useful generic strings unavailable to the general public, and
assumes bad intentions on the part of those who may like to use them.

 


Tim 






-------- Original Message --------
Subject: [gnso-rn-wg] gTLD Reserved Names Chart
From: "Ray Fassett" <ray@xxxxxxxxx>
Date: Wed, May 02, 2007 7:47 pm
To: <gnso-rn-wg@xxxxxxxxx>

Attached find the gTLD Reserved Names Chart outlining the sub group
recommendation for discussion on Thursday.

 

Ray Fassett



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

Privacy Policy | Terms of Service | Cookies Policy