RE: [gnso-idn-wg] Comments on IDN WG Outcomes Report v2.3 (long)
- To: "'Avri Doria'" <avri@xxxxxxx>, <gnso-idn-wg@xxxxxxxxx>
- Subject: RE: [gnso-idn-wg] Comments on IDN WG Outcomes Report v2.3 (long)
- From: "Ram Mohan" <rmohan@xxxxxxxxxxxx>
- Date: Wed, 14 Mar 2007 17:33:01 -0400
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.
e: rmohan@xxxxxxxxxxxx | m: +1.215.431.0958
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
Subject: [gnso-idn-wg] Comments on IDN WG Outcomes Report v2.3 (long)
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.
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.
Should probably include a definition of "keyword" solutions in the
glossary or in the statement of support. I don't remember what they
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.
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.
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.
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.
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.
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.
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
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.
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
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.
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
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.
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.
Strongly support the option wherein the privacy concerns in respect
to whois are given primacy.