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

Sun Nov 8 18:54:37 UTC 2015

Hi all,

Congratulations in order dear Rudi.

Cheers !
-Olévié-

2015-10-01 15:02 GMT+01:00 Klaus Stoll <kdrstoll at gmail.com>:

> Dear Rudi
>
> First of all: Congratulation for great and hard is in order. I want to
> encourage all NPOC members to get involved in implementing the
> recommendations. Maybe we could make this a topic for our next membership
> call.
>
> Congratulations again
>
> Yours
>
> Klaus
>
>
> On 10/1/2015 9:49 AM, Rudi Vansnick wrote:
>
> 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)
> <http://www.npoc.org>www.npoc.org
>
> <rudi.vansnick at npoc.org>rudi.vansnick at npoc.org
> Tel : +32 (0)9 329 39 16
> Mobile : +32 (0)475 28 16 32
>
>
>
>
>
> _______________________________________________
> Npoc-discuss mailing listNpoc-discuss at icann.orghttps://mm.icann.org/mailman/listinfo/npoc-discuss
>
>
>
> _______________________________________________
> Npoc-discuss mailing list
> Npoc-discuss at icann.org
> https://mm.icann.org/mailman/listinfo/npoc-discuss
>

-- 
*Olévié Ayaovi Agbenyo KOUAMI*

*Directeur-Adjoint de O and K IT SOLUTIONS sarl (Editeur de logiciels de
gestion SIGE (http://www.oandkit.com <http://www.oankit.com>)*

*Président/CEO de l'INTIC4DEV (Institut des TIC pour le développement)*

*SG de ESTETIC  - Association Togolaise des professionnels des TIC
(http://www.estetic.tg <http://www.estetic.tg>)*

*ICANN-GNSO-NCSG-NPOC Communications Committee Chair (http://www.npoc.org/
<http://www.npoc.org/>)Membre du FOSSFA (www.fossfa.net
<http://www.fossfa.net>) et Membre de Internet Society (www.isoc.org
<http://www.isoc.org>) *

*Skype : olevie1 FB : @olivier.kouami.3 Twitter : #oleviek Lomé – Togo*
ICANN - Fellow & Alumni

*Membre fondateur du RIK-Togo (Réseau Interprofessionnel du Karité au Togo)*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/npoc-discuss/attachments/20151108/9bcc2186/attachment.html>