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

Tue May 5 09:57:04 UTC 2020

Hi Edmon,

How would you propose to change to address the said perception? Is there
some way to clarify, say, by adding a footnote or changing the text somehow?

Thanks,
Justine
------

On Tue, 5 May 2020 at 16:43, Edmon <edmon at isoc.hk> wrote:

> I have some concern with Recommendation 4.
> The recommendation seems to expect that an IDN Variant TLD go through the
> same "application process"
> I believe, any IDN Variant TLD should only be "activated" not "applied
> for" by the same Registry Operator.
> This is consistent with how the 2012 round was envisioned and handled.
> Allowing IDN Variant TLDs to be "applied for" is problematic for the
> concept of IDN Variants I think.
> Edmon
>
>
>
> > -----Original Message-----
> > From: IDN-WG <idn-wg-bounces at atlarge-lists.icann.org> On Behalf Of
> Justine
> > Chew
> > Sent: Tuesday, May 5, 2020 10:23 AM
> > To: IDN-WG <idn-wg at atlarge-lists.icann.org>
> > Subject: Re: [IDN-WG] Request for comments to Draft Recommendations on
> > IDN for Subsequent Procedures
> >
> > 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/1uEVRugHtDTGlioo0lXBQBIYuxZIjcrolea
> > > dyAsflCxY/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.%20DRAF
> > >> T%20
> > >> > At-Large%20SubPro%20Scorecard%2016.02.2020%20-
> > >> >
> > %20IDNs%20Internationalized%20Domain%20Names.pdf?version=1&modifica
> > >> > tion
> > >> > 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--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.%20DRAF
> > >> T%20
> > >> > At-Large%20SubPro%20Scorecard%2016.02.2020%20-
> > >> >
> > %20UA%20Universal%20Acceptance.pdf?version=1&modificationDate=15819
> > >> > 1464
> > >> > 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=15819145428
> > >> > 39&
> > >> > > 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&modifi
> > c
> > >> > a
> > >> > 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.
> > >>
> > >
> > _______________________________________________
> > 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.
>
>