ICANN ICANN Email List Archives

[ssac-gnso-irdwg]


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

[ssac-gnso-irdwg] Actions/Notes/Next Meeting: IRD-WG

  • To: "ssac-gnso-irdwg@xxxxxxxxx" <ssac-gnso-irdwg@xxxxxxxxx>
  • Subject: [ssac-gnso-irdwg] Actions/Notes/Next Meeting: IRD-WG
  • From: Julie Hedlund <julie.hedlund@xxxxxxxxx>
  • Date: Wed, 20 Apr 2011 08:44:00 -0700

All,

Here are some actions and brief notes from Monday’s call.  I welcome your 
comments. Our next call will be on Monday, 02 May at 1500 UTC/0800 PDT/1100 
EDT.  The call details will be sent separately.

Attendees:  Jim Galvin, Edmon Chung, Sarmad Hussain, Steve Metalitz, Jiankang 
Yao, and Ram Mohan; from staff: Julie Hedlund, Dave Piscitello, Steve Sheng; 
Apologies — Avri Doria and Rafik Dammak;

Actions: Open a dialog on the mailing list on this proposal for a Final Report: 
Instead of recommending a particular model the IRD-WG should speak about the 
technologies that are important and relevant to this process 
(translation/transliteration) and call out the questions that need to be 
studied to develop a policy/PDP.

Notes:

Questions for Sarmad Hussain on his comments:

1. Comments on the four models and the WHOIS service


 *   Dave: Helpful to consider looking at the models in the context of who 
benefits and who is affected in terms of usability, and other parameters.
 *   Jim: Comments seemed to converge on the requirement to include the must be 
present script .
 *   Steve M.: Monolingual registrant — that is the status quo, isn’t it?  What 
do registrants do today?   Do they provide their contact data in ASCII script?
 *   Jim: Get more input from ccTLDs in particular — we don't say much about 
that in our interim report.  How much was done in talking to ccTLDs.  Started 
with a report from Dave on what ccTLDs were doing, and we got input from other 
ccTLDs.
 *   Dave: We reached out through the ccNSO to ascertain what character sets 
that they accepted — 17 or 18 responses.  We did not go back to see what user 
interface and what they accepted as submissions .
 *   Jim: Jay Daley suggested in San Francisco that a user has a right to be 
monolingual.  If we have the registrar doing the translation/transliteration 
then we have a problem with the quality of the data.
 *   Sarmad:  My main question: Who is providing the data and who is the owner? 
 Is is the registrar or registrant?  I am not sure that this is clear in the 
RAA.  This is a fundamental question that needs to be clarified.   If the 
registrant is providing the data then if there is translation or 
transliteration provided by anyone else then that could conflict with that 
fundamental principle.  If the registrant is monolingual then he/she would not 
be able to verify the translation/transliteration.
 *   Ram: Speaking from a registry operator’s perspective the data is owned by 
the registrar and provided to the registry on a contract.  The registrar is 
responsible for the registration data and owns it and is the only body that has 
the authority to change that data in the database.  We should not worry about 
who else owns the data.  It is stored in many places, but the registrar has the 
authority and owns it.   As far as the translation/transliteration: I am not 
sure that we should worry about that.  Access controls for that data are 
outside of the scope of what we are trying to do in this WG.  By access control 
I mean is who has the authority to change the data downstream.
 *   Jim: In the analysis of the comments IPC expressed concerns with 
compliance issues related to translation and transliteration from ICANN’s point 
of view. I think we could raise the question of who has responsibility for the 
data.  I think we could state what is existing practice — that the registrars 
have responsibility.   The comments from Network Solutions also suggested that 
the IRD-WG should consider the role of registries in the process.
 *   Steve:  I am concerned about the term “ownership,” which has certain legal 
meanings.  We are talking about responsibility.  I think your perspective 
depends on where you sit.  If you look at the RAA it is the registrant’s job to 
provide this information.
 *   Jim: To clarify: I think this group can call out the question of who is 
responsible for the data.  The registrars are the only ones who have authority 
to change it but they don’t take responsibility for the quality of the data.
 *   Edmon: Conceptually the end registrant “owns” that contact information but 
the fact that the registrar gives it to the registry should be balanced with 
ICANN’s policy role.
 *   Jiankang: The registry is only responsible for keeping the data safe; who 
has the responsibility to keep the data accurate?  The registration should be 
responsible for ownership and quality.
 *   Steve: Maybe we do need more information about how ccTLD’s and gTLD’s 
handle this today.  Should we ask registrars how they handle this today?  Maybe 
we could identify some registrars that are offering second level domains in 
non-ASCII scripts.
 *   Jim:  I think we should take that as a proposed action and ask for 
comments and consensus on the mailing list, but we need to be clear about what 
we want to learn from the survey.
 *   Edmon: I think a survey would be quite useful, but I would caution that 
the data that we do get back might be excluding those who are not in the system 
right now.

2. Sarmad’s second point: quality of translations/transliterations


 *   Jim:  We don’t state the we know who owns the data.  We will need to 
expand on that carefully in our report.  On the other hand I agree with you 
that if the quality of the data is the responsibility of the user, but there is 
an issue if the user cannot validate the translation/transliteration.
 *   Edmon:  I think Sarmad raised an interesting question, but it could be 
important for us to think about the quality of the supplied data versus the 
quality of the translation/transliteration.  The threshold of quality for 
translation/transliteration could be lower.  It depends on what we are going to 
use the data for.
 *   Jim:  We should at least call out the question even if we don’t answer it 
ourselves.

3. Sarmad’s Proposed New Model:


 *   Jim:  We need to think of a new way of drafting this final report:  Talk 
about the issues that go over all of the models rather than trying to emphasize 
one.  Highlight the questions and where they apply.  In Sarmad’s 5th model 
registrants should be able to provide the data in whatever way is appropriate 
to them but to make sure the data is tagged in such a way so that it could be 
translated or transliterated by others.
 *   Sarmad:  The quality of the translation/transliteration depends on who 
does it.  The model doesn’t make the registrar liable for inaccurate 
translation/transliteration.  Example:  Take a name — Mohammad, which can be 
spelled in many different ways.  What translation/transliteration is doing is 
potentially pointing law enforcement to the wrong person.
 *   Jim:  Rather than trying to recommend a particular model we need to raise 
these questions and look at several options, the first of which is that the 
registrant provides the translation/transliteration.  Also we should think 
about a clearinghouse option — to universally provide a 
translation/transliteration.
 *   Steve S.: Is our goal is to decide on one model?  There will be a policy 
development process that would determine the policy.
 *   Jim:  Up until this call we have had consensus that we would choose a 
model, but after this call I have a different view on what the final report 
should look like.  I am not inclined to recommend a particular model.  We 
should speak about the technologies that are important and relevant to this 
process (translation/transliteration) and call out the questions that need to 
be studied to develop a policy.
 *   Edmon: I agree very much with you.  I think the direction is right.   I 
think the way you characterized the perspective is a better way to go than the 
models approach.  It ties well with what Steve Sheng is asking.  Is that this 
group would produce a document that would feed into a PDP type of discussion.
 *   Action: bring to the mailing list this approach.  Open a dialog on the 
mailing list.


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

Privacy Policy | Terms of Service | Cookies Policy