[IDN-WG] Request for comments to IDN and UA preliminary scorecards in context to Subsequent Procedures
b_jouris at yahoo.com
Wed Mar 11 14:34:59 UTC 2020
A couple of thoughts.
First, you speak of "IDN Variant TLDs". But the situation is rather murkier than that. As the TLD process is being implemented, there are two distinct categories of conflicts: Variants and "Confusables". The Variants label is being restricted to an extremely limited number of cases which are so overwhelmingly indistinguishable that rejection of conflicting cases can be automated. For proposed registrations which involve mere Confusables, the plan is for a Similarity Review Panel to manually compare the two TLDs.
That panel is not available for SLDs. And involves a level of judgement which may or may not be provided by whatever (if any) mechanisms the registries choose to provide for cases involving Confusables. If we keep saying TLD Variants, there is the risk that the registries will simply ignore cases with Confusables as "review not required" -- that is, the situation remains mostly in react mode.
Second, as noted the criteria for Variants are being drawn extremely narrowly. In the Generation Panel I am on, everyone has been so immersed in the various glyphs that even the non-linguists among us have what amounts to a professional knowledge of what the different diactitics are, and how they differ from one another. (We retain some divergence of opinion as to what a "reasonably careful user" will actually be able to distinguish. But nobody is under the misapprehension that the ability of normal users to distinguish similar glyphs is anywhere near that.) Plus, we are making out judgments while comparing glyphs side-by-side -- a luxury that normal users will not have. For some of us, a difference of just 1 or 2 pixels seems to be sufficient to reject a pair as Variants.
Third, the Latin Generation Panel has received direction that the sets of variants must not be "too large". That is, if there is a set of variants (generated via transitivity) which is too big, we must select one pair, no matter how similar, to demote to Confusable. It isn't clear whether the problem is here. Perhaps there is some restriction on what the software for comparing proposed TLDs can handle -- wildly unlikely as that would be with modern computing capacity. But no other justification presents itself. But whatever the reason, this further reduces the number of cases of "Variants".
At minimum, I would think that the registries' direction from ICANN when addressing SLD conflicts should include everything identified as either Variant or Confusable. That will still leave scope for problems, but at least will reduce it. And then, in my opinion that direction should take the form of an amendment to the contracts. Anything less leaves way too much discretion.
I would also note again that ICANN is publishing tables of those Variants and Confusables. Which makes us an accessory before the fact whenever a bad actor uses those tables to generate an abusive domain name. Not sure where ICANN's lawyers are on this. But having seen California courts in action on class action law suits, I worry about what will potentially hit ICANN as a result.
On Thursday, February 27, 2020, 07:56:27 PM PST, Edmon <edmon at isoc.hk> wrote:
Comments inline below:
> -----Original Message-----
> From: IDN-WG [mailto:idn-wg-bounces at atlarge-lists.icann.org] On Behalf Of
> Justine Chew
> Sent: Friday, February 28, 2020 11:35 AM
> To: IDN-WG <idn-wg at atlarge-lists.icann.org>
> Subject: Re: [IDN-WG] Request for comments to IDN and UA preliminary
> scorecards in context to Subsequent Procedures
> In Internationalized Domain Names draft preliminary scorecard as at 16 Feb
1 comment on the scorecard:
Regarding PDT, I think in general, I understand and can agree to the principal that PDT should be required. However, in the future there should be 1 PDT for delegation of ALL IDN variant TLDs alongside the primary (applied for) IDN TLD (i.e. 1 PDT for whatever TLD delegated, IDN or ASCII, with or without IDN Variant TLDs). That way it does not discriminate IDN TLDs that need IDN Variant TLDs to best serve users to have to jump through more hoops. For already delegated IDN gTLDs, I can see the value for a simple PDT.
> 'Pending Issues':
> *Point 8. RZ-LGRs limited to generating IDN variants* Q1. What about when RZ-
> LGRs are not yet in existence? Should absence lead to variant label being blocked
> or not being able to be allocated?
It needs to be blocked/reserved and not being able to be allocated, this is to avoid a situation where another IDN TLD application comes along and has a conflict with the IDN Variant. I.e. there needs to at least be a way to say if a new IDN TLD application arrives, whether it is the primary TLD (applied for string) or its IDN Variants, they must not conflict with the IDN Variants of the earlier applied for IDN TLD (and its possible IDN Variants)
> ....*"the ICANN Board resolved on 25 September 2010 that "no variants of gTLDs
> will be delegated ... until appropriate variant management solutions are developed."
> Subsequent work by ICANN organization and the community led to the identification
> of two issues: (i) there is no accepted definition for variant TLDs, and (ii) there is no
> 'variant management' mechanism for
> *The first issue is addressed by the Root Zone Label Generation Rules
> (RZ-LGR) Project
> <https://www.icann.org/resources/pages/root-zone-lgr-2015-06-21-en>. To address
> the second issue, ICANN organization is working with the community to develop
> mechanisms for IDN variant TLD implementation."*
> Q2. Are scripts for which RZ-LGRs Project does not yet cover in danger of
> potential/incidence of hijacking, abuse etc because no LGRs currently exist for those
> *Point 11. Coordination with IDN Variant Management Framework* Q3. If the answer
> to Q2 is yes, then does the IDN Variant TLD Implementation (4.0?)
> provide adequate insight and/or solution to this issue?
Yes it should. In those cases, it is a policy question whether the application can continue to be pending in the first place, and it is a technical/security issue that it cannot be delegated into the root.
> *Point 9. Bundling of SL IDN variants*
> Bill's comments below appears to raise an issue of SLD confusion involving IDN
> characters (perhaps I'm not using the correct term but Bill has described an example
> below) where harm exists - whether it is exploited through malicious acts or not.
> Q4. Do rules for bundling of SL IDN variants even consider this? Or it is an issue
> that goes far beyond bundling?
Yes it should. This was supposed to be dealt with in the ICANN IDN Implementation guidelines 4.0, which is incorporated into the Registry RAs and Registrar RAAs. However, the RySG has been raising some concerns for its adoption by the board. Once the IDN Implementation Guidelines can be updated, it should provide a much stronger framework for SLDs and bundling.
> Q5. What could be done to better address this issue? Would requiring "*registry
> contracts be modified to require that SLDs which differ only by variants (and
> confusables) be blocked*." be an acceptable solution?
Push through for the adoption of the IDN Implementation guidelines 4.0 I think is the most immediate one. This will/should also be part of the IDN Variant PDP that hopefully would come soon from the GNSO.
> On Fri, 28 Feb 2020 at 02:54, Bill Jouris <b_jouris at yahoo.com> wrote:
> > I have been working on one of the IDN project groups (the Latin
> > Generation Panel). As a result, I have seen some disconnects between
> > what we are doing there and what is discussed in the presentation.
> > Allow me to note a couple of issues I see:
> > First, there are references (for example Slides 7 and 8) to "variants".
> > At the Generation Panel, we are making decisions about what
> > constitutes a variant. There is strong push from above to make the
> > criteria as strict/narrow as possible, so as to keep the number of
> > variants low. To the point of requests to remove some variant pairs
> > which are truly indistinguishable, simple because the variant set is "too large".
> > Most of the cases of characters (letters plus diacritics in our
> > particular script, although there are also cross-script variants to
> > consider) which are readily mistaken for each other are being relegated to
> > That is, characters with differences that a few sharp-eyed users will
> > notice, even though the vast majority of users will not. For TLDs,
> > there are apparently plans to have cases involving the latter manually
> > evaluated. But whether they should be considered "variants" as the WG
> > uses the term, or how else to identify them, is not obvious.
> > Second, most of the discussion here involves TLDs. But there would
> > seem to be an even larger potential for problems with SLDs. At the
> > moment, decisions about what registrations of SLDs to allow and what
> > to block are left entirely to the discretion of the individual
> > registries. ICANN makes no requirement, either in the registry
> > contracts or otherwise, restricting the use of variants (under whatever definition).
> > There was discussion at Montreal of a recent problem involving someone
> > registering a domain name which was identical to the name used by
> > EasyJet, except that the J was replaced by an I. (The problem was
> > eventually resolved by revoking the second registration.) Even though
> > users are typically very familiar with both letters, there were a
> > number of users who were successfully scammed by the second registration.
> > How much easier would it be to sow confusion if the registration
> > involved characters that most users are NOT familiar with? For
> > example, a Small Letter I with Ogonek ( į ) occurs only in Lithuanian.
> > Like a Small Letter J, it continues below the line -- making it
> > substantially harder to spot as a substitution. easyįet.com
> > <http://xn--et-9oa.com> is even easier to mistake for easyjet.com than
> > easyiet.com was. For TLD registrations, attempted registration with
> > only this difference would be blocked. But for SLDs, it would be
> > available. And this is just one of dozens, perhaps hundreds, of opportunities for
> user confusion.
> > Note also that ICANN will be publishing tables of variants (and
> > confusables) whose use in TLDs is restricted. Those tables then
> > become a resource for any bad actor looking for ways to create an SLD
> > which will confuse users.
> > My thought is that the registry contracts should be modified to
> > *require* that SLDs which differ only by variants (and confusables) be blocked.
> > Otherwise, we are looking at significant increases in the number of
> > cases which, like with the EasyJet case, are only addressed after the
> > damage has been done. Prevention seems like a far better way to go.
> > Bill Jouris
> > From: *Justine Chew* <justine.chew.icann at gmail.com>
> > Date: Mon, 17 Feb 2020 at 14:26
> > Subject: Request for comments to IDN and UA preliminary scorecards in
> > context to Subsequent Procedures
> > To: IDN-WG <idn-wg at atlarge-lists.icann.org>
> > Dear IDN-WG colleagues,
> > Some of you will know that the At-Large Consolidated Policy Working
> > Group
> > (CPWG) is in the process of reviewing the anticipated recommendations
> > (also affirmations and implementation guidance where available) of the
> > New gTLD Subsequent Procedures PDP WG ahead of the release of its
> > draft final report later this year.
> > The process adopted by CPWG is to review a series of At-Large
> > preliminary scorecards on various topics of high and medium priority
> > from the end-users' perspective. It was agreed that assistance be
> > sought from members of the IDN-WG on the preliminary scorecards for
> > Universal Acceptance and Internationalized Domain Names, as both areas
> > are considered key foci for the IDN-WG, given the expertise and interest of its
> > Thus, please find for comments the following:
> > - Universal Acceptance draft preliminary scorecard as at 16 Feb 2020
> 8067&api=v2> (contains
> > draft SubPro WG affirmations, recommendations & implementation guidelines)
> > - Internationalized Domain Names draft preliminary scorecard as at 16
> > Feb 2020
> > <https://community.icann.org/download/attachments/111390697/02.%20DRAF
> > T%20At-Large%20SubPro%20Scorecard%2016.02.2020%20-
> > api=v2>
> > Please bear in mind that while we welcome comments in general, the
> > CPWG Small Team working to finalize and consolidate the scorecards in
> > due course will attempt to do so by considering feedback which ought
> > to be taken up (or re-taken up, as the case may be) versus which might be omitted.
> > The format of the preliminary scorecards provide an idea on the Small
> > Team's approach. We also suggest that you peruse the presentation
> > <https://community.icann.org/download/attachments/111390697/01.%20SubP
> > onDate=1566791519000&api=v2> setting out the status of SubPro WG
> deliberations against the ALAC's last public comment input as at 26 August 2019.
> > Perhaps some consideration for these preliminary scorecards can
> > factored into any planned face-to-face meeting at ICANN67.
> > Many thanks in advance,
> > Justine
> > ------------------------------------------------------------
> > *Justine Chew*
> > CPWG SubPro Small Team Lead
> > At-Large liaison for Subsequent Procedures
> > ------------------------------------------------------------
> IDN-WG mailing list
> IDN-WG at atlarge-lists.icann.org
> IDN WG Wiki: https://community.icann.org/display/atlarge/At-Large+IDN+Policy
> By submitting your personal data, you consent to the processing of your personal
> data for purposes of subscribing to this mailing list accordance with the ICANN
> Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to
> change your membership status or configuration, including unsubscribing, setting
> digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
IDN-WG mailing list
IDN-WG at atlarge-lists.icann.org
IDN WG Wiki: https://community.icann.org/display/atlarge/At-Large+IDN+Policy
More information about the IDN-WG