[Gnso-epdp-idn-team] Notes and action items - IDNs EPDP Meeting #20 - 20 January 2022

[Emily Barabas]

Dear all,

Please find below the notes from today’s meeting on Thursday, 20 January 2022 at 13:30 UTC.

Kind regards,

Ariel, Steve, and Emily



Action Items:

Action Item #1: Leadership team will update the recommendations based on today’s discussion and share with the EPDP Team for review.

Notes – IDNs EPDP Call – 20 January 2022

Welcome & Chair Updates

  *   The leadership team continues to look into reordering charter questions and will provide feedback in a week or two. They will only suggest changes to the order if they think there is substantive benefit. The EPDP Team will work through the rest of Topic A before any changes are made to the order.
  *   Update on GNSO Council Approach to IDN Implementation Guidelines v.4.0: The Council has agreed with the Board’s suggestion to continue to defer items that overlap with the EPDP. The Council drafted a letter identifying items in the Guidelines that overlap with the EDPD charter. This is a discussion item on today’s Council call and the letter is expected to be sent by the end of the week. As liaisons, Dennis and Anil will relay relevant updates to the ccNSO and ccPDP4.

Charter question A5

  *   Last week, the EPDP Team discussed with SSAC members whether there should be a ceiling mechanism for variants. This week, the EPDP Team will reflect on the SSAC’s input.
  *   Follow up on data collection exercise for this charter question: Org checked all scripts in the RZ-LGR and those that will be incorporated in next version to see if there are mechanisms in place to reduce the number of allocatable variants.
  *   Presentation of results: slide 4 lists scripts with no variant labels, scripts with no allocatable variant labels, and scripts that have allocatable variant labels.
  *   Scripts with allocatable variant labels: Arabic, Bengali, Chinese, Greek, Latin, Myanmar, Tamil.
  *   Question: Does this list only cover gTLDs and ccTLDs?
  *   Answer: The same would apply to both gTLDs and ccTLDs. It includes all scripts in the RZ-LGR.
  *   Question: What do we have these three categories listed on slide 4? Is the categorization a technical decision or a policy issue?
  *   Two distinctions: First is the question of variants versus no allocatable variants (column 1 versus column 2). This depends on the judgment of the script community and the way they define variants for the script. For those scripts that have variants, there is the question of whether they are allocatable (column 2 versus column 3). The question about whether they are allocatable is primarily an issue of usability. Once you define something as a variant and determine that it will be treated as such, the security aspect is contained, but the usability aspect is not. Allocation may be appropriate for usability reasons.
  *   Clarification: The security challenges are the same for column 2 and 3, arising from the fact that there could be code points that are the same within a script or between scripts. By declaring such code points as variant code points, the security issues are addressed in both column 2 and 3. We may want to have them as allocatable because of usability requirements.
     *   Question: Is there a reason to think that security issues might change as we add more scripts and that security panels will need to reassess allocatable variants?
     *   Clarification: When saying that the security issues are addressed by considering the labels variants, this is referring to security issues as defined in a limited context – those with respect to “same” code points. It does not address all possible security issues, for example those related to string similarity.
  *   Comment: Evaluation at the root level is to address similar looking TLDs. Providing an example of the difference between allocatable and non-allocatable, in Chinese U+39DF = U+64D3 are considered equivalent. If you apply for the TLD to the left, the one to the right can’t be applied for independently. The question is whether the two can be allocated to the same entity. The question is whether the label stands on its own and is unique. If it is not, an application for the TLD should fail.
  *   Org data collection: Looking at scripts in column 3 on slide 4, org went through existing list of TLDs which are delegated and ran them through the RZ-LGR to see how many variants are created. See slides 5-6. Most scripts have been able to put a reasonable ceiling on the number of variants. There are at least two scripts – Arabic and Chinese that might create an unanticipated number of variant labels.
  *   Question: Is the analysis in slide 4 an official analysis?
  *   Answer: ICANN org staff collated information from the RZ-LGR proposals for use by this group.
  *   Question: For the Latin script proposal, does the analysis take into account public comments that have been received.
  *   Response: Yes, the public comments have been taken into account and they don’t impact definitions of allocatable variants.
  *   Comment: The SSAC members seemed to agree that we shouldn’t come up with an arbitrary limit/ceiling value but focus on evaluation criteria in order to understand that the registry can manage any issues that arise with variants.
  *   Question: Do the Registries and Registrars have insight into the challenges that arise with the bundling exercise?
  *   Comment: When you apply for the TLD, you shouldn’t automatically be granted variants. You should be protected against other applicants obtaining variants.  If ICANN wants to offer variants, from a Registry perspective and a DNS perspective, that’s a separate zone and there is maintenance of two zone files involved. It’s two separate TLDs that the Registry needs to facilitate and operate.
  *   Comment: In general, the concept of IDN variants is not “look alike.” In Chinese, up to 5% of users will type the variant. It’s not just an issue of protection, it’s also an issue of usability, at least in the Chinese case.
  *   Comment: Agree that we shouldn’t automatically give applicants variants, but the question is whether there should be a limit.
  *   Org comment: When we are generating allocatable variants through the RZ-LGR process, even though panels work to manage the number of allocatable variants, the process still over-generates as a byproduct of making some of the solutions work. When people use variants, they do it from a language perspective. Since the RZ-LGR is script based, variants are generated with code points across languages in the script. Therefore, not all allocatable variants are equally usable.
  *   Questions: Should further guidelines be developed and if so, should the working group provide recommendations and/or implementation guidance for those guidelines?
  *   Summary: This is a limited issue impacting a limited number of scripts. We are not recommending a ceiling value. There is some support for idea that this is something for the market to provide for. We may come back to put some ideas in place for the guidelines with input from the Registries and Registrars.

Charter question A6

  *   Org question: The are a set of variants labels that are blocked. There will be a smaller set, allocatable to the same applicant. There will be an even smaller set that will be delegated variant labels. If a variant label or string is delegated, it has a high stability bar. It should remain delegated unless there is an extreme circumstance. Allocatable variants are not yet in the root, so changes there may be less critical. Since for blocked strings are not able to be used, changes there are even less critical. For recommendations 1.4 and 1.5, we talk about variants – do we want to differentiate between these three groups?
  *   Question: What are the implications of the different buckets referenced above as they apply to recommendations 1.4 and 1.5?
  *   Clarification: If a variant TLD was delegated and in the root and there is a change in the RZ-LGR saying that that variant should be blocked, or that it is no longer a variant, it should be grandfathered. But if the variant is blocked and then it becomes allocatable, that doesn’t create as significant and issue compared to changing something that is in the root zone and delegated. The categories speak to how much of a stability impact that change can have on the root zone.
  *   Comment: Suggest restricting these recommendations to delegated and allocated variants and not address blocked variants. There is no harm done if the blocked variant is taken away due to a change.
  *   Support expressed for limiting the recommendations to delegated and allocated variants.
  *   Suggestion to use “variant labels” instead of “variants.”
  *   Question from org regarding recommendation 1.6: RZ-LGR has a built-in stability clause. Would you still want to go back and update RZ-LGR procedures? Additional comment: It may not be possible to anticipate all applicable circumstances that would result in an update to the RZ-LGR.
  *   Comment: We did think some elaboration of the circumstances would be helpful for predictability.
  *   Question regarding 1.5: what are we trying to say by “extremely strong”? Are we trying to say that there are circumstances where the presumption could be rebutted?
  *   Question: After the public comment process, will it be the panel that makes the decision about grandfathering?
  *   Clarification: Determining whether a specific label should be delegated in the root zone is outside the purview of the Generation Panels, as their responsibility is currently defined.
  *   Comment: This group can set a policy that if there is a change, an existing TLD is grandfathered. The question is if there is a presumption, what if anything can result in an exception.
  *   Comment: The Generation Panel does not have the power to change Registry contracts as currently set up. Contracted parties have little reason to agree to change this.
  *   Suggestion: Grandfathering should be absolute in recommendation 1.5.
  *   Suggestion: in recommendation 1.5: "except as set forth in 1.6, all existing gtLDs…….will be grandfathered."
  *   Question: Can we seek public opinion before granting grandfather status?
  *   Response: This may be covered in recommendation 1.4.
  *   Comment: This will be implemented in contracts. We shouldn’t give a panel power over contracts they are not a party to. It’s ok for the panel to make a recommendation, subject to a process between ICANN and the Registry. But the panel is not a party to the contract.
  *   Comment: Further discussion may be needed about what that process would be following the recommendation from the panel.
  *   Summary: Recommendation 1.5 to be updated to say that the TLD will be grandfathered, except as set forth in 1.6. Additional edits may be appropriate for 1.6.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-epdp-idn-team/attachments/20220120/352b4880/attachment-0001.html>