[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.
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. ---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.
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.
|