[Gnso-epdp-idn-team] Notes and Action Items - IDNs EPDP Meeting #95 - 7 September 2023

[Daniel Gluck]

Hi All,

Please find below the notes and action items from the 7 September 2023 IDNs EPDP meeting #95<https://community.icann.org/x/zIyZDg> at 12:00 UTC.

Best regards,
Ariel, Steve, and Dan


ACTION ITEMS


  *   Staff will review Recommendation 4.4 and draft potential language for priority for past applications in the string similarity review process.
  *   The chair asked the team to consider approaches for the string similarity review process, also in Recommendation 4.4, to clear up confusion in the event that an in-process ccTLD string is found confusingly similar to an in-process gTLD string
  *   Staff will look into the best wording for Rec 6.2 based on RFC 2119.
  *   Staff will review Final Recommendations 7.8 and 7.11 and provide language to reflect the request from the public comments about not conforming to the language in recognized data protection principles.
  *   The team will review the proposed changes for Rec 3.5 and IG 3.6.

NOTES

  *   Roll Call and SOI Updates (2min)

     *   No Updates

  *   Welcome and Chair Updates (5min)

     *   The chair welcomed everyone to the call and detailed the email that went out to the GNSO council from IDNs EPDP Staff Support regarding .Quebec. The council will have one week to review and provide feedback.

  *   Continue Review of Proposed Updates of Phase 1 Final Recommendations (Starting at 3.16) (110 min)

     *   Starting with Recommendation 3.16, the global change was made for this recommendation and sub recommendations (3.16.1, 3.16.2, 3.16.3) were added to remain consistent with formatting. A footnote was also added to reflect comments received. This received unanimous approval from the team.
     *   Rec 3.17 received an update from a team member on the new guidance from the Chinese, Japanese, and Korean Generation Panels on the status of single-character gTLDs and expect formal communications to be sent from the group on the second part of Rec 3.17. Regardless, it did receive support in chat from the team.
     *   A smaller global change was made to clarify that Reserve Names are New gTLD Program Reserved Names was made and was agreed to by the team. This was the major change reflected in 3.18-3.21.
     *   Rec 3.22 contained larger changes that are part of a pending resolution in front of the ICANN Board. Staff support will keep an ear out for any updates and provide them to the team if available.
     *   Rec 4.1 is a larger recommendation with many sub recommendations included to maintain common formatting. It also contained the smaller global change regarding Reserve Names above and removed text in 4.1.6 and 4.1.12 to give flexibility to the string similarity review panel to review applied-for strings in any number of characters against two-character ASCII combinations. It was asked from a team member if an applied-for string in the next round is found confusingly similar to a 2012 round string that is still in process and hasn't been delegated, should priority be given to the 2012 round string?

        *   The chair agreed it would be helpful to call out in a recommendation about the priority given to past rounds of gTLDs to account for the possibility posed by the team member that without an explicit recommendation that a prior application from 2012 for this round (or potentially this round for future rounds) would be skipped over by the string similarity review. It is possible that this fits around Recommendation 4.4 as it is the outcome for string similarity review.

           *   ACTION ITEM: Staff will review Recommendation 4.4 and draft potential language for priority for past applications in the string similarity review process.

     *   Recs 4.2 and 4.3 were discussed without objection.
     *   Rec 4.4 was discussed regarding the changes made and a team member brought up the potential for in process ccTLD and gTLD requests where the in process ccTLD could take precedence over the gTLD, as this is in the 2012 Applicant Guidebook.

        *   The chair asked how to account for the difference in timing between requests and what is currently in use is if the applied gTLD has completed its application process (ready to be delegated) and then the ccTLD request comes in, it is too late. If the ccTLD request comes in as the gTLD application is under consideration, then the ccTLD wins out.

           *   Another team member asked about what happens if the gTLD passes the string similarity test but the process is not finished and the ccTLD request comes across the wire?

              *   The ccTLD would proceed as the only way the ccTLD application stops is if the gTLD is completely finished and is ready to be contracted.

                 *   ACTION ITEM: The chair asked the team to consider approaches for the string similarity review process in Recommendation 4.4 to clear up confusion in the event that an in-process ccTLD string is found confusingly similar to an in-process gTLD string

     *   There was language with regard to the limited challenge mechanism in the rationale for Rec 4.4 that may need rewording in the future, but not at this moment
     *   Rec 5.1 has no changes, while 5.2-5.5 contain edits to incorporate numbered sub recommendations instead of bulleted lists and in 5.3 there are edits to language to clarify and remain consistent throughout the report. This received unanimous approval from the team.
     *   No changes were made to Rec 6.1
     *   Minor changes were made to Recommendation 6.2 in meaning, but the recommendation was rewritten to better reflect this. There was discussion over the use of “must” instead of “will” in the text, with “must” preferred by the team. “Must” was added to the text during the call, but for consistency “shall” might also be used.

        *   ACTION ITEM: Staff will look into the best wording for Rec 6.2 based on RFC 2119.

     *   Rec 7.1 contained some revised text from staff and leadership and a team member provided context for registries not wanting different SLAs for different TLDs, as there is value in consistency.
     *   A minor change was made for 7.2 without any disagreement.
     *   A substantial change was made for 7.3 with the vice chair responding that the “Amendment to Rec 7.3 is to reflect an agreed change in position requiring a new RA for existing ROs to require the same RA but adding a specification to achieve the same goal.”

        *   This was agreed to by the team.

     *   Rec 7.4 was removed due to it no longer being necessary and the following numbers were changed. Below this bullet, the new numbers are referred to.
     *   There were no major changes to 7.5 and 7,6
     *   Rec 7.7 received some revisions that were not objected to by the team.
     *   Rec 7.8’s revisions were exclusively the global change.
     *   Rec 7.9 was revised to reflect proposed edits from the public comment proceeding.
     *   The Public Comment review for Final Recommendations 7.8 and 7.11 should add the language regarding contracted parties. (Contracted parties must abide by all applicable laws and regulations…)

        *   ACTION ITEM: Staff will add draft text in the “Public Comment Review” section of Final Recommendations 7.8 and 7.11 to reflect the request from the public comments about not conforming to the language in recognized data protection principles.

     *   Rec 7.12-7.14 received minor changes without objection
     *   Rec 8.1 received no changes
     *   Rec 8.2 was discussed for the changes made based on prior comments, including that guidelines would be non-binding. There was discussion about the timeline (before or during implementation) and lack of precedence in this area. It was suggested that guidelines could evolve, but the chair answered the framework would be developed during implementation not the specific guidelines.
     *   A global change was made in Rec 8.4 and a minor wording change was made in Rec 8.5 without objection.
     *   No changes were made in Rec 8.6. In Rec 8.7 there was a minor change made to discuss the stability principle in the LGR procedure. There was also a discussion for changing “must” to “should” in the text, which is reflected in the current document.

        *   The second instance must remain ”must”

     *   No change was made in Rec 8.8.
     *   The global change was made in Recs 8.10 and 8.11. Implementation Guidance was added for 8.11 in IG 8.12 to address ICANN Org’s concern from the public comment period. The implementation guidance shifted the recommendation numbers and the numbers below this bullet are the new numbers.
     *   Rec 8.13 contained a minor wording change without objection.
     *   Rec 9.1 and IG 9.2 did not receive comments and do not contain any changes. It was noted in the rationale that some text was removed to reflect best practices.
     *   No changes were made in Rec 9.3.

        *   There was a discussion about the label state transition from “rejected” to  “withheld-same-entity” in IG 9.4 but the chair determined that at this time it is not necessary to change this transition path or delete the “rejected” label state.

  *   Review of proposed text for Rec 3.5 and I.G. 3.6 (Time Permitting)

     *   The chair discussed proposed revisions from leadership to Rec 3.5 and IG 3.6

        *   Possible outcomes were presented to the team for the implementation guidance, with the chair asking the team to consider the proposal.

           *   ACTION ITEM: The team will review the proposed changes for Rec 3.5 and IG 3.6.
           *   The chair announced that this will be discussed next week and then closed the meeting.

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