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

Fri Feb 28 03:55:53 UTC 2020

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--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.