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

Tue May 5 10:00:30 UTC 2020

Hi Roberto,

Thanks. I believe the problem you mentioned is taken up under the topic of
Universal Acceptance which I hope to speak on tomorrow at the CPWG call.
Hope you can join that call, else please let me know what more can be done,
after said call?

Regards,

Justine
------

On Tue, 5 May 2020 at 17:10, Roberto Gaetano <roberto_gaetano at hotmail.com>
wrote:

> Justine,
> The fact that I did not reply is due only to the fact that my technical
> skills are largely insufficient to get into detail for the recommendations
> - with the possible exception of the first one - and that therefore I stay
> with what more skilled folks decide.
> This said, I am writing now because I don’t want my lack of responsiveness
> to be interpreted as a lack of interest, so I am repeating loud and clear
> that IDNs are an essential feature to be included in the next gTLD
> programme. Actually, my personal opinion is that the further introduction
> of IDN TLDs is the single major reason for expanding the domain name system.
> We have a further problem, that is the lack of “acceptance” of IDNs (and
> internationalised email addresses). This obviously limits the diffusion of
> IDNs among the users. But this should not be an excuse for not going
> forward. The risk that we face is that once the acceptance of IDNs will be
> wider - even if not “universal” - it will be too late because we have
> missed the train and the window for proposing IDN TLDs has been closed
> again.
> I am probably stating the obvious, but better repeat the obvious than
> being silent and give the impression that the issue is not relevant enough.
> Cheers,
> Roberto
>
>
> > On 05.05.2020, at 04:22, Justine Chew <justine.chew.icann at gmail.com>
> wrote:
> >
> > 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--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.
> >>>
> >>
> > _______________________________________________
> > 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.
>
>