[Npoc-discuss] GNSO PDP T&T has been approved by the ICANN board

Thu Oct 1 13:49:09 UTC 2015

Dear NPOC members,

During the period 2014-2015 all over about 16 months I have been co-chair of the GNSO PDP working group on Translation and Transliteration of Contact Information. The final report with 7 recommendations was approved and unanimous voted by the GNSO Council during the Buenos Aires meeting. So we will enter into the last phase of this PDP in a few weeks with the implementation of the proposed recommendations. I welcome any NPOC member during the process of putting together the WG team.

GNSO Council Recommendations Translation and Transliteration of Contact Information

Whereas, on 13 June 2013, the GNSO Council launched a Policy Development Process (PDP) on the Translation and Transliteration, addressing two charter questions, set forth at http://gnso.icann.org/en/issues/gtlds/transliteration-contact-charter-20nov13-en.pdf [PDF, 185 KB].

Whereas, the PDP followed the prescribed PDP steps as stated in the Bylaws, resulting in a Final Report delivered on 12 June 2015.

Whereas, the Translation and Transliteration of Contact Information Working Group (WG) reached consensus on its first recommendation and full consensus on its remaining six recommendations.1

Whereas, the GNSO Council reviewed, and discussed the recommendations of the Translation and Transliteration of Contact Information WG, and adopted the Recommendations on 24 June 2015 by a unanimous vote (see: http://gnso.icann.org/en/council/resolutions#20150624-3).

Whereas, the GNSO Council vote met and exceeded the required voting threshold (i.e. supermajority) to impose new obligations on ICANN contracted parties; and

Whereas, after the GNSO Council vote, a public comment period was held on the approved recommendations, and the comments have been summarized and considered (https://www.icann.org/public-comments/transliteration-contact-recommendations-2015-06-29-en).

Resolved (2015.09.28.02), the Board adopts the GNSO Council Policy Recommendations concerning the translation and transliteration of contact information as presented in the Final Report.

Resolved (2015.09.28.03), the CEO, or his authorized designee(s), is directed to develop and complete an implementation plan for these Recommendations and continue communication and cooperation with the GNSO Implementation Review Team and community on the implementation work.

Rationale for Resolutions 2015.09.28.02 – 2015.09.28.03

Why the Board is addressing the issue now?

The continued internationalization of the domain name systems means that an ever-larger share of Internet users do not use (or are not  even familiar) with US ASCII, the technical term for the Latin-based script used in English and many other western European languages.

Accuracy and consistency of contact information data are crucial to make it a useful source to those seeking information regarding domain name registrants. This PDP WG has considered the important issue of whether translated and/or transliterated data or data submitted in the script best known to the registrant is more likely to deliver these requirements, bearing also in mind the amount of requests for such data and the costs associated with blanket translation or transliteration.

The Translation and Transliteration PDP Final Report received consensus support on its first recommendation and full consensus on the remaining six others. It also received unanimous support from the GNSO Council.

Following the closing of the public comment period, the next step as outlined in Annex A of the ICANN Bylaws is consideration by the ICANN Board of the recommendations.

What is the proposal being considered?

The following policy recommendations are being adopted:

Recommendation #1 The Working Group recommends that it is not desirable to make transformation of contact information mandatory. Any parties requiring transformation are free to do so on an ad hoc basis outside Whois or any replacement system, such as the Registration Data Access Protocol (RDAP). If not undertaken voluntarily by registrar/registry (see Recommendation #5), the burden of transformation lies with the requesting party.

Recommendation #2 Whilst noting that a Whois replacement system should be capable of receiving input in the form of non-ASCII script contact information, the Working Group recommends its data fields be stored and displayed in a way that allows for easy identification of what the different data entries represent and what language(s)/script(s) have been used by the registered name holder.

Recommendation #3 The Working Group recommends that the language(s) and script(s) supported for registrants to submit their contact information data may be chosen in accordance with gTLD- provider business models.

Recommendation #4 The Working Group recommends that, regardless of the language(s)/script(s) used, it is assured that the data fields are consistent to standards in the Registrar Accreditation Agreement (RAA), relevant Consensus Policy, Additional Whois Information Policy (AWIP) and any other applicable polices. Entered contact information data are validated, in accordance with the aforementioned Policies and Agreements and the language/script used must be easily identifiable.

Recommendation #5 The Working Group recommends that if the transformation of contact information is performed, and if the Whois replacement system is capable of displaying more than one data set per registered name holder entry, these data should be presented as additional fields (in addition to the authoritative local script fields provided by the registrant) and that these fields be marked as transformed and their source(s) indicated.

Recommendation #6 The Working Group recommends that any Whois replacement system, for example RDAP, remains flexible so that contact information in new scripts/languages can be added and expand its linguistic/script capacity for receiving, storing and displaying contact information data.

Recommendation #7 The Working Group recommends that these recommendations are coordinated with other Whois modifications where necessary and are implemented and/or applied as soon as a Whois replacement system that can receive, store and display non-ASCII characters, becomes operational.

Finding in relation to second Charter question Based on recommendations #1-#7, the question of who should decide who should bear the burden of translating or transliterating contact information to a single common script is moot.

Recommendation 1 was accompanied by a Minority Statement, reading as follows: Working Group member Petter Rindforth, in line with the position taken by his Constituency, the Intellectual Property Constituency (ICP),2 recommends mandatory translation and/or transliteration (transformation) of contact information in all generic top-level domains (gTLDs).

Although he agrees that there are situations where the contact information in the local language of the registrant is the primary version, such as to identify the registrant in preparation for a local legal action, there are a number of situations where a global WHOIS search, providing access to data in as uniform a fashion as possible, is necessary for the data registration service to achieve its goals of providing transparency and accountability in the DNS. See also 5.1.1 [of the Final Report] explaining the Working Group's arguments supporting mandatory transformation of contact information in all generic top-level domains.

Which stakeholders or others were consulted?

Regular consultation with stakeholders took place during the lifetime of this PDP, specifically during three ICANN meetings (ICANN 49, 50 and 51), as well as public comment periods for the Preliminary Issues Report, the Initial Report and prior to Board consideration.

What concerns or issues were raised by the community?

The main concern that was raised by the Community was that a multi-script / multi-language database will lead to less transparency because scripts other than Latin might be less comprehensible for a majority of internet users. It would also reduce the search-ability of data. It was also feared that fraudulent registrants could hide their identity behind different scripts/languages.

What significant materials did the Board review?

The Board reviewed the Final Report, the GNSO Council Recommendations Report to the Board, as well as the summary of public comments and Staff's response to those comments.

What factors did the Board find to be significant?

The recommendations were developed following the GNSO Policy Development Process as outlined in Annex A of the ICANN Bylaws and have received the unanimous support from the GNSO Council. As outlined in the ICANN Bylaws, the Council's supermajority support for the motion (the Council voted unanimously in favor) obligates the Board to adopt the recommendation unless by a vote of more than two-thirds, the Board determines that the policy is not in the best interests of the ICANN community or ICANN. In addition, continuing the internationalization of the domain name system is an important area of work for ICANN. The recommendations have the potential to improve user-friendliness and accuracy of contact information data throughout a truly globalized DNS.

Are there positive or negative community impacts?

Some of the positive impacts identified in the Final Report include (but are not limited to):

	• Registrants not familiar with US-ASCII will be able to register domain names using the script they are most familiar with;
	• Registrars are not forced to translate or transliterate data but they have to validate data regardless of which script they support –  the decision on which ones those are will be regulated by demand and supply;
	• Registration costs will not increase because requiring registrars to translate or transliterate all contact information data into one script3 will inevitably lead to costs that could be passed on to registrants;
	• Allowing registrants to use the language/script they are most familiar with when registering domains will have a positive impact on data accuracy.
Some of the negative impacts identified in the Final Report are that:

	• Those seeking to search contact information data and operating in US-ASCII might have to translate or transliterate data to be able to contact registrants (though that is true for those seeking information but not familiar with US-ASCII even if translation or transliteration were mandatory).
Are there fiscal impacts or ramifications on ICANN (strategic plan, operating plan, budget); the community; and/or the public?

There are no fiscal impacts on ICANN. Those members of the community and wider public might have to pay for professional translation or transliteration of contact information. However, these costs stand in stark contrast to the potential costs that would occur if under a blanket requirement every contact that is provided in a script other than US-ASCII would have to be translated or transliterated.

Are there any security, stability or resiliency issues relating to the DNS?
The current WHOIS protocol is not designed for scripts other than US-ASCII. However, the Registration Data Access Protocol (RDAP) is currently being rolled out as the WHOIS replacement and it [the RDAP] is fully compatible with different scripts. Once the RDAP is implemented – or any another replacement that is capable of dealing with scripts other than US-ASCII – there will be no security, stability, or resiliency issues related to the DNS if the Board approves the proposed recommendations.

Rudi Vansnick
Chair Non-for-Profit Operational Concerns Constituency (NPOC)
www.npoc.org <http://www.npoc.org/>

rudi.vansnick at npoc.org
Tel : +32 (0)9 329 39 16
Mobile : +32 (0)475 28 16 32

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/npoc-discuss/attachments/20151001/e0362916/attachment.html>