[Gnso-epdp-idn-team] Notes and action items - IDNs EPDP Meeting #83 - 25 May 2023

Steve Chan steve.chan at icann.org
Wed May 31 19:05:03 UTC 2023 

Dear all,

With apologies for the late delivery, please find below the notes and action items from Thursday’s meeting on 25 May 2023 at 12:00 UTC.

Kind regards,

Ariel, Emily, and Steve


Notes and Action Items - IDNs EPDP Call – 25 May 2023

Action Items

  *   None

Notes

Roll Call and SOI Updates

  *   None

Welcome and Chair Updates

  *   Reminder that the Phase 1 Initial Report is out for public comment and there have been a couple of requests to extend the public comment period. Leadership is willing to extend to 19 June. No concerns expressed.
  *   Update from GNSO Council meeting – presented timeline for Phase 2 work which shows this team concluding in Oct 2025. No concerns expressed from Council. Noted that Phase 2 work has already started and making significant progress, which was not planned to start until the end of 2023.
  *   However, unknown what the comments will look like for Phase 1. Depending on the comments received, it could impact timelines for delivering the Phase 1 Final Report by Nov 2023.
  *   Also requested Council consider a F2F meeting for this EPDP Team, which requires a 6-month lead time. Looking at Nov-Dec timeframe.

Same-entity charter questions (C1, C2, C3, C3a)


  *   Slide 3: Reminder of what the charter questions are about.
     *   C1 – extending the same entity principle to existing second-level labels.
     *   C2 – Consider what the definition should be for same-entity (e.g., registrant). Also asks what the impact might be for ROs that already have a contractual provision that allows them to allocate second-level variants.
     *   C3 – Assumes that the answers to C1 and C2 are yes, what object should be used to identify entities as being the same?
     *   There is also C3a, but that is dependent upon the group agreeing that ROID is the right mechanism.
C1

  *   Slide 4: There are existing recommendations from SubPro that require second-level labels, in their various permutations (s1.t1, s1.t1v1 & s1, s1v1, … under t1, t1v1, …) must all be allocated only to the same entity. These two recommendations have already been adopted by the ICANN Board and are currently in implementation. The question is essentially, should these recommendations be extended to existing second-level labels that already exist in the DNS?
  *   What might be helpful is to understand if registry/registrar colleagues can share their experiences. How easy is it to identify when there are variants and set them aside?
  *   Clarification that for this question, we only need to consider variants at the second-level, since top-level variants do not exist. So, we only need to consider example.tld, examplev1.tld, …
  *   For the instances where example.tld, examplev1.tld are both already registered but to different registrants, suggestion that these should be grandfathered and not be forced to take one of them away from one of the entities.
  *   However, if only one of them is registered, do not see an issue with enforcing the same entity requirement going forward.
  *   Question about how difficult it is to set aside variants for second-level domains. Response is that it should not be difficult and that currently, many registries are likely already withholding variants.
  *   Support for grandfathering as removing rights from an existing registrant in favor of another may lead to legal issues. Not sure how easy it will be to identify all existing variants and maintain a database.
  *   Question about further actions registrars could take where second-level variants are registered by different registrants. One response is that registrars often just follow policies and the law, and would not do anything additional.
  *   Another question about grandfathering instances where there are two or more registrants for variants of each other. What happens on an ongoing basis?
  *   Suggestion that grandfathering should be a temporary situation that should be rectified as soon as possible. And that for any other allocatable variants, they should remain withheld so as to avoid making the grandfathering issue worse. Some others agree with this approach as allowing additional variants to be registered will perpetuate the conflict with the policy.
  *   Only when the grandfathering situation is removed should the variants become available again.

C2

  *   Slide 6 – reviewed existing contractual language that allows for the activation of variants. These requirements state that it must be the sponsoring registrar of the canonical name requesting activation and they must have the same NS resource records, but do not require the same entity.
  *   The question here is whether the same entity principle should apply to existing second-level domains where variants are held by more than one registrant. The question is directly related to much of the EPDP Team’s discussions so far in this meeting.
  *   Suggestion that allowing additional variants to continue to be registered doesn’t make the problem worse (where there are two or more registrants for variants of each other). Concerns about to withhold until the issue is resolved creates uncertainty.
  *   Noted that allowing additional variants makes resolving the grandfathering issue more difficult to resolve.
  *   There is no data available about how many instances there are of variants being held my 2 or more registrants.
  *   Registrants are potentially being disadvantaged by not being allowed to register additional variants. The grandfathering can still be unwound if the set of variants is reduced to a single registrant.
  *   Example shared for clarification: There are 4 labels that are variants of each other with two of them registered to two separate registrants. The suggestion from some is that the two unregistered variants should remain unregistered until the grandfathering need is removed.
  *   Allowing variants in this situation doesn’t change the scenario, there are 2 or more registrants for variants of each other.
  *   Grandfathering is to take account of the existing state. It should not be considered forward looking to create more grandfathering complexities. It also seems to allow for the violation of the same-entity principles.
  *   Not sure the same entity principle is broken by allowing additional variants to be registered in a grandfathering situation.
Summary of discussions to date: it seems like agreement that the same entity principle should be extended to existing registrations. And it seems like agreement that there should be grandfathering. The remaining questions are around the grandfathering rules.
  *   Good stopping point for this first discussion and pursue next meeting.
  *   There is a second piece of C2 to consider which is the impact of the same entity requirement for existing registries that already have the contractual allowance to activate variants. That contractual allowance is different than the same entity requirement.
  *   Initial thought is that since this consensus policy, ROs will need to comply with it. The existing requirements and new consensus policy will need to be consistent.
  *   Further, there is a feeling that the existing requirements are compatible – could therefore add an additional provision that requires the same registrant.
  *   Discussion whether it should be registrant or legal entity, or both. Comes back to what is commonly understood as what is a registrant. Same entity is same registrant, is the same applicant. Need to define what we mean by same registrant or same entity. Details that need to be included.
  *   A registrant (contact) can also represent a legal body or person or both.
  *   The requirement could be for the same entity, but do not specify the method to ensure the same entity.
  *   Should existing Ros that already have this contractual amendment be required to rely on the same entity principle to allocate or withhold for allocation second-level variants int the future? – answer is yes. Will discuss during leadership team where to go next.

Dialogue with SSAC SMEs


  *   Lyman Chapin, John Levine, Jim Galvin, Jiankang Yao and Jaap Akkerhuis from SSAC joined the conversation
  *   Purpose of reaching out to SSAC is following publication of the Initial Report to see if there are any security and stability concerns. Getting a heads up may facilitate reconciling public comment input.
  *   General feedback from SSAC SMEs: Although as individuals have strongly held opinions on some of these topics, as variants do not exist at the DNS level, it is not likely one where SSAC will have specific comments on many of the recommendations as these are mainly focused on the user experience and not the technical level.
  *   SSAC SME feedback: Re. Preliminary Recommendation 8.1 - SSAC60 and the follow up comments is to advocate the conservatism approach because there may be permutation effects at the top level and then the second and third level. Understanding from the GNSO deliberation where that conservatism will be achieved will be what the SSAC would be interested in seeing. Need to assess whether the measures in place will result in conservative activation of variants. Economic factor may determine number of variants that will allocated. For second level they could be sold as a package? Maybe for this a ceiling value should be considered to ensure conservatism?
  *   Chair confirmed that the IDN EPDP team has taken a conservative approach recognizing that variants have not been introduced before. Anticipate that reality will be fairly conservative as only Arabic doesn’t have a limit on the variant labels that can be available at the top-level. Have reached out to the Arabic script level to see if they could assist with what would be a reasonable ceiling.
  *   SSAC SME feedback re. Preliminary recommendation 3.7: In relation to 3.7, the SSAC comments on SubPro essentially said the same as preliminary rec 3.7 so there does seem to be consistency.
  *   Response: no upper bound on total number of TLDs is in line with the variant approach. If someone wants to pay for 1,000 variant TLDs they can do so similar to how someone can apply for 1,000 TLDs that are not variants.
  *   SSAC SME feedback re. preliminary recommendation 8.7: there needs to be a transparent process to update the LZ-LGR.
  *   SSAC will take question about providing feedback back. SSAC 60 and SAC120 did already provide input, but review if further input is deemed necessary. Domain name itself consists of top level and second level so permutations are a potential concern for SSAC. Appreciate that the GNSO has reached out in good faith to engage with SSAC on this topic.
  *   Reminder that public comment period is still open – if SSAC has further input, will try to submit by the deadline.
  *   SAC120 highlights importance of ensuring usage of variants. Preliminary recommendation 3.5 provides for explanation for why variants are needed. Others may come into play as well, for example delegation within a certain period of time.

AOB

  *   None





Steven Chan

Senior Director, Policy Development Support & GNSO Relations

Internet Corporation for Assigned Names and Numbers (ICANN)
12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094-2536


Email: steve.chan at icann.org<mailto:steve.chan at icann.org>
Skype: steve.chan55
Mobile: +1.310.339.4410

Find out more about the GNSO by visiting: https://learn.icann.org/<https://urldefense.proofpoint.com/v2/url?u=https-3A__learn.icann.org_&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpCIgmkXhFzL7ar9Qfqa0AIgn-H4xR2EBk&m=jLNFXvpu9gNdUeHi-G6sjWNCF9w4_AwhzzUDFZy2elE&s=o7Auz997kA-HPv9PHJCjFVZw7Pgo8krw4MxfqCwBrIU&e=>
Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ICANN-5FGNSO&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpCIgmkXhFzL7ar9Qfqa0AIgn-H4xR2EBk&m=jLNFXvpu9gNdUeHi-G6sjWNCF9w4_AwhzzUDFZy2elE&s=kWw4fQPNjw2lVKy1UjTxS2F0BmjEAzaDFWNmsYywbmE&e=>
Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar <https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_group-2Dactivities_calendar&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpCIgmkXhFzL7ar9Qfqa0AIgn-H4xR2EBk&m=jLNFXvpu9gNdUeHi-G6sjWNCF9w4_AwhzzUDFZy2elE&s=-L6chFfv0OperrXHHpTF722WnH3FZIutn4cS16IvpOg&e=>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-epdp-idn-team/attachments/20230531/a36af294/attachment-0001.html>

More information about the Gnso-epdp-idn-team mailing list