[Gnso-epdp-idn-team] Notes and action items - IDNs EPDP Meeting #12 (ICANN72 session) - 26 October 2021
steve.chan at icann.org
Wed Oct 27 00:53:40 UTC 2021
Please find below the notes from today’s meeting on Tuesday, 26 October 2021 at 23:30 UTC.
Ariel, Emily, and Steve
Action Item 1: The liaisons (Alireza/Anil and Dennis) will discuss where additional coordination may be needed beyond VM management, if applicable.
Action Item 2: Review the process flow and provide questions and comments before the next meeting, which should support discussions on the potential challenge mechanisms.
Notes – IDNs EPDP Call (ICANN72 session) – 26 October 2021
Welcome & Chair Updates / Roll Call & SOI Updates
* This is a working session and therefore we will not go through the background for the EPDP on IDNs.
* Because coordination between the ccNSO and GNSO was requested by the Board, we want to start with an update from the ccPDP4
Update from ccPDP4
* Kenny Hwang presented on the Purpose and the structure of the ccPDP4. This includes the sub-group Variant Management, which is already focusing on coordination with the GNSO’s EPDP on IDNs. There are two other sub-groups that are less intertwined with the GNSO’s group.
* Kenny provided progress to date on the Full WG
* Anil Kumar Jain presented on the Variant Mgmt Sub-group (which links most closely with the EPDP). The Sub-group takes into account the staff papers/TSG and SubPro recommendations as inputs. Differentiating between policy recommendations and advice to ccTLD Managers.
* Example: same entity requirements for SLDs may become a strong recommendation.
* Next step is to review IDN tables and requirements re: IDN Tables and IDN Guidelines v4.0
* De-selection of IDN ccTLD – define trigger event to cause retirement process to start. Examples include name being removed from ISO 3166 or change of script of Designated Language.
* Next steps: conclusion of VM sub-group by end of 2021/early 2022. Conclusion of de-selection by 2021/early 2022. Update basic policy for aforementioned areas afterwards. Start confusing similarity sub-group in early 2022. Stress test starting end of Q2 2022.
* Kenny discussed the work plan. Plan to publish Initial Report and Final Report as well in Q3 2022.
* We need to be sure to coordinate between the two PDPs, especially where it might extend beyond the VM mgmt sub-group.
* Question: How will the ccPDP consider the IDN Guidelines v4.0?
* Answer: Will be taken into account by the VM mgmt. sub-group. It will consider whether the changes to date will have an impact on the guidelines that were completed some years ago.
* The EPDP will also be looking at the update process for the IDN Implementation Guidelines, so this might also represent something that the ccNSO should keep an eye on.
* In the past for the ccTLD fast track, the ccTLD operators would need to present their IDN tables. This is presumably replaced by the RZ-LGR. The VM mgmt. sub-group is looking at potential requirements for IDN tables at the second-level.
* The GNSO Council just received a letter from the Board in response to the Council’s request to defer the entirety of the IDN Guidelines v4.0 until the EPDP on IDNs completes. The Council has not yet made a decision on next steps.
* Standard for confusing similarity between ccNSO/GNSO would seem to make sense to be as consistent as possible.
Action: The liaisons (Alireza/Anil and Dennis) will discuss where additional coordination may be needed beyond VM management, if applicable.
Continue deliberations on Topic A: Consistent definition and technical utilization of RZ-LGR – continue with question a3
* Reviewing a3, particularly around if the string is determined to be invalid, is there a reason not to use the eval challenge processes as recommended by SubPro?
* Staff and leadership realized it was difficult to consider what the challenge mechanisms will look like without understanding the process.
* Donna reviewed the slide, discussing the application of the RZ-LGR in the process. Important question here is what happens if a string is determined to be invalid – should they be allowed to proceed further?
* The assumptions in the possible process are based upon the 2012 practices and the SubPro recs.
* Clarified that applicants may not know background and utility of RZ-LGR, but they should understand that their string must comply with RZ-LGR.
* Staff provided an overview of the potential process for determining validity of applied-for gTLD labels.
* Starts with the simplest circumstance where a valid string is submitted and the DNS Stability Panel validates the correct application of the RZ-LGR.
* Second path is the DSP determines the RZ-LGR was applied incorrectly and that the string is invalid (potentially low likelihood).
* Third path is applied-for string is invalid, applicant can abandons application.
* Or update string to conform with RZ-LGR.
* Or move forward, after receiving warning. DSP will then check if RZ-LGR is applied correctly.
* If yes, and string is invalid, string is rejected.
* Or no, not applied correctly and the string is valid, application proceeds.
* If the application is rejected, the application could withdraw application OR the applicant could challenge the assessment of the DSP. And the DSP may refer challenge to Integration Panel or Generation Panel.
* The intention is to illustrate when and why there might be a need to challenge an outcome.
* Question: In 2012, were invalid applications allowed to be submitted?
* Answer: If memory serves, in 2012, most requirements were built into the system and invalid strings were not allowed to be submitted.
* This EPDP, if it agrees, should explicitly state that invalid IDN gTLDs can be submitted, with ample warnings.
* Hence, the question for this group is whether they can submit an invalid string and/or also challenge the invalid assessment up front (against the algorithm).
* The only challenge point (as would be similar to SubPro) seems to be in the red dotted section, after a string is submitted.
* There are two layers here to consider (IDNA 2008 standard and RZ-LGR).
* The layer for potential challenge only pertains to the RZ-LGR layer, not IDNA2008
Action: Review the process flow and provide questions and comments before the next meeting, which should support discussions on the potential challenge mechanisms.
Senior Director, GNSO Support
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>
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...
More information about the Gnso-epdp-idn-team