Emily cc as above Good morning; and thank you (as ever) for these timely and comprehensive notes; I apologies (for health reasons) that I was not on Call yesterday Best Nigel On Thu, 2 Dec 2021 at 18:47, Emily Barabas <emily.barabas@icann.org> wrote:
Dear all,
Please find below the notes from today’s meeting on Thursday, 2 December 2021 at 13:30 UTC.
Best regards,
Ariel, Steve, and Emily
*Action Items:*
*Action Item #1*: WG to review draft response to charter questions and provide input by Monday 13 December 2021.
*Action Item #2*: Staff to draft placeholder response to charter question a4 based on the analysis conducted. WG will return to close the question once it has deliberated on charter question b4.
*Action Item #3*: Leadership team to see if there are additional background materials that can be leveraged to inform discussion on charter question A5.
*Notes – IDNs EPDP Call – 2 December 2021*
*Welcome & Chair Updates*
- Two Board liaisons have been assigned to the EPDP: Akinori and Edmon. Welcome to both. - Staff sent draft language in response to charter questions a1-a3 with two weeks to consider the text. If there are substantive comments, the WG will take time on an upcoming call to discuss. Minor edits can be made offline with changes sent to the mailing list. No objections were raised to this approach. Questions can also be submitted and addressed on list.
*Action Item #1*: WG to review draft response to charter questions and provide input by Monday 13 December 2021.
*Written Early Input <https://community.icann.org/display/epdpidn/Community+Input> from SO/AC/SG/Cs*
- Brief overview of overarching comments from RySG and specific comments from SSAC members and ccNSO ccPDP4 VM subgroup on charter questions a1-a3. - Context regarding RySG comment: The RySG wanted to highlight potential dependencies specifically with respect to the same entity principle and RPMs, Transfers, etc. Regarding comments on contractual provisions, registries want to see consistency in the ways that contracts are revised and amended. - Comment on SSAC members’ response to charter question a1: Looking at this response in conjunction with the SSAC response to charter question a4, there may be a conflict in the text. It may be necessary to clarify what “Root LGR procedure” is intended to mean in SAC060: “The root zone must use one and only one set of rules for the Root LGR procedure.” - Comment on SSAC members’ response to charter question a2: It may be helpful to clarify the recommended “analysis of the delegated variant labels in ccTLDs against the most current version of LGR.” Did they mean “synchronized TLDs” or perhaps “self-identified variants TLD labels by the former gTLD applicants”? - If clarification is needed on SSAC members’ comments, the WG can request discussion with SSAC members during a WG meeting. - Note that the small number of written comments in response to the EPDP request for early input is not necessarily a “red flag.” While still a required step in the EPDP, it is largely duplicative because SO/AC/SG/Cs provide input through their representatives in the EPDP.
*Continued Deliberations on Topic A: Consistent Definition and Technical Utilization of RZ-LGR (Topic A working document: live version <https://urldefense.com/v3/__https:/docs.google.com/document/d/1I9dSd7alSvz9Z...> in Google Docs, archived versions in MS Word on wiki <https://community.icann.org/display/epdpidn/Working+Documents>)*
*Charter question A4*
- Charter was developed on the assumption that the SubPro recommendations would have been adopted by the Board and the IRT would be underway and available for coordination with the EPDP. The EPDP will flag to Council that it is working under the assumption that the SubPro recommendations will be adopted by the Board. - Slide 3: background and charter question – this charter question specifically focuses on existing TLDs that apply for a variant TLD label in a script that is not yet supported by the RZ-LGR. Staff conducted an analysis of whether there will be any such cases and therefore whether there is a problem to solve. - From one perspective, before answering this charter question, it is important to first answer the fundamental question of whether an application by an existing RO for a variant gTLD label should be treated as a new gTLD application. If the answer is yes, the charter question becomes moot. - From another perspective, all existing gTLDs are using scripts that are already in the RZ-LGR or will soon be integrated, so it may not be necessary to respond to this specific charter question. [This perspective is along the same lines as the following slides in the deck] - Slide 4: Scripts of existing gTLDs and RZ-LGR status - among scripts used in existing gTLDs, they are either integrated or expected to be integrated for RZ-LGR-5 (expected for mid-2022). - Slide 5: Further analysis of existing Latin script gTLDs – Even if the RZ-LGR-5 launch is delayed, it is unlikely that existing Latin script gTLD operators could apply for allocatable variants that do not exist. - Comment: Answering the fundamental question above (charter question b4) will help answer many other questions. - Comment: It is important to look at the history: There is an assumption that variants are essentially the same TLD, but because of the technical implementation we are unable to map the two TLDs together. In terms of applications, it should be one and the same. - Clarification: If we found that there were variants whose script was not yet supported by the RZ-LGR or won’t be through version 5, we would have the question of whether the process recommended by SubPro would apply – that is the question at hand here. The question of whether these become new applicants are not is covered in a different section of the charter. - Comment: the first sentence of the question on slide 3 states “. . . that apply for a variant TLD label. . .” therefore this group needs to decide whether there should be a process for existing TLDs to apply for variant labels outside of the rounds. This is the root of the question. - Clarification: Charter question b4 may be the appropriate place to discuss the fundamental question being referenced. - Upon further discussion, the working group agreed that this question may be moot based on the available data. The working group will not make any conclusions on this charter question and then return to this question to close it after addressing the fundamental question in b4. - There may be different interpretations of this question. Based on one interpretation of this question, the analysis indicates that this point is moot. Staff to add placeholder text responding to the charter question based on this analysis. It will note that the response to this charter question will be revisited after questions later in the charter are addressed.
*Action Item #2*: Staff to draft placeholder response to charter question a4 based on the analysis conducted. WG will return to close the question once it has deliberated on charter question b4.
*Charter question A5*
- Slide 7: Introduction to charter question A5 - Slide 8: Review of SAC060, TSG Recommendation #14, Appendix C of Staff Paper: Limiting the IDN Variant Domain Names with the Delegation of IDN Variant TLDs - Comment: This is an example of overregulation on registries. Registries have an incentive to create their own rules to make this manageable. It is impossible to make rules for this. This group can’t decide the right number or the factors as a policy matter. - Comment: ICANN is about fact-based policy making. Are there any facts supporting those ideas in the paper? If not, they are not applicable to the process. - Comment: This question is also related to the previous one and the broader question of whether a variant TLD is a normal TLD application with the same costs as a standalone (see charter section D)? If so, it might be resolved by the market. The only restriction we should have is the one imposed by the RZ-LGR. - These questions are related to questions later in the charter. - Question: Why would a registry ask for more labels than it can handle? - Slide 9-11: Additional details of Appendix C of Staff Paper: Limiting the IDN Variant Domain Names with the Delegation of IDN Variant TLDs - Comment: You need to set policy based on actors acting rationally. We should not assume that registries will apply for more labels than they can handle. The RZ-LGR already limits what is applicable. We shouldn’t artificially limit labels for delegation because there is not a fair or rational way to do it. - Comment: The smallest amount possible is not a measurable value. It may not be in the public interest to limit variants. If the SSAC limits labels in some language this may cause a scandal. - Suggestion: The staff paper explores the potential issues. Maybe the working group could look at the probability and consequences of these issues to help analyze the issues further, and if appropriate, identify potential mitigation measures. Some support expressed for this approach. - Comment: If this group is open to it, the WG could invite the integration panel to present to the WG to better understand the IP’s views. - Org comment: The advice originated from SSAC. IP has affirmed that RZ-LGR could create multiple variant labels for some string. - Comment: Support for a phase by phase opening as a conservative approach. - Comment: SSAC should present data on why and how this is a problem. - Org comment: The charter question can be strictly interpreted (a specific number) or more broadly as a question of whether there should be limits. - There are already some script communities proposing ceiling values. - Suggestion: The policy could be that although there is no limit of the number of delegations for registries, registries must take action to ensure that the variant labels are manageable for registrars and registrants. - Summary: members want to see more data that can help inform whether there should be a ceiling value or other limit.
*Action Item #3*: Leadership team to see if there are additional background materials that can be leveraged to inform discussion on charter question A5.
_______________________________________________ Gnso-epdp-idn-team mailing list Gnso-epdp-idn-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-idn-team