A stable, appropriate and limited release of two-letter names uniquely for .name

["Hakon Haugnes" <hakon@xxxxxxxxxxxx>]

Dear Marilyn,

Thank you for your comment in the forum, let me address the questions you
have. 


First, you ask whether the .name proposal for a limited release of
two-letter names is appropriately handled by RSTEP. 

As know you know, RSTEP is a consensus policy
(http://www.icann.org/registries/rsep/rsep.html) and was designed by ICANN
in the widest sense, including the GNSO, to provide a fair, inclusive,
transparent and timely process by which proposals like ours can be evaluated
objectively by a professional team. RSTEP is a product of consensus within
ICANN and a sufficient process for handling the .name proposal for limited
release of the two-letter names.


Second, you ask whether the .name proposal should be considered in a wider
TLD context. 

We believe that this is not relevant to the .name proposal, but also that it
is evident that there is a very specific purpose and structure to the
proposed .name release that can simply not be extrapolated to another gTLD.
We believe it is implicit in the RSTEP process to take into account
appropriate differences among TLDs. Firstly, that the second level will not
actually be released at all, only as a carrier for third level registrations
of personal names, like yin(at)li.name, which is a unique feature of .name in
the gTLD space, and secondly, that .name is the gTLD intended for personal
names. Two-letter personal names are common worldwide, but in particular in
Asia, where the blocking of two-letter names has a disproportionate effect.
This is a .name specific proposal with a clear and stated purpose for names,
which is suited for the .name gTLD structure and intent. 


Third, you ask about allocation of the two-character names. 

The otherwise common allocation issue does not arise with the .name proposed
release of two-letter names, because the registrations are made on the third
level only. The second level itself, the scarce resource, is not released
and cannot be used by any Registrant. Therefore there is no "landrush"
allocation issue and first-come, first-served registrations as third level
domains (and email addresses) is a fair, stable, well understood and
perfectly suited allocation method.


Fourth, you raise a question about potential confusion.

We believe there is no real risk of confusion between a personal name
registration as an email address or a third level domain on the .name TLD,
and a domain name registration on a country code. This is addressed in our
proposal, and we have communicated with ccTLD managers on the issue as well
as the ISO agency, as contemplated by our Appendix K, which was drafted in
2001. Based on the feedback received from the outreach, we believe there is
no general fear of confusion, or risk of confusion, and second, because of
the unique nature of .name, for individuals and personal names, and the
release on the third level only, there can be no real confusion between a
personal name registration e.g. yin(at)xi.name and a country code domain e.g.
business.xi. Thus, as said, we believe that the proposed two-letter release
is .name specific, and has no "public policy concerns" and implications
outside of .name. 


Fifth, you refer to RFC1535. 

It is important to understand the scope of this RFC. RFC1535 is not specific
to two-character names (it affects any domain length) and describes _bad_
resolver behaviour that was corrected in RFC1536. There are already massive
TLDs where this would be a serious issue if RFC1535 were relevant. There are
already domains like li.com, li.net, and name.com, name.de, and co.uk,
me.uk, co.jp, etc, already active on the Internet. The issue has never
seriously been discussed in the GNSO, CCNSO or SSAC as a current stability
threat, which it would and should have if this was a threat. It would have
been a serious issue for e.g. .org, .com, .net or Colombia (.co) to have
substructures like .co.uk, .com.au or co.jp, if RFC1535 was still relevant. 

Further, RFC1535 behaviour was deprecated in BIND 13 years ago - the
behaviour described in RFC1535 was fixed in release 4.9.2 of BIND in 1993,
and the BIND 4 resolver is long officially deprecated
(http://www.isc.org/sw/bind/bind4.php). BIND is now in its version 9. The
only resolver in the 4 series that can be used, if one has to, is 4.9.11
which does not suffer from the bug described in RFC1535. We therefore
believe that RFC1535 is not a relevant stability or security risk for the
.name proposal. This has been more fully addressed in our proposal. 


In summary, this .name proposal is specific to the .name gTLD, and is
following the appropriate procedure and means available to address it. The
aim is to be able to provide a personal .name address to the 15-25% of the
peoples from Asia who have a two-letter name, who are currently being
unfairly blocked. We should release their names to the Internet for the
benefit of people worldwide. 


Thank you for your interest in .name and for considering our proposal. 


Best regards,

Hakon Haugnes
President, Global Name Registry