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

[James M Galvin <jgalvin@xxxxxxxxxxxx>]

Thanks Julie, this looks good to me.

Jim



-- On May 16, 2011 8:55:10 AM -0700 Julie Hedlund 
<julie.hedlund@xxxxxxxxx> wrote regarding [ssac-gnso-irdwg] IRD-WG 
Meeting Notes: 16 May 2011 --
> 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+Regist
> ration+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.