ICANN ICANN Email List Archives


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

Concerns about the .name proposal regarding second level names

  • To: <gnr-proposal-comments@xxxxxxxxx>
  • Subject: Concerns about the .name proposal regarding second level names
  • From: "Marilyn Cade" <marilynscade@xxxxxxxxxxx>
  • Date: Mon, 20 Nov 2006 15:46:54 -0500

Regarding the .name Registry request for Limited Release of Initially
Reserved Two-Character Names


I ask that ICANN not approve the proposal by .name registry until there is
further discussion and consideration of the political and public policy
issues that are involved in the question of the use of two character
names/otherwise known as 'two letter names'. 


I have read the materials provided by .name registry and by ICANN, as well
as the clarification posted by the .name registry to ICANN regarding the
RSTEP process.  I believe that there are additional areas/questions that
deserve addressing. I will note that it is possible that all the questions
can be addressed with ease. However, there are questions that need to be
identified, and asked in a transparent way, and thoughtful consideration
given to the questions and the answers. 


I agree and support the referral to the RSTEP process to address possible
technical issues related to stability and security; however, ICANN has not
sufficiently explored in a transparent and visible way the issues associated
with the uses of two letter names that are often associated with country
code names.


ICANN should not be addressing the use of two letter names in a 'one off'
manner which in essence would be a return to the early days of the Internet.
As ICANN noted in the letter of 17 October 2006, two character names were
initially available in .com; .net and many ccTLDs; however, since 2001, two
character names have reserved in all gTLD registry agreements. ICANN's
letter acknowledges that there are technical issues raised in RFC 1535 that
have not been addressed. ICANN goes on to note that other registries and
sponsors are also interested. 


However, ICANN did not address clearly or even ask, in its posted
communications what the policy or political issues may be that need to be
addressed; such as whether it is suitable to address release of reserved
names on a registry by registry basis; the need to at least ask the question
about whether there needs to be a 'framework' that is consistent of whether
to release two character names in all gTLD registries versus a 'one off'
approach and what are the pros and cons of either approach; how released two
character names are then allocated; whether governments, via the GAC, may
have public policy concerns, or other concerns related to the release and
use of the two character names, as two letter names are used in the country
code strings, and whether in fact, there are consumer confusion issues
regarding the use of the two character names when they are similar to the
existing two letter names. 


Surely, ICANN has already recognized that there are both confusion issues
and public policy issues, since they started requiring the initial reserving
of the two character names in 2001. 


At this point in time, I not believe that the question of how .name's
proposed use will avoid confusion of users who expect two letter codes to be
associated with the standard abbreviations for country names has been
answered, although .name has stated in its response that it doesn't see that
possibility.  I take note that .name registry believes that there is a
significant market potential for .name by the limited release of the
initially reserved two character names. I am not in disagreement with the
registry's market interest, but I am concerned that the consumer confusion
and public policy questions exist, and need to be examined, and addressed. 


It may be that after further consideration, the benefits outweigh the
concerns. But examination is warranted.


It is very possible that there are simple answers to these questions, and
that .name registry may be treated differently than other registries who
have also reserved schedules for two character names; however, these
questions deserve to be asked, explored and answered, including the issue of
consistent treatment. It is most probable that governments, via the GAC, may
have concerns and wish to know more about the unreserving and allocation of
names that are typically, depending on their location, known as
abbreviations of country names, and used as country codes. 


This change is a contractual issue, and the GNSO Council has responsibility
for policies for generic top level names. Some areas are clearly in need of
policy, while others are suitable to staff level decisions. The issue of
reserved names is yet to be determined, but in the PDPDec05 PDP, it has been
raised as a topic that needs to be examined. At present, the draft
recommendation in PDPDec05 is Recommendation, and references the
existing name list. 


I urge ICANN to not approve the .name proposal at this time, but to identify
the additional questions that need to be asked, which include but are not
limited to, whether there should be a 'standard' approach across all
registries; whether there is a justification to treat .name registry
uniquely; whether .name's three step proposal is adequate to prevent user
confusion, if the proposal is approved; and importantly, whether this
proposed 'use'  of two character names, which are or may be confusingly
similar to existing country codes, may be released, and allocated, are
within the areas of public policy that the GAC members believe they should
provide advice on.


Fortunately, ICANN is meeting in Sao Paolo very shortly. It is very possible
that further responsive information from .name registry can assist in
responding to many of the questions. However, until they are addressed, I
recommend against approval of the .name registry request for limited release
of Initially Reserved Two Character Names. 


Respectfully submitted


Marilyn Cade

20 November 2006 


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

Privacy Policy | Terms of Service | Cookies Policy