RE: [gnso-idn-wg] Comments on IDN WG Outcomes Report v2.3 (long)

["Ram Mohan" <rmohan@xxxxxxxxxxxx>]

Avri,
Very thoughtful suggestions regarding Agreement/Support - I will consider
them carefully, and incorporate into the next round.

I am re-working the Draft Outcomes document to a format that changes the
numbering scheme somewhat and lists areas of "Agreement" together and areas
of "Support" together.  I will incorporate your comments into that draft
document before the next version gets sent to the list tomorrow.

-Ram

--------------------------------------------------------------------------
Ram Mohan
e: rmohan@xxxxxxxxxxxx | m: +1.215.431.0958
--------------------------------------------------------------------------


-----Original Message-----
From: owner-gnso-idn-wg@xxxxxxxxx [mailto:owner-gnso-idn-wg@xxxxxxxxx] On
Behalf Of Avri Doria
Sent: Wednesday, March 14, 2007 2:19 PM
To: gnso-idn-wg@xxxxxxxxx
Subject: [gnso-idn-wg] Comments on IDN WG Outcomes Report v2.3 (long)

Hi,

Unfortunately I will be on a plane during the Friday special meeting,  
so decided i would put my comments/issues into an email message.

As opposed to going through then by category, as makes sense in the  
meetings, i will just got through the sections where i have questions  
or comments numerically.



---section 2

Note: on definitions:  we spent a little bit of discussion time on  
the levels of support.  I am comfortable with the current categories  
(don't really care what they are called), but think that they may  
benefit with somewhat better explanations.

e.g. for there to be a broad agreement similar to IETF's rough  
consensus, means that someone, specifically the chair, needs to be in  
the position of deciding that there is broad agreement despite some  
low level of continued disagreement. Since this report is being  
passed on to the council and its other TFs and WGs, those few  
disagreeing with the broad agreement should be able to add a brief  
comment to the report explaining their disagreement.  My assumption  
is that for the call of broad agreement to hold at the council level,  
there should only be very few comments attached to the claim of  
agreement, and that the chair should be able to explain to the  
council and others how those issues were adequately discussed in the  
WG.  The fact that we have recordings of the meetings and an open  
email list should make that burden relatively easy.

Note, I think that this same condition would hold in the  
determination of "outside scope" since that is essentially another  
form of agreement category.

In terms of Support classification, I think that there are two types  
(ok, at least two types - there are always exceptions to any  
bifurcation); those where there are multiple suggestions on the same  
topic and those where there is a single opinion and disagreement of  
that opinion.  In the case where there are multiple opinions, the  
document is good at listing them and I am sure that new alternates  
will be added as necessary.  In cases where the is lukewarm support  
and disagreement, there should, if possible be some statement  
explaining the reasons for disagreement.

---4.1.4

Should probably include a definition of "keyword" solutions in the  
glossary or in the statement of support.  I don't remember what they  
are.

---4.1.5

I personally strongly support the option that indicates that there  
should not be a policy dictated priority, but that the order in which  
scripts are supported technically should determine the order in which  
they are supported in the application process.  I also support the  
notion that dealing with the policy considerations needs to be  
sufficiently completed, as opposed to perfectly completed, before the  
process ICANN accepts and processes applications for IDN gTLDs.

---4.2.1

I agree that the pioneers in IDN deployment should not be penalized  
and that ICANN must do its utmost to support work that has gone on in  
the absence of centralized support.

---4.2.2

While I support the right of a country to designate its own name in  
the scripts associated with its national languages, I am strongly  
against giving any nation the ability, let alone responsibility, to  
control _any_ other IDN TLDs in scripts associated with their  
national languages.  I certainly support countries' right to comment  
and to challenge applications on an equal basis during the new gTLD  
process and to take advantage of any challenge mechanisms that may be  
created.  I also support the idea that language communities should  
have a voice and an equal right to comment and challenge TLDs in  
scripts associated to their languages.

While I support notification of appropriate governments in cases of  
application for Geographical Indicator gTLD, I do not support any  
special status for governments within that process.


---4.2.5

As part of the RN WG subgroup on Geographical Indicators, I note that  
our recommendations include the notation that further work and  
consultation is required.  I expect this will be an ongoing activity  
for some group if/when the IDN WG finishes its work.


---4.3.2

While I agree with this proposal, I also believe that there should be  
support for continued legacy support and that an appeal should be  
made to the technical community to find a solution that allows full  
legacy support.  In cases where this is truly impossible, then this  
recommendation should pertain.

---4.3.3

While I believe that the current guidelines should be followed, I  
also believe that the IDN guidelines should be open to review and  
revisions if necessary.  I certainly agree that all contracts should  
conform to all ICANN guidelines and consensus policies.

---4.3.5 2nd Agreement

While I agree that there would be challenges, I would be more  
comfortable with wording that said:

that applications for IDN gTLDs may face challenges/objections based  
on claims of intellectual property rights (IPR).

i.e. it is not for us or ICANN to judge the validity of those claims.

---4.3.6

Thanks for including this option.

As I discussed at the last phone call, I think this is an important  
option for those who feel they need it.  I also believe that it would  
be reasonable to expect that any registry that requested this alias  
option would also extend that option to its registrants - I would  
even be in favor of making this a requirement for granting the request.

As part of the association of the LDH alias, I would support a  
condition that indicated that ICANN would have the ability to  
determine the appropriate LDH alias, i.e. while the application would  
include the request for an LDH alias and could even recommend one,  
ICANN would have no need to grant that particular alias -  especially  
in those cases where the requested LDH alias conflicted with a LDH  
application of the same round.  E.g. if the "onion growers  
cooperative" (for want of a better example) of the Galil  applies  
for .בצל (bazal == onion) there is no reason why ICANN should grant  
them .onion as the LDH alias, especially if the UK Onion Grower's  
Association is applying for .onion in same round.  A more appropriate  
LDH alias might be .bazal or even .onioninhebrew.

Additionally, during the conversation, there was mention, apologies -  
I do not remember by whom, of a corollary option of an alias in  
script variant, or in a different script associated with another  
official language of a country.  I would be in support of a single  
such variant or IDN alias being granted as part of a single  
application instead of the LDH alias.

---4.4.1  Agreement 1

While I am in agreement, I would be more comfortable with the  
following wording:

priority rights for new domain names do not derive from the  
possession of existing domain name strings as such, but may derive  
from established IPR.

i.e. ie. the claims need to established by whatever external  
authorities establish such rights, and 'IPR rights' seems redundant

---4.4.1  support stmt 1

I propose adding the following alternate to

A consideration in the protection of rights of others must include  
protecting the commons, especially natural language, from undue  
claims of IPR.


---4.4.2 Agreement

While I agree, I recommend a clarification in wording:

Agreement to address aliasing as a general capability rather than  
through use of a specific technical approach, such as use of DNAME  
records.

---4.4.2  Support

Isn't the issue here already covered by 4.4.1?

I am assuming that an existing domain name holder could apply, as a  
new application, for an IDN that they would then alias to their  
existing IDN if that suited their business model.  I see no reason  
why such an application would not be acceptable, though of course  
according to 4.4.1 it would not have a special status among other  
applicants in the same round.

---4.5.1

I strongly agree with the absence of a prohibition against against  
use of scripts mixing across multiple labels.  I also agree with the  
requirements for registries to prevent spoofing or visual confusion.   
I not not, however, agree with placing any other limits on script  
mixing across multiple labels.

I am, however, very wary of script mixing within a single label and  
think that it should be prohibited in all but the most limited of  
cases.  In cases where it is normal within an official written  
language, I believe it _may_ be allowed but careful consideration  
must be given in applying the exception process.

---4.5.2 Some support stmt

I think this one might belong in 4.3.x

---4.5.3

I disagree with this one and offer an alternate view.

Prohibition against non-language characters should be reconsidered  
and should only be done for provably technical reasons.  Wholesale  
prohibition of non-language characters should not be supported.   
Rather only those non-language characters that can be shown to cause  
technical problems should be prohibited.

Unicode non-language characters that do not cause technical  
difficulties should, however, only be allowed if they are defined  
within a specific script that gains a community's support.

---4.5.4

I do not support the notion of extending confusing similar to the  
phonetically similar as that will get us into a whole area of accents  
and pronunciation that I believe would prove intractable.

---4.6.1

Strongly support the option wherein the privacy concerns in respect  
to whois are given primacy.


thanks
a.