[ssac-gnso-irdwg] Another comment

[Steve Sheng <steve.sheng@xxxxxxxxx>]

http://forum.icann.org/lists/ird-wg-report/msg00003.html

GNSO gTLD Registries Stakeholder Group Statement

Issue:
Interim Report of the Internationalized Registration Data Working Group


Date: March 13, 2011
Issue Document URL: 
<http://www.icann.org/en/announcements/announcement-15nov10-en.htm 
<http://www.icann.org/en/announcements/announcement-15nov10-en.htm> >
This statement on the issue noted above is submitted on behalf of the gTLD 
Registries Stakeholder Group (RySG). The statement that follows represents a 
consensus position of the RySG as further detailed at the end of the document. 
The RySG statement was arrived at through a combination of RySG email list 
discussion and RySG meetings (including teleconference meetings).

The Registries Stakeholder Group (RySG) submits the following comments 
regarding the "Interim Report of the Internationalized Registration Data 
Working Group". The RySG appreciates the effort contributed by this WG, 
consisting of subject-matter experts from the GNSO, SSAC, ccNSO and others.

Firstly the RySG considers this interim report to be highly important given its 
relevance to the delegation of IDN ccTLDs via the fast track process, as well 
as the upcoming initiation of the new gTLD program. Unfortunately, the "Fast 
Track Review" published in October 2010 does not contain much information 
related to registration data in non-ASCII characters. We also note that in the 
existing IANA IDN ccTLD database, most if not all of the IDN ccTLD delegation 
records are displayed only in ASCII form, except for the top-level domain 
string delegated. The RySG therefore urges continuing work with community 
stakeholders to provide an analysis of current practices.

The RySG suggests that a clear definition of "Internationalized Registration 
Data" (IRD) and "Registration Data containing non-ASCII character sets" must be 
provided. The context of "IRD" should be precise so that the community in 
general can understand that the WG does not deal solely with fully 
internationalized registration data but also considers a "hybrid" condition 
where ASCII and non-ASCII characters may be displayed at the same time. We 
reserve comment regarding the definition of variants and the display of it via 
WHOIS query, especially considering the ongoing effort initiated by the ICANN 
Board for variant issues of IDN TLDs.

As per its charter, the objective of the IRD-WG is to "study the feasibility 
and suitability of introducing display specifications to deal with the 
internationalization of Registration Data". We note that:
*      That objective is of course not just technical - it also has significant 
policy and business implications.  The policy implications include the impacts 
upon all the providers and consumers of gTLD (and possibly ccTLD) registration 
data, implications for domain dispute filings and resolution, for understanding 
domains' registration status, for tracking domain abuse, etc.  As such, using 
ICANN community process is essential, and exploration and decision-making 
should be done very deliberately. Changes will mean significant switching costs 
for WHOIS users and providers, and increased ongoing operational costs for 
providers.

*      The report lists the impacts of the various solution models.  These 
impact assessments are often marked as "unclear," and some important points are 
missing.  For example, one recommendation is that "Whois responses should 
include variants of an IDN label in the response as well," but that will not be 
technically practical if the number of variants is large, especially since 
registries must deliver WHOIS data under SLAs.  We encourage the IRD-WG to 
continue its evaluations of the impacts.

·      The report's recommendations are about base requirements.  This is 
logical - it is essential to define and understand the requirements before 
discussing how to technically implement them.


We are glad to see that the analysis made by the WG has taken consideration of 
the existing RAA. This approach should be further extended to ensure that 
registrars will have the capacity to acquire, verify, and restore accurate 
registration data, and provide accurate registration data services in non-ASCII 
characters. Understanding the likely operational burden on worldwide users, 
registrars, law enforcement agencies, and registries, the RySG therefore 
recommends an approach that creates minimal operational impact while still 
meeting user needs. Specifically, the RySG agrees that:

*     Domain names (RAA 3.3.1.1): Whois services should return both A-label and 
U-label representation for the given IDN domains queried.

*     Name server names (RAA 3.3.1.2): Currently all name servers are in ASCII. 
To the extent technically possible names should be displayed in the 
corresponding U-label, as well.

*     Sponsoring Registrar (RAA 3.3.1.3): This should always be available in 
ASCII to aid law enforcement and intellectual property investigations. To the 
extent possible, it should also be available in local language and script. It 
is important to note that ICANN's registrar accreditation application 
<http://www.icann.org/en/registrars/accreditation-application.htm> requires 
applicants to submit a transliteration of "any legal name, street, electronic 
or mailing address which is not in Latin characters."

*     Telephone/Fax (RAA 3.3.1.7,8): Should always be available in ASCII and in 
internationally recognized notation.

*     Email address (RAA 3.3.1.7,8): Should always be available in ASCII. To 
the extent technically possible names should be displayed in the corresponding 
U-label as well.  The RySG notes that internationalized email addresses are 
being considering in standardization efforts by the Email Address 
Internationalization (EAI) WG in the IETF, and there should be dependency 
created and maintained on the progress being made on the IETF WG. Handling of 
IDNs in association with individual address also needs to be discussed and 
defined.

*     Dates (RAA 3.3.1.4,5): Should always be available in ASCII. However, the 
RySG does not understand why the WG members did not discuss the 
internationalization of this field.

*     Registration Status: Should always be available in ASCII. In the gTLDS, 
EPP status fields are relied upon by registrants and registrars for a variety 
of registration purposes.  For example, registrants and registrars rely on them 
to understand and track registrar-to-registrar transfers, and to determine the 
expiration or RGP status of a domain. Domain statuses are also checked by law 
enforcement and abuse responders.

*     Entity names and Address (RAA 3.3.1.6,7,8): Should always be available in 
ASCII where non-ASCII registration data (translation or transliteration) is 
optional, and acceptable by the registrars and the registries.

The RySG believes WHOIS internationalization is an important issue that needs 
forward movement, and looks forward to participating in further discussions of 
this topic. The RySG is willing to work with community stakeholders, including 
governments and public authorities, to explore conditions and requirements for 
making non-ascii registration data mandatory (i.e., IDN registry - registrar - 
registrant service model for a specific linguistic or cultural community).



 RySG Level of Support

1.   Level of Support of Active Members:  Supermajority
1.1. # of Members in Favor:  10
1.2. # of Members Opposed: 0
1.3. # of Members that Abstained: 0
1.4. # of Members that did not vote: 3
2.   Minority Position(s): N/A


General RySG Information

* Total # of eligible RySG Members[1] <#_ftn1> :  14
* Total # of RySG Members:  13
* Total # of Active RySG Members[2] <#_ftn2> :  13
* Minimum requirement for supermajority of Active Members:  9
* Minimum requirement for majority of Active Members:  7
* # of Members that participated in this process:  13
* Names of Members that participated in this process:  13
1.   Afilias (.info & .mobi)
2.   DotAsia Organisation (.asia)
3.   DotCooperation (.coop)
4.   Employ Media (.jobs)
5.   Fundació puntCAT (.cat)
6.   Museum Domain Management Association - MuseDoma (.museum)
7.   NeuStar (.biz)
8.   Public Interest Registry - PIR (.org)
9.   RegistryPro (.pro)
10. Societe Internationale de Telecommunication Aeronautiques - SITA (.aero)
11. Telnic (.tel)
12. Tralliance Registry Management Company (TRMC) (.travel)
13. VeriSign (.com, .name, & .net)


 *   Names & email addresses for points of contact

o  Chair: David Maher, dmaher@xxxxxxx <mailto:dmaher@xxxxxxx>
o  Vice Chair:  Jeff Neuman, Jeff.Neuman@xxxxxxxxxx 
<mailto:Jeff.Neuman@xxxxxxxxxx>
o  Secretariat:  Cherie Stubbs, Cherstubbs@xxxxxxx <mailto:Cherstubbs@xxxxxxx>
o  RySG representative for this statement: Ching Chiao, chiao@xxxxxxxxxxxxx 
<mailto:chiao@xxxxxxxxxxxxx>


________________________________
[1] <#_ftnref>  All top-level domain sponsors or registry operators that have 
agreements with ICANN to provide Registry Services in support of one or more 
gTLDs are eligible for membership upon the "effective date" set forth in the 
operator's or sponsor's agreement (RySG Articles of Operation, Article III, 
Membership, ¶ 1).  The RySG Articles of Operation can be found at 
<http://gnso.icann.org/files/gnso/en/improvements/registries-sg-proposed-charter-30jul09-en.pdf>.
  The Universal Postal Union recently concluded the .POST agreement with ICANN, 
but as of this writing the UPU has not applied for RySG membership.

[2] <#_ftnref>  Per the RySG Articles of Operation, Article III, Membership, ¶ 
6: Members shall be classified as "Active" or "Inactive". A member shall be 
classified as "Active" unless it is classified as "Inactive" pursuant to the 
provisions of this paragraph. Members become Inactive by failing to participate 
in a RySG meeting or voting process for a total of three consecutive meetings 
or voting processes or both. An Inactive member shall have all rights and 
duties of membership other than being counted as present or absent in the 
determination of a quorum. An Inactive member may resume Active status at any 
time by participating in a RySG meeting or by voting.


Warm regards,
Steve