[ssac-gnso-irdwg] RE: Version 2 of the Draft Final Report - suggested staff edit of Recommendation #2
- To: Steve Sheng <steve.sheng@xxxxxxxxx>, Steve Sheng <steve.sheng@xxxxxxxxx>, "ssac-gnso-irdwg@xxxxxxxxx" <ssac-gnso-irdwg@xxxxxxxxx>
- Subject: [ssac-gnso-irdwg] RE: Version 2 of the Draft Final Report - suggested staff edit of Recommendation #2
- From: Liz Gasster <liz.gasster@xxxxxxxxx>
- Date: Wed, 28 Sep 2011 07:32:25 -0700
I would like to propose a slight modification to Recommendation 2 in your draft
Final Report, v. 2 regarding the request for an Issue Report (the Issue Report
is a preliminary report that staff writes, which typically is the first step to
launching a Policy Development Process (PDP)). Over the last months, a GNSO
Work Team has been updating the GNSO Policy Development Process to include
additional fact-finding before the typical "Issue Report" would be requested of
Staff. The rationale for conducting fact finding before preparation of an
Issue Report is to help assure that there is sufficient information available
upon which staff can base the determinations and other content typically
addressed in an Issue Report. In this case, fact finding could take the form
of a Request for Information to ask the community questions about "whether it
is desirable to translate contact information to a single common language or
transliterate contact information to a single common script". An RFI could also
ask the community to provide their insights and viewpoints about "who should
bear the burden and who is in the best position to address these issues."
Another means of fact-finding in addition to (or in lieu of) a possible RFI
approach might be to develop and plan a workshop, for example in Costa Rica, to
delve into these questions, and expand the documented record of these issues
prior to moving to the Issue Report stage. My concern about Recommendation 2
as written, is that it would be very difficult for staff to prepare an informed
Issue Report on the topics requested, without additional information.
Here is the current language and a modest proposal to change it:
Recommendation 2: The GNSO council and SSAC should request a common issues
report on translation, transliteration or transcription of contact information.
The issues report should consider whether it is desirable to translate contact
information to a single common language or transliterate contact information to
a single common script. It should also consider who should bear the burden and
who is in the best position to address these issues. The report should consider
policy questions raised in this document and should also recommend whether to
start a policy development process (PDP).
Recommendation 2: The GNSO council and SSAC should coordinate the planning of a
series of fact-finding steps that could lead to an Issues Report on the
translation, transliteration or transcription of gTLD Whois contact
information. Fact-finding should consider whether it is desirable to translate
contact information to a single common language or transliterate contact
information to a single common script. It should also consider who should bear
the burden and who is in the best position to address these issues. Following
this fact-finding, the GNSO and SSAC should consider whether an Issue Report
should be requested to consider policy questions raised in the IRD Working
Group Final Report and to recommend whether to start a policy development
Please feel free to modify the language, it's just a draft, but the crux of the
proposed revision is a desire to make sure that staff has the information upon
which to prepare an Issue Report before one is requested.
Thanks so much for considering.
Best, Liz Gasster
Senior Policy Counselor
From: owner-ssac-gnso-irdwg@xxxxxxxxx [mailto:owner-ssac-gnso-irdwg@xxxxxxxxx]
On Behalf Of Steve Sheng
Sent: Wednesday, September 21, 2011 5:50 PM
To: Steve Sheng; ssac-gnso-irdwg@xxxxxxxxx
Subject: [ssac-gnso-irdwg] Version 2 of the Draft Final Report
Thank you all for the latest round of feedback as well as detailed
discussions on the phone calls, attached please find a revised version of the
draft final report as well as a redline version (as compared with version 1).
Changes from version 1 are:
- reworded recommendations as discussed on the phone call.
- cleaned up the document
- addressed most of Avri's comments
- revised the translation and transliteration section.
- provided more text on section 3.4.
- added some text about transcription, along with translation and
At the direction of the chairs, this document is now in last call status, WG
members are encouraged to provide comments by close of business September 27
Also as agreed two calls ago, I have circulated this report to IETF IDN expert
John Klensin for his comments.
Finally, on the last phone call, there are two issues raised:
1) whether to add some text about transcription. - I think Jim and Avri think
this should be added. I have also recommended this to make the document
technically correct. If others have a different opinion, would encourage you to
raise it now.
2) whether to include texts on variants, Edmon suggested yes and to include
the following text (from interim report), but would need more opinion from the
WG, is there any support or objection to include the following text from the
interim report into section 4.2 under domain names? Your opinion is greatly
The IRD-WG members discussed the issue of how to query and display variants
extensively. They provide the following observations:
* There is no uniform definition of variant. Different organizations and
different countries define it differently. However, in general, variants can be
categorized as activated variants and reserved variants. Activated variants are
variants of a domain name that are put in the corresponding DNS zone file, thus
resolvable through normal DNS lookups. Reserved variants are variants reserved
for a specific domain name and cannot be registered, but are otherwise not in
the DNS zone file.
* IRD-WG members noted that it is outside the scope of the IRD-WG to define
variants or discuss how different languages handle variants. Rather, the IRD-WG
use the categories as they are generallly defined (activated vs. reserved).
* The IRD-WG members agree that a Whois service query of an activated
variant should return the domain of which it is a variant in its response, as
well as an indication that the label queried is a variant of the original
domain. The IRD-WG members agree that this should be consistent across Whois
* The IRD-WG members also agree that defining a Whois service query of a
reserved variant returns is a matter of local policy. The IRD-WG has identified
two options: A query of a reserved variant for XYZ domain should return a
message saying that this variant is a reserved variant of XYZ domain or
(alternatively) a query of a reserved variant should return the same
information as the query for an activated variant. The WG further agreed that
having the Whois service response provide a link to the registrar/registries'
variant policy would be helpful.
On 9/8/11 11:13 PM, "Steve Sheng" <steve.sheng@xxxxxxxxx> wrote:
Thanks for those who have provided comments to this report, attached please
find version 1 of the draft final report. (apologies for sending it late).
Changes from version 0:
- reorganize the findings section to make it flow better
- added additional discussions about translation and transliteration.
- added text where necessary.
- addressed some editor notes.
For your reference, I have also included a redline version compared with