Re: [IDN-WG] Request for comments to IDN and UA preliminary scorecards in context to Subsequent Procedures
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 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@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@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 (contains draft SubPro WG affirmations, recommendations & implementation guidelines) - Internationalized Domain Names draft preliminary scorecard as at 16 Feb 2020 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 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 ------------------------------------------------------------
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-...> 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... 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@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@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@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-...> (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-...>
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%20ID...> 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 ------------------------------------------------------------
Comments inline below:
-----Original Message----- From: IDN-WG [mailto:idn-wg-bounces@atlarge-lists.icann.org] On Behalf Of Justine Chew Sent: Friday, February 28, 2020 11:35 AM To: IDN-WG <idn-wg@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...
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... 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@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@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@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@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.
Much obliged, Edmon. Justine ------ On Fri, 28 Feb 2020 at 11:55, Edmon <edmon@isoc.hk> wrote:
Comments inline below:
-----Original Message----- From: IDN-WG [mailto:idn-wg-bounces@atlarge-lists.icann.org] On Behalf Of Justine Chew Sent: Friday, February 28, 2020 11:35 AM To: IDN-WG <idn-wg@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...
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... 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@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@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@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@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.
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@isoc.hk> wrote: Comments inline below:
-----Original Message----- From: IDN-WG [mailto:idn-wg-bounces@atlarge-lists.icann.org] On Behalf Of Justine Chew Sent: Friday, February 28, 2020 11:35 AM To: IDN-WG <idn-wg@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...
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... 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@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@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@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@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@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.
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/1uEVRugHtDTGlioo0lXBQBIYuxZIjcroleadyAsfl... 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@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@isoc.hk> wrote:
Comments inline below:
-----Original Message----- From: IDN-WG [mailto:idn-wg-bounces@atlarge-lists.icann.org] On Behalf Of Justine Chew Sent: Friday, February 28, 2020 11:35 AM To: IDN-WG <idn-wg@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...
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... 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@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@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@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@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@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.
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@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/1uEVRugHtDTGlioo0lXBQBIYuxZIjcroleadyAsfl...
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@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@isoc.hk> wrote:
Comments inline below:
-----Original Message----- From: IDN-WG [mailto:idn-wg-bounces@atlarge-lists.icann.org] On Behalf Of Justine Chew Sent: Friday, February 28, 2020 11:35 AM To: IDN-WG <idn-wg@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...
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... 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@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@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@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@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@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.
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@atlarge-lists.icann.org> On Behalf Of Justine Chew Sent: Tuesday, May 5, 2020 10:23 AM To: IDN-WG <idn-wg@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@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@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@isoc.hk> wrote:
Comments inline below:
-----Original Message----- From: IDN-WG [mailto:idn-wg-bounces@atlarge-lists.icann.org] On Behalf Of Justine Chew Sent: Friday, February 28, 2020 11:35 AM To: IDN-WG <idn-wg@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@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@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@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@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@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@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.
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@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@atlarge-lists.icann.org> On Behalf Of Justine Chew Sent: Tuesday, May 5, 2020 10:23 AM To: IDN-WG <idn-wg@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@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@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@isoc.hk> wrote:
Comments inline below:
-----Original Message----- From: IDN-WG [mailto:idn-wg-bounces@atlarge-lists.icann.org] On Behalf Of Justine Chew Sent: Friday, February 28, 2020 11:35 AM To: IDN-WG <idn-wg@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@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@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@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@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@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@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.
I would propose a simple edit to Recommendation 4 as follows: (a) Recommendation xx (Rationale 4): IDN gTLDs deemed to be IDN variants of already existing or applied for TLDs will be not be allowed for separate application and allowed for activation only by the same registry operator [and back-end registry service provider,] implementing by force of written agreement a policy of cross-variant TLD bundling. Edmon From: Justine Chew <justine.chew.icann@gmail.com> Sent: Tuesday, May 5, 2020 5:57 PM To: Edmon <edmon@isoc.hk> Cc: IDN-WG <idn-wg@atlarge-lists.icann.org> Subject: Re: [IDN-WG] Request for comments to Draft Recommendations on IDN for Subsequent Procedures 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@isoc.hk <mailto:edmon@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@atlarge-lists.icann.org <mailto:idn-wg-bounces@atlarge-lists.icann.org> > On Behalf Of Justine Chew Sent: Tuesday, May 5, 2020 10:23 AM To: IDN-WG <idn-wg@atlarge-lists.icann.org <mailto:idn-wg@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@gmail.com <mailto:justine.chew.icann@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@yahoo.com <mailto:b_jouris@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@isoc.hk <mailto:edmon@isoc.hk> > wrote:
Comments inline below:
-----Original Message----- From: IDN-WG [mailto:idn-wg-bounces@atlarge-lists.icann.org <mailto:idn-wg-bounces@atlarge-lists.icann.org> ] On Behalf Of Justine Chew Sent: Friday, February 28, 2020 11:35 AM To: IDN-WG <idn-wg@atlarge-lists.icann.org <mailto:idn-wg@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@yahoo.com <mailto:b_jouris@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 <http://easyjet.com> than easyiet.com <http://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@gmail.com <mailto:justine.chew.icann@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@atlarge-lists.icann.org <mailto:idn-wg@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@atlarge-lists.icann.org <mailto:IDN-WG@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@atlarge-lists.icann.org <mailto:IDN-WG@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@atlarge-lists.icann.org <mailto:IDN-WG@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.
Hi Edmon, all, The SubPro PDP WG discussed your proposed amendment (put forward by me on behalf of the IDN-WG) at its most recent WG call. Allow me to summarize the outcome, 1. Firstly, there was an edit to the earlier draft Recommendation xx (Rationale 4) which essentially led to it being read as follows, but does not change the point that you (i.e. Edmon) had highlighted. Original Text: Recommendation xx (Rationale 4): IDN gTLDs identified as variants of already existing or applied for [IDN] TLDs will be allowed provided they have the same registry operator and back-end registry service provider. *This policy of cross-variant TLD bundling must be captured in relevant Registry Agreements.* 2. What the SubPro PDP WG discussed was the text submitted (on behalf of the IDN-WG), as amended to take into account the above edit. Text suggested by Justine: [Recommendation xx (Rationale 4): IDN gTLDs *deemed* to be variants of already existing or applied for TLDs *will not be allowed for separate application and allowed for activation by* the same registry operator and back-end registry service provider. This policy of cross-variant TLD bundling must be captured in relevant Registry Agreements.] And the rationale provided for this text: The recommendation seems to expect that an IDN Variant TLD go through the same "application process". An 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. 3. During the SubPro PDP WG call, there was some support for our proposed text but Leadership and staff pointed out that there is no policy for IDN gTLD variants to be activated without going through the standard gTLD application process, only that such application for a deemed IDN gTLD variant is to be restricted to the same registry operator and back-end registry service provider which already has an existing or applied for ("linked") IDN TLD. (a) Here is the context provided by staff: From: Steve Chan Date: Fri, 12 Jun 2020 at 06:10 Subject: Re: [Gnso-newgtld-wg] FW: IDN Variant - Activation or Application? To: Aikman-Scalese, Anne , Jeff Neuman Cc: gnso-newgtld-wg@icann.org Dear Anne, all, It may be helpful to review the entire set of documentation for IDN variant TLD management here: https://www.icann.org/resources/pages/idn-variant-tld-implementation-2018-07... Document three ( https://www.icann.org/en/system/files/files/idn-variant-tld-recommendations-...) on this page provides the recommendations and analysis. To your question, I think sections 3.3 and 3.3.1 are most applicable. Section 3.3 references several RFCs and SAC060 to note that a conservative approach should be taken in allocating IDN variant TLDs; just because an IDN variant can be allocated does not mean that it should be allocated. Section 3.3.1 mentions that the study recommends that the application process and fee apply to variant labels, similar to any gTLD label, which is consistent and furthers the principle of conservative allocation of variants. To summarize and in response to your questions, based on my reading, *the paper says IDN variants would be available for application (not simply activation) and only to the same entity*. Best, Steve (b) I noted that Maxim Alzoba and Rubens Kuhl (both from GNSO) offered some helpful information, namely that above position is one made and held by ICANN Org with little community consultation, and that GNSO has established a scoping team to develop policy on this issue, See: https://gnso.icann.org/sites/default/files/file/field-file-attach/idn-scopin... <https://www.google.com/url?q=https://gnso.icann.org/sites/default/files/file...> 4. SubPro PDP WG members have now been asked to consider the original text with an added sentence, Recommendation xx (Rationale 4): IDN gTLDs identified as variants of already existing or applied for TLDs will be allowed provided they have the same registry operator and back-end registry service provider. This policy of cross-variant TLD bundling must be captured in relevant Registry Agreements. This working group has not discussed the process by which an existing registry operator could apply for, or be given, an IDN variant of an existing TLD. Nor has it discussed who one would include in its application for a new gTLD its desire for an IDN Variant. *5. My question then to this group/Edmon is what is our position or reaction to the highlighted text above?* Thanking all in advance for reading this long email and for responding, Justine ------ On Tue, 5 May 2020 at 20:00, Edmon <edmon@isoc.hk> wrote:
I would propose a simple edit to Recommendation 4 as follows:
*(a) Recommendation xx (Rationale 4)*: IDN gTLDs deemed to be IDN variants of already existing or applied for TLDs will be not be allowed for separate application and allowed for activation only by the same registry operator [and back-end registry service provider,] implementing by force of written agreement a policy of cross-variant TLD bundling.
Edmon
*From:* Justine Chew <justine.chew.icann@gmail.com> *Sent:* Tuesday, May 5, 2020 5:57 PM *To:* Edmon <edmon@isoc.hk> *Cc:* IDN-WG <idn-wg@atlarge-lists.icann.org> *Subject:* Re: [IDN-WG] Request for comments to Draft Recommendations on IDN for Subsequent Procedures
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@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@atlarge-lists.icann.org> On Behalf Of Justine Chew Sent: Tuesday, May 5, 2020 10:23 AM To: IDN-WG <idn-wg@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@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@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@isoc.hk> wrote:
Comments inline below:
-----Original Message----- From: IDN-WG [mailto:idn-wg-bounces@atlarge-lists.icann.org] On Behalf Of Justine Chew Sent: Friday, February 28, 2020 11:35 AM To: IDN-WG <idn-wg@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@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@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@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@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@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@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.
Thanks Justine for the detailed report. 1&2 ok. 3. First of all, I do not agree with the staff report. We were going to address that in the IDN Variants PDP that should address the issue more holistically. So I hope SubPro would not just take the staff report as-is, but stay with what was also a hard fought battle prior to and during the 2012 round. 4&5. Some minor edits to the first sentence: ============ Recommendation xx (Rationale 4): IDN gTLDs identified as IDN Variants of already existing or applied for gTLDs will be allowed provided they have the same registry operator and back-end registry service provider. This policy of cross-variant gTLD bundling must be captured in relevant Registry Agreements. ============ For second sentence, I think it is best to avoid the phrase “apply for”, and for simplicity, I would suggest: ============ This working group has not discussed the process of allocating and delegating an IDN variant of an existing TLD. ============ For the last part, I am not sure it is true… the issue must have been discussed, even though the WG may not have come to any conclusion to it. I would suggest completely removing it. The 2012 AGB did include a question for the applicant to identify the IDN Variants though. Edmon From: Justine Chew <justine.chew.icann@gmail.com> Sent: Friday, June 12, 2020 9:57 AM To: Edmon <edmon@isoc.hk>; IDN-WG <idn-wg@atlarge-lists.icann.org> Subject: Re: [IDN-WG] Request for comments to Draft Recommendations on IDN for Subsequent Procedures Hi Edmon, all, The SubPro PDP WG discussed your proposed amendment (put forward by me on behalf of the IDN-WG) at its most recent WG call. Allow me to summarize the outcome, 1. Firstly, there was an edit to the earlier draft Recommendation xx (Rationale 4) which essentially led to it being read as follows, but does not change the point that you (i.e. Edmon) had highlighted. Original Text: Recommendation xx (Rationale 4): IDN gTLDs identified as variants of already existing or applied for [IDN] TLDs will be allowed provided they have the same registry operator and back-end registry service provider. This policy of cross-variant TLD bundling must be captured in relevant Registry Agreements. 2. What the SubPro PDP WG discussed was the text submitted (on behalf of the IDN-WG), as amended to take into account the above edit. Text suggested by Justine: [Recommendation xx (Rationale 4): IDN gTLDs deemed to be variants of already existing or applied for TLDs will not be allowed for separate application and allowed for activation by the same registry operator and back-end registry service provider. This policy of cross-variant TLD bundling must be captured in relevant Registry Agreements.] And the rationale provided for this text: The recommendation seems to expect that an IDN Variant TLD go through the same "application process". An 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. 3. During the SubPro PDP WG call, there was some support for our proposed text but Leadership and staff pointed out that there is no policy for IDN gTLD variants to be activated without going through the standard gTLD application process, only that such application for a deemed IDN gTLD variant is to be restricted to the same registry operator and back-end registry service provider which already has an existing or applied for ("linked") IDN TLD. (a) Here is the context provided by staff: From: Steve Chan Date: Fri, 12 Jun 2020 at 06:10 Subject: Re: [Gnso-newgtld-wg] FW: IDN Variant - Activation or Application? To: Aikman-Scalese, Anne , Jeff Neuman Cc: gnso-newgtld-wg@icann.org <mailto:gnso-newgtld-wg@icann.org> Dear Anne, all, It may be helpful to review the entire set of documentation for IDN variant TLD management here: https://www.icann.org/resources/pages/idn-variant-tld-implementation-2018-07... Document three (https://www.icann.org/en/system/files/files/idn-variant-tld-recommendations-...) on this page provides the recommendations and analysis. To your question, I think sections 3.3 and 3.3.1 are most applicable. Section 3.3 references several RFCs and SAC060 to note that a conservative approach should be taken in allocating IDN variant TLDs; just because an IDN variant can be allocated does not mean that it should be allocated. Section 3.3.1 mentions that the study recommends that the application process and fee apply to variant labels, similar to any gTLD label, which is consistent and furthers the principle of conservative allocation of variants. To summarize and in response to your questions, based on my reading, the paper says IDN variants would be available for application (not simply activation) and only to the same entity. Best, Steve (b) I noted that Maxim Alzoba and Rubens Kuhl (both from GNSO) offered some helpful information, namely that above position is one made and held by ICANN Org with little community consultation, and that GNSO has established a scoping team to develop policy on this issue, See: <https://www.google.com/url?q=https://gnso.icann.org/sites/default/files/file...> https://gnso.icann.org/sites/default/files/file/field-file-attach/idn-scopin... 4. SubPro PDP WG members have now been asked to consider the original text with an added sentence, Recommendation xx (Rationale 4): IDN gTLDs identified as variants of already existing or applied for TLDs will be allowed provided they have the same registry operator and back-end registry service provider. This policy of cross-variant TLD bundling must be captured in relevant Registry Agreements. This working group has not discussed the process by which an existing registry operator could apply for, or be given, an IDN variant of an existing TLD. Nor has it discussed who one would include in its application for a new gTLD its desire for an IDN Variant. 5. My question then to this group/Edmon is what is our position or reaction to the highlighted text above? Thanking all in advance for reading this long email and for responding, Justine ------ On Tue, 5 May 2020 at 20:00, Edmon <edmon@isoc.hk <mailto:edmon@isoc.hk> > wrote: I would propose a simple edit to Recommendation 4 as follows: (a) Recommendation xx (Rationale 4): IDN gTLDs deemed to be IDN variants of already existing or applied for TLDs will be not be allowed for separate application and allowed for activation only by the same registry operator [and back-end registry service provider,] implementing by force of written agreement a policy of cross-variant TLD bundling. Edmon From: Justine Chew <justine.chew.icann@gmail.com <mailto:justine.chew.icann@gmail.com> > Sent: Tuesday, May 5, 2020 5:57 PM To: Edmon <edmon@isoc.hk <mailto:edmon@isoc.hk> > Cc: IDN-WG <idn-wg@atlarge-lists.icann.org <mailto:idn-wg@atlarge-lists.icann.org> > Subject: Re: [IDN-WG] Request for comments to Draft Recommendations on IDN for Subsequent Procedures 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@isoc.hk <mailto:edmon@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@atlarge-lists.icann.org <mailto:idn-wg-bounces@atlarge-lists.icann.org> > On Behalf Of Justine Chew Sent: Tuesday, May 5, 2020 10:23 AM To: IDN-WG <idn-wg@atlarge-lists.icann.org <mailto:idn-wg@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@gmail.com <mailto:justine.chew.icann@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@yahoo.com <mailto:b_jouris@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@isoc.hk <mailto:edmon@isoc.hk> > wrote:
Comments inline below:
-----Original Message----- From: IDN-WG [mailto:idn-wg-bounces@atlarge-lists.icann.org <mailto:idn-wg-bounces@atlarge-lists.icann.org> ] On Behalf Of Justine Chew Sent: Friday, February 28, 2020 11:35 AM To: IDN-WG <idn-wg@atlarge-lists.icann.org <mailto:idn-wg@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@yahoo.com <mailto:b_jouris@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 <http://easyjet.com> than easyiet.com <http://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@gmail.com <mailto:justine.chew.icann@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@atlarge-lists.icann.org <mailto:idn-wg@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@atlarge-lists.icann.org <mailto:IDN-WG@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@atlarge-lists.icann.org <mailto:IDN-WG@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@atlarge-lists.icann.org <mailto:IDN-WG@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.
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@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@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/1uEVRugHtDTGlioo0lXBQBIYuxZIjcroleadyAsfl...
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@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@isoc.hk> wrote:
Comments inline below:
-----Original Message----- From: IDN-WG [mailto:idn-wg-bounces@atlarge-lists.icann.org] On Behalf Of Justine Chew Sent: Friday, February 28, 2020 11:35 AM To: IDN-WG <idn-wg@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...
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... 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@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@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@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@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@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@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.
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@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@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@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/1uEVRugHtDTGlioo0lXBQBIYuxZIjcroleadyAsfl...
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@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@isoc.hk> wrote:
Comments inline below:
-----Original Message----- From: IDN-WG [mailto:idn-wg-bounces@atlarge-lists.icann.org] On Behalf Of Justine Chew Sent: Friday, February 28, 2020 11:35 AM To: IDN-WG <idn-wg@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...
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...
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@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@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@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@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@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@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.
Hi Justine If you are talking about the 13:00 UTC CPWG call, I will be there. Incidentally, besides the proposal to the Global IGF that I have written about there is a session planned at EuroDIG. Lianna is the focal point. The organising team has a mailing list that anybody can join, instructions are at https://list.eurodig.org/mailman/listinfo/WS15_2020. Cheers, Roberto On 05.05.2020, at 12:00, Justine Chew <justine.chew.icann@gmail.com<mailto:justine.chew.icann@gmail.com>> wrote: 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@hotmail.com<mailto:roberto_gaetano@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@gmail.com<mailto:justine.chew.icann@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@gmail.com<mailto:justine.chew.icann@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/1uEVRugHtDTGlioo0lXBQBIYuxZIjcroleadyAsfl...
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@yahoo.com<mailto:b_jouris@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@isoc.hk<mailto:edmon@isoc.hk>> wrote:
Comments inline below:
-----Original Message----- From: IDN-WG [mailto:idn-wg-bounces@atlarge-lists.icann.org<mailto:idn-wg-bounces@atlarge-lists.icann.org>] On Behalf Of Justine Chew Sent: Friday, February 28, 2020 11:35 AM To: IDN-WG <idn-wg@atlarge-lists.icann.org<mailto:idn-wg@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...
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... 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@yahoo.com<mailto:b_jouris@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--easyet-e9a.com/>> <http://xn--et-9oa.com<http://xn--et-9oa.com/>> is even easier to mistake for easyjet.com<http://easyjet.com/> than easyiet.com<http://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@gmail.com<mailto:justine.chew.icann@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@atlarge-lists.icann.org<mailto:idn-wg@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@atlarge-lists.icann.org<mailto:IDN-WG@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@atlarge-lists.icann.org<mailto:IDN-WG@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@atlarge-lists.icann.org<mailto:IDN-WG@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.
participants (4)
-
Bill Jouris -
Edmon -
Justine Chew -
Roberto Gaetano