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

[Patrik Fältström]

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 291 bytes
Desc: OpenPGP digital signature
URL: <http://mm.icann.org/pipermail/gnso-ssr/attachments/20140304/0232346a/signature.asc>