[Gnso-ssr] discussion -- SAC060 -- User Experience Implications of Active Variant TLDs

[Kal Feher]

Some follow up questions in line.

-----Original Message-----
From: Patrik Fältström [mailto:paf at frobbit.se] 
Sent: Tuesday, 4 March 2014 5:42 PM
To: Kal Feher; GNSO SSR List
Subject: Re: [Gnso-ssr] discussion -- SAC060 -- User Experience Implications of Active Variant TLDs

On 2014-03-04 03:55, Kal Feher wrote:
> Mike, Fellow GNSO - SSR ers,
> 
> I apologise in advance for the long reply, but you did ask a lot of 
> questions, so it's not all my fault.

Maybe it is our, SSAC, fault :-)

> It would also help if the actions were a little clearer and more direct.
> For example, the objection process comments (Recomm 2) suggest that in 
> the process of developing an IDN LGR, public comments will suffice as 
> a mechanism to manage disagreements regarding variants.

No, Recommendation 2 says that ICANN must have a known and predictable process for how to handle a disagreement. If that process is "no appeal or secondary review is possible" that might be the correct answer.

The LGR process today does not say anything about what happens if someone do disagree with an LGR.
-KF in many regions there are committees and submission mechanisms, which is why language tables change over time. We don't want that process for the root though. 

Reason for the recommendation is that you can not allow an LGR to be started to be used, and then changed, without a very detailed review of potential backward compatibility implications of the change. You might add code points (not so problematic), remove code points (not fun if you have domain names using those code points) or decide two earlier distinct code points now are the same (definitely not fun if you have to earlier distinct domain names with different holders that now end up being treated equivalent).

-KF I'm referring to the second sentence "However, each release of the integrated IDN LGR will be open to public comments prior to publication." What is each LGR group supposed to do with this advice? Are they supposed to document comments and categorise them? eg: relevant if applied to second level or lower, but not appropriate for root. I think actions from the board should be translatable to a specific action or criteria to each LGR working group.

> The Recommendation 9 status is confusing. So perhaps we need to 
> clarify exactly what this capability represents? does it represent the 
> ability to host a second TLD zone file which mirrors the first? LGR 
> capability is irrelevant in that case. does it represent the ability 
> to take registrations or at least manage (update, including 
> activation/deactivation of variants) IDNs in the TLD? <- that is a 
> significantly more difficult capability to develop and assess. Perhaps 
> conducting the PDT (recently updated) IDN test cases for all submitted 
> languages and scripts might be a useful measure. Bearing in mind that 
> the current LGRs TLD's use are likely to be very different to LGRs 
> developed for the root (yet to be completed, if I'm not mistaken).

EBERO is to be able to do whatever changes needed to the zone, and because of that it is not "only" to host a zone file. And as later discovered (Recommendation 11) that each registry is to calculate variant sets of all LGRs used by any registry used for all scripts the registry uses (not only the LGRs the registry uses), the same must be true for anyone acting as EBERO.
-KF  But what does "Closed" mean for the current status? Do the EBERO providers have registries with all LGRs currently or soon to be in use? Or does "closed" mean "we have told EBEROs to do this"?

Recommendation 11 will cause the grandfathering issue you were concerned about in the root in your earlier comment ..unless implemented straight away(less work but still too late). It ignores the reality that implemented LGRs are a choice by each TLD based on criteria important to them. If someone has made a decision to have a smaller set of variants than another TLD, they should be entitled to do so. The affect will be to homogenise IDNs with no capacity to allow for regional/dialect differences. A form of linguistic imperialism predicated on convenience? I'm wondering why strengthening regional committees for developing LGRs in cooperation was not suggested? It might allow for TLDs to consider the implications of divergent LGRs while still allowing them to represent the language as appropriate for their community.
I note that the comment to Recommendation 11 suggests such efforts are not coming soon. The longer the wait, the worse the experience for everyone if this is ever actually implemented. 


> I do note that Recommendation 4 is a little more realistic than the 
> matching recommendation (recomm 6 I think) in the original report 
> which required TLD operators to adopt LGRs developed for the root, at 
> their lower levels or show cause why. We need to have a discussion on 
> why the current situation, where TLDs can choose already adopted LGRs 
> or choose not to (reasons undefined) is perceived, on the basis of a 
> recommendation for regulation, to have failed. After all, many of the 
> evaluated TLDs used for the original report were ccTLDs, so regulation 
> is unlikely to influence them. If there are genuine failures of 
> conformity (in implementing LGRs), as opposed to educated divergence, 
> then some clear guidance will be needed in order to influence those 
> TLDs to adopt this advice.

Different TLDs will have different LGRs for the same script.

This is why SSAC say that _for_the_root_zone_ (which is the most important for ICANN), only one LGR can be used, and in reality that is the result of the integration panel working with whatever harmonization is needed.
-KF I think we are on the same page here.

   Patrik Fältström
   SSAC Chair