[IDN-WG] Request for comments to Draft Recommendations on IDN for Subsequent Procedures

Tue May 5 02:22:59 UTC 2020

I have not received any response to my request below. Does that mean no one
in this IDN-WG has anything else to say about these Subsequent Procedures
recommendations?

Justine
------

On Tue, 28 Apr 2020 at 18:10, Justine Chew <justine.chew.icann at gmail.com>
wrote:

> Dear IDN-WG colleagues,
>
> Just to follow up on the earlier conversation.
>
> We now have draft recommendations and corresponding rationales from the
> Subsequent Procedures PDP WG for our consideration.
>
> These can be viewed at this Googledoc:
> https://docs.google.com/document/d/1uEVRugHtDTGlioo0lXBQBIYuxZIjcroleadyAsflCxY/edit?usp=sharing
>
> I am hoping that folks in this IDN-WG can alert me to any concerns,
> omissions, support or needed amendments, clarity etc for any of the
> recommendations. *Please do so on via comments on the Googledoc by 4th
> May.*
>
> Much obliged,
> Justine
>
> ------------------------------------------------------------
> *Justine Chew*
> CPWG SubPro Small Team Lead
> ------------------------------------------------------------
> ------
>
>
> On Wed, 11 Mar 2020 at 22:35, Bill Jouris <b_jouris at yahoo.com> wrote:
>
>> Hi Edmon,
>>
>> 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.
>>
>> Bill Jouris
>>
>>
>> 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
>> > 2020
>> > <
>> https://community.icann.org/download/attachments/111390697/02.%20DRAFT%20
>> > At-Large%20SubPro%20Scorecard%2016.02.2020%20-
>> > %20IDNs%20Internationalized%20Domain%20Names.pdf?version=1&modification
>> > Date=1581914542839&api=v2>
>>
>> 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.
>>
>> > under
>> > '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
>> > TLDs.*
>> >
>> > *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."*
>> >
>> > Source:
>> >
>> https://www.icann.org/resources/pages/idn-variant-tld-implementation-2018-07-26-en
>> >
>> > 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
>> > scripts?
>> >
>> > *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?)
>> > <
>> https://www.icann.org/resources/pages/idn-variant-tld-implementation-2018-07-26-
>> > en>Framework
>> > 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.
>>
>> Edmon
>>
>>
>> >
>> > Thanks,
>> > Justine
>> >
>> > 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
>> > "confusables".
>> > > 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--easyet-e9a.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
>> > membership.
>> > >
>> > > Thus, please find for comments the following:
>> > >
>> > >    - Universal Acceptance draft preliminary scorecard as at 16 Feb
>> 2020
>> > >
>> > <
>> https://community.icann.org/download/attachments/111390697/03.%20DRAFT%20
>> > At-Large%20SubPro%20Scorecard%2016.02.2020%20-
>> > %20UA%20Universal%20Acceptance.pdf?version=1&modificationDate=158191464
>> > 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-
>> > %20IDNs%20Internatio
>> > >
>> > nalized%20Domain%20Names.pdf?version=1&modificationDate=1581914542839&
>> > > 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
>> > >
>> > ro%20IDNs%20as%20at%2026.08.2019%20for%20CPWG.pdf?version=1&modifica
>> > ti
>> > > 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
>> > https://atlarge-lists.icann.org/mailman/listinfo/idn-wg
>> >
>> > 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
>> > Privacy Policy (https://www.icann.org/privacy/policy) and the website
>> Terms of
>> > 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
>> https://atlarge-lists.icann.org/mailman/listinfo/idn-wg
>>
>> 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 Privacy Policy (https://www.icann.org/privacy/policy) and
>> the website Terms of 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.
>>
>