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

[Daniel Gluck]

Hi All,

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

Best Regards,
Ariel, Steve, and Dan


ACTION ITEMS:

  *   The ALAC proposed language for 3.5 will be adopted, pending review by the RySG, with a possibility of further revisions over the use of “resellers” in the new 3.5.4.
  *   The team members will take the ALAC proposed language for IG 3.6 back to their stakeholder groups for review by the next meeting on 5 October. If there are no discrepancies, the ALAC IG 3.6 will be adopted.
  *   The Leadership proposed Rec 4.4 was approved unanimously by the EPDP team.
  *   The P1 Final report will be made available by ICANN Staff to the EPDP team for their review, with sections 1,3, and 5 needing input. The rest will not need input as they remain largely uncontroversial (administrative / procedural). The Chair requests review to be completed by Meeting #99 on 5 October.
  *   The team will use “recommendation” with a lowercase r in their final report.

NOTES:

  *   Roll Call and SOI Updates (2min)
  *   Welcome and Chair Updates (5min)
     *   The Chair welcomed everyone to the call and noted ICANN’s upcoming 25th anniversary
  *   Review of comments for outstanding Recs 3.5 and 4.4 and IG 3.6(90min)
     *   As a response to the request from the chair, the Registries submitted draft text for Rec 3.5 and IG 3.6, which the ALAC reviewed and proposed edits to this draft text over the email list.
        *   A team member from the RySG walked the EPDP team through their draft recommendation 3.5

           *   This was drafted with the goal to minimize applicant confusion
           *   3.5.4 and the new 3.5.5 have the goal of having the applicant confirm they understand the complexities of applying for variant domain names

              *   A participant asked about the possible redundancy of 3.5.4 requiring confirmation from the applicant that they understand the complexities as it can be assumed that if they applied in the first place, they should understand the complexities
                 *   The team member from the registries replied that the 3.5.4 works in tandem with 3.5.5 for specific confirmation of the variant complexities

                    *   3.5.4 is the direct affirmation
                    *   3.5.5 asks to detail their plan to overcome the complexities
              *   A different participant asked if the draft text changed the introductory paragraph for Rec 3.5
                 *   This was shortened by the Registries
        *   The RySG team member then walked the group through their revised IG 3.6
           *   This guidance asks for reasonable information to be provided by the applicant to evaluate things technical capabilities or the enforcement of the same entity principle
              *   There may be some overlap between IG 3.6 and Rec 3.7, IG 3.8, and IG 3.9 on the technical capabilities evaluation
        *   A team member from the ALAC walked the EPDP team through their proposed text for Rec 3.5
           *   The proposed ALAC text strikes out the RySG’s’ 3.5.4 and 3.5.5, but mainly keeps the content from the RySG’s 3.5.5 in the new 3.5.4 with some revisions included.
           *   The RySG’s 3.5.4, asking for an acknowledgement of the complexity, would be supported if it was part of the contract between the registrars / resellers and the registrants, and not in the IDNs report.
              *   A different participant commented on the operational point of view (reducing complexities over time). It may be overly broad and potentially hard to manage between the application and when the TLD is operational.
                 *   The chair mentioned that for the purpose of providing some level of comfort to the evaluators, asking if the applicant is aware of complexities is a reasonable thought, but asked the RySG if they would be agreeable to rolling up the confirmation into the description instead of having direct confirmation.
                    *   It may be agreeable for all to remove resellers but keep registrars as the focus of the revised text from the ALAC.

                       *   The first ALAC team member desired to keep text as is, due to the qualifier of “and/or” taking some of the stress/ burden off of including language that may not be completely necessary to all of the EPDP team members.
§  A team member responded that having resellers is not a deal breaker, but not ideal.

           *   ACTION ITEM: The ALAC proposed language for 3.5 will be adopted, pending review by the RySG, with a possibility of further revisions over the use of “resellers” in the new 3.5.4
        *   The ALAC then described their proposed IG 3.6
           *   The ALAC team did not agree with the proposed RySG text as there is overlap with Rec 3.7 and IG 3.8 and 3.9 over technical capability evaluation
           *   They proposed reverting back to previous text that has been updated to reflect recent discussions
              *   The major theme is to put aside technicalities and the Same Entity Rule (As it doesn’t prevent all risks) and evaluate applications submitted under the lens of Rec 3.5
                 *   The text suggests that the applicant must pass all aspects of 3.5 to proceed to the next stage of the application process. In IG 3.6.5 it is noted that the evaluation for the application for one variant label should not affect the rest of the application
                    *   A member of the RySG mentioned in chat “I'm still working through the proposed 3.6 since I'm just seeing it now, but I'm in general ok with it as well”
                    *   A participant mentioned their concern for 3.6 and how it will be implemented. The way to fill that gap would be to enhance the rationale but there may be a challenge that the implementation guidance may be difficult to follow
           *   ACTION ITEM: The team members will take the ALAC proposed language for IG 3.6 back to their stakeholder groups for review by the next meeting on 5 October. If there are no discrepancies, the ALAC IG 3.6 will be adopted.
     *   Leadership proposed text for Rec 4.4 and staff described the text again
        *   There was no dissent from the team over the text, outside of the connection to the 2012 Applicant Guidebook, so the text was updated to reduce the reliance on the 2012 AGB
        *   Also described were the newly revised Rec 4.4.4, which was reviewed by ICANN’s GDS team without change
           *   The Leadership proposed Rec 4.4 was approved unanimously by the EPDP team
  *   Review Selected Sections of the P1 Final Report (20min)
     *   ICANN Staff gave an overview of the final report, which they hope will be familiar to the team as it is organized very similarly to the initial report. During this meeting, Sections 1, 3, and 5 will be discussed
        *   ACTION ITEM: The P1 Final report will be made available by ICANN Staff to the EPDP team for their review, with sections 1,3, and 5 needing input. The rest will not need input as they remain largely uncontroversial (administrative / procedural). The Chair requests review to be completed by Meeting #99 on 5 October.
     *   Recommendation is generally spelled with a lowercase “r” in the text as to conform with ICANN standards, but if the team would like, “recommendation” could be changed to ‘output’ to reduce any confusion
        *   ACTION ITEM: The team will use “recommendation” with a lowercase r in their final report.
     *   Staff then walked through the updates for report section 1, which are available with redline text for the team to review this week
     *   Next, staff described updates to the glossary in Section 3 of the P1 final report. Redline text is available for the team’s review. Some terms of note for review include “Conservatism”, “IRT”, and “IDN gTLD”, among others
     *   Finally in Section 5, Staff described edits made to the text regarding differences from the EPDP IDNs’ policies to what the ccNSO went through with ccPDP4
        *   Context was provided for Number 4 in section 5.2 from ICANN GDS for the single character Han gTLD rationale
           *   While the EPDP supports this, the ccPDP4 does not. This difference should be considered acceptable and demonstrates a key difference between gTLD and ccTLD
     *   The chair implored the team to review this text, look for any discrepancies or typos, and please report back with any comments or suggestions that are important to them.
  *   AOB (3 min)
     *   The Chair adjourned the meeting
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-epdp-idn-team/attachments/20231002/640a0fe8/attachment-0001.html>