[IDN-WG] Request for comments to IDN and UA preliminary scorecards in context to Subsequent Procedures

Fri Feb 28 04:03:26 UTC 2020

Much obliged, Edmon.

Justine
------

On Fri, 28 Feb 2020 at 11:55, 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.
>
>