ICANN ICANN Email List Archives

[ssac-gnso-irdwg]


<<< Chronological Index >>>    <<< Thread Index >>>

[ssac-gnso-irdwg] IRD-WG Meeting Notes: 16 May 2011

  • To: "ssac-gnso-irdwg@xxxxxxxxx" <ssac-gnso-irdwg@xxxxxxxxx>
  • Subject: [ssac-gnso-irdwg] IRD-WG Meeting Notes: 16 May 2011
  • From: Julie Hedlund <julie.hedlund@xxxxxxxxx>
  • Date: Mon, 16 May 2011 08:55:10 -0700

All,

Here are the notes from today’s meeting.  Please let me know if you have any 
changes.  Our next call will be in four weeks on Monday, 13 June (30 May is a 
US Holiday) at 1500 UTC/0800 PDT/1100 EDT.  See also the wiki at: 
https://community.icann.org/display/gnsossac/Internationalized+Registration+Data+Working+Group+-+Home.
  For other places see:
http://www.timeanddate.com/worldclock/fixedform.html.  Dial-in details are 
below.  If you require a dial-out, please let me know. We currently have Rafik 
and Sarmad on the list.  The teleconference information will be sent with the 
call reminder.
-----------------------------------------------------
ACTION:  Staff will produce a more detailed outline with text filled by 6 June 
for the WG’s review at its meeting on 13 June.
-----------------------------------------------------

Notes 16 May 2011

Attendees: Jim Galvin, Chair; Steve Austin, Avri Doria, Rafik Dammak, Sarmad 
Hussain, Bob Hutchinson, and Jiankang Yao; Staff: Julie Hedlund, Dave 
Piscitello, and Steve Sheng
Apologies: Steve Metalitz

Comments on Jim’s Proposal (see proposal and draft outline below)

Dave: The issue is not one of cost, but how we are going to pay for this.  The 
recommendations could talk about improvements to WHOIS to support IRD in a 
manner that no individual group ends up with an unfunded mandate.
Avri: This is a decent way to approach the work.  Comments on unfunded 
mandates, if we try to make that a consideration then we may just end up with 
the status quo.   We could include understanding the cost of what is being 
recommended, but that could be a result of this work.
Dave: Trying to get us to a more constructive dialog and consider models to 
share the cost or look at examples from other areas, such as data escrow.
Jim:  Suggest that we allow for some text to be developed in this area.
Avri:  We don’t have to call it an “unfunded mandate,” we can break it down 
into cost, who bears it, how do we fund it.
Bob: We may need to wordsmith the recommendations to clearer reflect the 
sentiment of the group: We can’t move forward without a policy that says who is 
going to do what.
Jim:  Maybe I have gone to far in narrowing the scope.
Bob:  There is another group that is working on trying to pick a protocol.  We 
could do a bottom up systems analysis, but we need a proper understanding of 
the policies that the system was trying to implement.
Avri: The GNSO Council is working on the whole issue of WHOIS services and 
policies.  One part of that report has the international display requirements, 
which helped kick off this group.  Perhaps Jim should be plugged into that work.
Jim:  The question I have is what is the action we should take?  Are we 
expanding on text to include in the recommendations?   Also, we should look 
into coordination.
Steve Sheng: When we wrote the service requirements report for WHOIS data we 
said we would wait until the IRD-WG provides its recommendations.  I am not 
sure the recommendations would be ready in time to include in a survey.
Bob (to Avri): Should we suspend the work of this group until the GNSO 
completes its work?
Avri:  I would not recommend suspension.  I would definitely recommend 
coordination.  We can provide updates to the GNSO Council.  The policy comes 
later.
Julie:  We do provide updates at GNSO Council meetings during ICANN meetings.
Avri:  I suggest more frequent coordination.
Jim:  Suggest we draft the document based on what I have proposed and give a 
heads up to the GNSO Council.
Sarmad: I had proposed a new model.  I am not sure what you mean by 4c.
Jim:  It was my intention to cover your proposal in the section on 
monoligualism.   Concerning 4c, I think the internal part of the system is 
ready for IRD to the extent that things are XML based since this allows 
tagging.  We could recommend that registries, registrars, and ICANN should make 
sure their systems are capability of handling this.  I was trying to separate 
this from the protocol issue.
Sarmad:  I am not sure what we are recommending.
Jim:  I think we can see how the text develops and reconsider this question.
Bob:  What happens after we publish this document?
Jim:  The report will need to be published for comment and will need to 
consider those comments.  Once it is final it will go to the Council, which 
will decide how to proceed.
Steve:  The staff could fill in a more detailed outline and send it to the WG 
to consider and to discuss on 6 June for a call on 13 June.
Avri:  Is this tied to any dates for Singapore?
Julie:  No, this is only for internal review in the WG, although we will 
provide a brief update on the status of our work in Singapore for the GNSO 
Council and the public.

Proposal from Jim for Consideration:

As a reminder, the mission of this working group is as follows:

The IRD-WG shall study the feasibility and suitability of introducing display 
specifications to deal with the internationalization of Registration Data.  In 
our interim report we have evolved 4 models and we sought community input on 
the efficacy of the those models.  We did get a few well reasoned comments but 
it is fair to say that we did not receive anything close to a community 
consensus on how to choose between the models.  I would like to propose 
something different than choosing between the 4 models, which we discussed 
during our last meeting.

In my opinion, the models are trying to address the problem of executing 
translation and transliteration.  Model 1 is status quo, i.e., we stick with 
the system we have and require US-ASCII to be
present at all times.  The other models distribute the translation and 
transliteration services in various ways.  I do not think we need to solve this 
problem.  I think we identify this as the problem that needs further study.

Specifically, I suggest the outline below for our final report. This is an 
expanded outline insofar as I try to say a bit about what I would expect to be 
in each section.  It is probably not explained
as well as it could be but I do hope it gets the point across.  I did not want 
to make this message any longer than it already is.  I also was not trying to 
write the report since I do want some discussion about this approach first.

The model for the outline is we state what we have, we make some observations 
about what we have, and we propose further study of a few specific issues.

1. INTRODUCTION - Mostly boilerplate information including problem statement 
and details about the formation of this group.  We can re-purpose a great deal 
of what is in the interim report.

2. BACKGROUND - This should include all the facts we need to support our 
findings.  Most of this is in our interim report.

a. what we know various registrars and registries are doing today to support 
the display of internationalizes data.
b. what we know about the existing WHOIS protocol.
c. what we know about the definition of registration data.
d. what we know about where different registration data elements are collected, 
stored, managed, and displayed.

3. INTERNATIONAL STANDARDS - This could be a part of the background information 
but my current thinking is that it is better to elevate to a major section.  In 
this section we summarize all the
international standards and standard practices that exist for 
internationalizing the various elements of existing registration data.  Most of 
this is in our interim report.

4. FINDINGS - In this section we list the conclusions we can draw from all the 
facts stated previously.

a. WHOIS is insufficient.  It has no structure and hence no method of signaling 
encodings.

a.1. Registration data has multiple purposes and internationalization 
requirements are different depending on the purpose.  To the extent the data is 
already represented in XML, e.g., within EPP between registrars and registries, 
internationalization is primarily ensuring the data is properly tagged with the 
script that is in use.

a.2. The lack of structure in WHOIS excludes any signaling mechanism, thus the 
data can not be correctly tagged and further it can not be correctly displayed.

a.3. There are recognized standards for internationalizing many of the elements 
of registration data but in many cases the data would need to be translated or 
tranliterated for use with the current
WHOIS.

b. Registrants are monolingual.  This is intended to highlight the problem of 
who does the translation or transliteration and what it means to responsibility 
for quality and compliance.

c. Quality of data is not a well defined phrase.  Registrants are expected to 
provide high quality data but can it be verified?  Even if could what happens 
to the quality after translation and transliteration and who is responsible for 
that?

d. Registration data is itself undefined.  WHOIS services do vary. WHOIS 
requirements vary between registrars and registrants as evidenced by the 
contracts.

4. RECOMMENDATIONS

a. Seek a plan to define registration data, who collects it, who stores it, who 
is responsible for it, and specify its purpose.

b. Seek a plan to replace WHOIS.  In other words, although the data can 
probably be internationalized, displaying it is problematic with the current 
system.  This study would need to consider if
registration data should be translated or transliterated, who should do it, 
what it means to the overall registration data infrastructure, and what it 
means to the quality of the data.

c. As an interim solution, given the continued use of WHOIS, as much as 
possible, all parties in the lifecyle of the registration data should adopt the 
international standards noted above for
registration data elements wherever they can.






<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy