[Gnso-epdp-idn-team] Notes and Action Items - IDNs EPDP Meeting #92 - 17 August 2023

[Daniel Gluck]

Hi All,

Please find below the notes and action items from the 17 August 2023 IDNs EPDP meeting #92<https://community.icann.org/x/xoyZDg> at 12:00 UTC.

Best regards,
Ariel, Steve, and Dan


ACTION ITEMS


  *   Leadership to propose suggested revisions to the rationale of Phase 2 Recommendation 5 by incorporating the discussion around the deletion and change of the source domain name
  *   Leadership to propose an update to the source domain name definition based on discussions today
  *   Sarmad will get back to the group regarding his proposition regarding identifying one source domain under each gTLD



NOTES

  *   Roll Call and SOI Updates
  *   Welcome and Chair Updates
     *   The chair also discussed the Phase 2 draft text that staff sent for team review is due back on 22 August.
     *   Next, the chair brought up the dates of the in-person face to face meeting from December 6 to 8. An agenda will be created after the ICANN78 meeting in Hamburg. There is no location determined at this time for the F2F workshop.
     *   Finally, the phase 1 report was promised to the GNSO council in November and the chair is committed to that timeline. While it is a positive step that they have completed the initial public comment review, there is still work to be done.
  *   Continue Discussion of Source Domain Name
     *   Staff provided a refresher of the Source Domain Name concept, including a new definition for the team to consider
     *   an attendee asked about the source domain requiring being a TLD or a Second level domain
        *   Staff replied that if the source domain is identified to the registrant, it must be a domain that includes labels at the second and top levels
     *   Staff went over the proposal from a participant of the team, including the rationale that specific details are based on the registrars / registries described as the life cycle management. One key point of the proposal is that as long as the change or deletion of the source domain name does not make its registered variant domain name(s) “blocked”, it should not create potential grandfathering situations and other operational complexities
     *   An attendee asked if the usage of the domain has an effect here as it seems the source domain could be deleted, and the variants remain allocatable
     *   Another attendee said that if this change should be made, it should be made by the registrar. Previously it was mentioned that the source domain name should be jointly managed by the registrant and registrar. He also suggested the source domain should not be deleted. The source must be changed to something else and then it can be deleted
        *   The chair reminded the team that this text is not definitive and final to be accepted, just a team proposal.
        *   The author of the text mentioned there are situations where it may not be possible to delete a source domain name.

           *   An attendee in chat wrote “that should Not happen from the source from definition because all possible Variants calculated from the source. There can be two possible sources, otherwise the definition is wrong”. They continued “is the source unique ? Otherwise, how is the source determined? This is very critical”

              *   Yes, the source must be unique, per the author of the proposal.
                 *   The chair mentioned that the source must be unique to develop the domain name set.
           *   Another attendee wrote another presumption “the gTLD variant set is delegated and open for registration.”
           *   A different attendee asked, “Shouldn’t there be a source per TLD?”
              *   This is not necessarily true, but other attendees of the team but there was disagreement among the attendees.
              *   “The IDN table may be different for the variant TLDs so variant calculations under variant TLDs may not be the same” , said an attendee.
                 *   This was agreed to as correct
     *   Staff continued to walk through the slides of the proposal, including paths that source may change or be deleted and its impact on the rest of the variant domains.
        *   A different attendee asked the team to revisit the definition for Source Domain
     *   An attendee mentioned in chat that “This is something that registries can solve if they want to. I don’t think we should limit what the registrant wants to do with a variant set as long as they conform to registry policies”
        *   Another attendee wrote “Might need to think this through... would this be a bit of gaming the system and the LGR... registries can potentially do a special transfer to effect the same”
        *   The next attendee wrote “It is challenging an inherent assumption that blocked variants cannot be registered.”
        *   A different attendee wrote “While I agree with the need for flexibility and freedom, there appears to be a significant possibility of confusion for registrants as well as end-users.”
           *   They mentioned that there may be issues that pop up from this due to the complexity. The important thing here is that the registrant of the source domain name has the right to its other variant domains. That principle alone would give the registrant the comfort that no one else will take the domain names.
           *   There is a desire to not write any policies about this idea. There should be an assurance that registrants are protected against someone else registering similar domain names due to the Same Entity Principle, but no need for formal policy on the matter. It should be left to the registrant / registrar / registry.
     *   The chair mentioned that the ability to delete a source domain name is discretionary and is not substantial enough to recommend a Policy to be recommended here.
        *   There is agreement on the preliminary recommendation 5, that there needs to be a source domain defined. A question they had is if the source domain could be changed or not. They suggested not creating a policy and leaving it up to the registry. Registry will not allow a situation where the change of the source domain name renders an active domain blocked; this will trigger compliance issue regarding IDN tables.
        *   Another attendee mentioned the possibility of changing a source leading to a registered domain becoming blocked
           *   This led to a discussion about what would happen if a registry were not complying with its IDN table. This would be a compliance issue with the registry agreement. There should be no need for additional policy to ensure compliance due to this.
              *   One possible way forward would even forgo a statement that blocked variants may never be allocated.
                 *   A response for this is that it may cause confusion with resellers and registrants without that statement.

                    *   Education regarding the importance of the source domain for registrants will be important, said an attendee, to avoid misunderstandings at the time of registration.

                       *   The chair replied that this is an implementation detail and possibly not in scope for this conversation.
                       *   There was a suggestion that “the registry needs to at all times comply with its IDN tables, or maybe this already exists as a standalone recommendation”
        *   Staff asked the team if they believe that source domains must be registered?
           *   The source domain may be decided but it does not necessarily have to be registered or activated, was one opinion.
     *   Staff mentioned “This Phase 2 preliminary recommendation 5 is derived from the charter question regarding whether variant domains should have life cycles independent from one another”
     *   An attendee had a question if the source domain would be visible anywhere? How would ICANN be able to determine if a registry is in breach if they can’t see the source domain.
        *   Staff mentioned that there is a charter question that relates to this. It is a catch-all registration data modification / WHOIS clause and may be able to encompass this question.
           *   An attendee suggested adding implementation guidance about this.
     *   Going back to the discussion on if the source domain must be activated or registered, one attendee proposed that the source must be registered but does not have to be activated.  It may be in an EPP client hold state or without nameservers, but it must exist in WHOIS / escrow systems.
        *   One attendee proposed a new EPP status: “We might need something like additional info in EPP CHECK or something”
        *   There may be technical issues regarding this, cautioned one attendee.
     *   ACTION ITEM: Leadership to propose suggested revisions to the rationale of Phase 2 Recommendation 5 by incorporating the discussion around the deletion and change of the source domain name
     *   ACTION ITEM: Leadership to propose an update to the source domain name definition based on discussions today
     *   There was a discussion about the definitions around the variant domain sets. One suggestion was that each variant TLD has its own IDN table. Different variant TLD tables behave differently and the source label under one TLD could be invalid or impossible under a variant TLD because the variants are different, although they may be consistent. This may require having one source domain under each gTLD.
        *   ACTION ITEM: Sarmad will get back to the group regarding his proposition regarding identifying one source domain under each gTLD
  *   AOB
     *   A RySG member shared some additional feedback on Recommendations 7.1 and 7.3.
        *   Regarding 7.1, there was additional feedback over the SLA and if the qualifier substantially similar means the same. The RySG agrees with the SLA remaining the same.
        *   Regarding 7.3, the RySG member shared that 2012 Registry Agreement should become an addendum to a new agreement. Registry Operators from the 2012 round with potentially allocated variants based on the Root Zone LGR should not be forced to transition to a new Registry Agreement, as the 2012 RA will be encased in the new agreement. There shouldn't be two separate RAs for one RO. Having separate RAs would make it prohibitive for ROs to apply for allocatable variant TLDs. There should be a way for legacy TLDs to remain untouched, with inclusion of new specifications that could activate with TLDs that wish to activate variant TLDs.
           *   The chair asked if RySG would like the 2012 agreement to become an addendum to the new round agreement.
              *   The RySG suggested that the 2012 RA be augmented into the new agreement as a schedule
                 *   This may also need to include operators from before the 2012 round.
     *   The chair adjourned the call.


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