AT-LARGE GATEWAY

At-Large Website

ALAC

RALOs

At-Large Regional Policy Engagement Program (ARPEP)

At-Large Governance

At-Large Reports

Policy Comments & Advice

Working Groups

ICANN Meetings

At-Large Summit (ATLAS III)

At-Large Review Implementation Plan Development

ALAC and RALO Elections, Selections, and Appointments

At-Large Priority Activities - 2021

Comment Close
Date		Statement
Name 

Status

Assignee(s)

Call for
Comments Open		Call for
Comments
Close 		Vote OpenVote CloseDate of SubmissionStaff Contact and EmailStatement Number
10.08.2015

GNSO Translation and Transliteration of Contact Information Policy Development Process (PDP) Recommendations for Board Consideration

No Statementn/an/an/an/an/an/a
Lars Hoffmann
policy-staff@icann.org
n/a


For information about this Public Comment, please click here 


Brief Overview

This public comment proceeding seeks to obtain community input on the seven recommendations of the Generic Names Supporting Organization's Policy Development Process on Translation and Transliteration of Contact Information.

Section I: Description, Explanation, and Purpose

At its meeting on 24 June 2015, the Generic Names Supporting Organization (GNSO) Council unanimously adopted the following recommendations, which will be submitted to the Board for adoption after the conclusion of this public comment period:

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 L 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.

Recommendation 1 received consensus and a minority view with regard to Recommendation #1 was included in the Final Report:

Working Group member Petter Rindforth, in line with the position taken by his Constituency, the Intellectual Property Constituency (ICP),1 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 explaining the Working Group's arguments supporting mandatory transformation of contact information in all generic top-level domains.

Recommendations 2-7 received full consensus.

1 see also 5.1.1 and the Public Comment Review Tool (Annex B).

Section II: Background

The Translation and Transliteration of Contact Information Policy Development Process (PDP) Working Group (the "Working Group") is concerned with the way that contact information data – commonly referred to as 'Whois' – are collected and displayed within generic top-level domains (gTLDs). According to the Charter [PDF, 185 KB] (see also Annex A), the Working Group 'is tasked to provide the GNSO Council with a policy recommendation regarding the translation and transliteration of contact information. As part of its deliberations on this issue, the Working Group should, at a minimum, consider the following issues:

  • Whether it is desirable to translate contact information to a single common language or transliterate contact information to a single common script?
  • Who should decide who should bear the burden [of] translating contact information to a single common language or transliterating contact information to a single common script?'

Section III: Relevant Resources

Final Report [PDF, 984 KB]

Section IV: Additional Information

Section V: Reports

Staff Contact

Lars Hoffmann
policy-staff@icann.org

 

FINAL VERSION TO BE SUBMITTED IF RATIFIED

The final version to be submitted, if the draft is ratified, will be placed here by upon completion of the vote. 


FINAL DRAFT VERSION TO BE VOTED UPON BY THE ALAC

The final draft version to be voted upon by the ALAC will be placed here before the vote is to begin.

 

FIRST DRAFT SUBMITTED

The first draft submitted will be placed here before the call for comments begins.

  • No labels

1 Comment

  1. Ariel Liang

    Comments posted on behalf of Satish Babu, who checked whether the final recommends have followed the advice provided in the ALAC Statement on the Translation and Transliteration of Contact Information PDP Initial Report. 

    -- 

    1. The GNSO PDP Recommendation #1 is consistent with the ALAC recommendation B1, which states that T & T does not have to be mandatory.

     

    2. GNSO's Recommendation #2 is consistent with ALAC Recommendation B2, which states that forms and document should be capable of accepting input non-ASCII data. GNSO states further that "...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". It does not go on to say how the former part ("easy identification of what...data entries represent") can be enabled.

     

    3. GNSO Recommendations #3 and #4 are specifically about compliance to gTLD-provider business models and standards (such as RAA and AWIP).

     

    4. GNSO Recommendations #5 and #6 relate to capability and flexibility of the new system to manage non-Roman scripts, and also in maintaining traceability of T & T. This is consistent with ALAC recommendations B2 and B3.

     

    5. GNSO Recommendation #7 points out the need to harmonize these changes with other Whois modifications.

     

    6. GNSO is silent on who shall do the T & T. ALAC had a made a suggestion in this regard in its recommendation B4.

     

    Overall, I feel that GNSO Recommendations are largely consistent with the ALAC recommendations, and that we do not have to submit a fresh comment.