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

Fri Feb 28 03:35:12 UTC 2020

Thanks, Bill.

All,

I guess I am looking for answers to a few high-level questions.

In  Internationalized Domain Names draft preliminary scorecard as at 16 Feb
2020
<https://community.icann.org/download/attachments/111390697/02.%20DRAFT%20At-Large%20SubPro%20Scorecard%2016.02.2020%20-%20IDNs%20Internationalized%20Domain%20Names.pdf?version=1&modificationDate=1581914542839&api=v2>
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?

 ....*"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?

*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?

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?

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%20At-Large%20SubPro%20Scorecard%2016.02.2020%20-%20UA%20Universal%20Acceptance.pdf?version=1&modificationDate=1581914648067&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.%20DRAFT%20At-Large%20SubPro%20Scorecard%2016.02.2020%20-%20IDNs%20Internationalized%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.%20SubPro%20IDNs%20as%20at%2026.08.2019%20for%20CPWG.pdf?version=1&modificationDate=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
> ------------------------------------------------------------
>