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. 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).
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.
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. Patrik Fältström SSAC Chair