Dear all,

Please find below the notes and action items from today’s meeting on Thursday, 13 July 2023 at 12:00 UTC.

Kind regards,

Ariel, Emily, and Steve

Notes and Action Items - IDNs EPDP Call – 13 July 2023

Action Items

Action Item 1: Reformulate IG 3.8. Consider removing “standards” to reflect “criteria and tests” or “widely accepted practices”. Add public comment/consultation component. Change “may” to “should”.

Action Item 2: In respect of Rec 3.16, define “established practices”, potentially in the glossary.

Action Item 3: Update references to Reserved Names for Recs 3.18 and 3.19.

Notes

Roll Call and SOI Updates

None

Welcome and Chair Updates

Survey results – shared with this group and with Council leadership. If any requests received, will be shared with full Council. No concerning results, but good to have a checkpoint at this stage of the work.
Face-to-face timeline – Based on survey results, 6-8 (Wed-Fri) of December. Still awaiting confirmation on location. Maybe more likely to have 2.5 days.
20 July Council meeting – provide update on this EPDP Team’s timeline. In summary, no change to Phase 1, but move Phase 2 tentative delivery to October 2024.

Continue reviewing Phase 1 Initial Report public comments, starting at recommendation 3.8

Tab for Implementation Guidance 3.8: only support received.
Tab for Implementation Guidance 3.9: Note, added charter question to help evaluate public comment received. Suggested wording changes from RySG and ALAC. Suggested categorization for CCWP-HR – concerns about research and implications of the research. The rationale for this recommendation suggests that the research will not directly impact outcomes. Suggestion is also for ICANN org to communicate to the ICANN community clearly defined timeframes, processes, and opportunities for public input before engaging in any research activities under this Implementation Guidance.
Expanding on the RySG comment: it is early days for variants. In the gTLD world, limited to NGO/ONG being marketed as a technical bundle. Not variants of course, but similar conceptually since they were marketed as the same. Understanding is that they stopped this practice given the difficulties. Research is therefore very much warranted to better understand the practice.
Expanding upon the ALAC comment: if standards are established, it should be a “should”. If it is widely accepted practices, it is less strong.
In general, standards (e.g., IETF), are the result of consensus among technical experts. But the standards are recommended, but not required. Contracted parties regard the contracts and Consensus Policies as the elements they must comply with. Requesting clarity about standards potentially serving as a requirement.
Clarification is there is a difference in strength between standards and best practices.
Context is that we are discussing implementation guidance for Rec 3.7, which is about evaluating the capabilities of the applicant to manage the primary string and any variants.
Suggestion that for now, it may be best practices, but as more experience is gained, standards may be established in the future. This IG is forward-looking.
It seems that the word “standard” may a concern, given its meaning to contracted parties. This may be confused with standardizing the approach across registries and variants.
Question about whether the IG should be “may” versus “should”, and also about “from time to time”.
Suggestion that it may not just be relevant for the application process, but for the operations of the RO, ICANN will need to establish a process. It is a given that ICANN will have to do analysis and establish criteria for evaluation.
Concern with “may” because it sounds optional while “should” suggests a higher likelihood that the work will be completed. Support for the notion that “may” is weak.
Should the group consider the input from the CCWP-HR to introduce a public comment period, to make sure there is community input to any new criteria and tests or widely accepted practices? Adding this component would help relieve concerns about “should” versus “may”.

Action Item: Reformulate IG 3.8. Consider removing “standards” to reflect “criteria and tests” or “widely accepted practices”. Add public comment/consultation component. Change “may” to “should”.

Tab for Recommendation 3.10: Support for rec as written and some support with wording changes. Similar comments about terminology from RySG which are currently being discussed by the leadership team. First part of the ICANN org comment may be misplaced? Second paragraph suggests that the rationale may be limiting as written. Staff to review and consider whether the comment is misplaced.
Tab for Recommendation 3.11: Generally support for rec as written, but some concerns from ICANN org and the BC. ICANN org relates to the permutation issues arising from large numbers of variants, as noted in SAC060. In summary, while the RZ-LGR sets limits, those limits may not be adequate. There may be reason to apply further restrictions. The inclusion of up to four variants can be seen as encouraging variants, and seemingly opposed to the concept of conservatism. BC also expresses concerns about the four variants, linking it to the ccTLD fast track. Comments are attached to both the ceiling value and fees, so does it make sense to address now or later.
Reemphasis that one of the principles of RZ-LGR is to minimize the number of allocatable variants. And even for the allocatable variants, they should be considered as a maximal set, not a minimal set. The inclusion of four variants takes away a potential constraint and turns it into a potential incentive.
Question about the specific number 4. If this is not conservative, what is conservative? A reminder that this group didn’t have a solid basis for selecting the specific number 4 and was looking for guidance from the community. The purpose of this recommendation was to encourage the uptake of variants.
The challenge for this group is balancing the goal of enabling communities to gain variants, but also taking into account conservatism. Currently there is no ceiling value (since the RZ-LGR does some of the work for the EPDP Team) and potentially incentives (e.g., 4 free variants) that may not be appropriately balanced. Suggestion is to hold further discussion on this one until we also consider comments to 8.1.
Added as well that the “need” question is informational, not scored, which is also pushing against the principle of conservatism.
Reminder that there are 5 supports as is. Leave recommendation unchanged for now.
Tab for Recommendation 3.12: Most comments support rec as written. ICANN org asks for confirmation of assumption that all applicants will help bear the costs for IDNs. As part of the EPDP Team’s deliberations, it was mentioned that cost recovery is for the program overall, not on a per-application basis.
In the rationale for 3.10, it says the following: “The EPDP Team recognized that the cost recovery principle applies to the overall New gTLD Program, and the costs of running the program would be borne by all applicants collectively.” The answer to the Org assumption is seemingly yes. At a principle level, this does not seem like a problem as applicants do not all get the same level of service/evaluation for the same base application fee.
Tab for Recommendation 3.13: Most comments support rec as written. ICANN org concerns around the word “discounted” as the actual costs of evaluating just a variant string may not be as simple as assumed. As written, the rec seems to provide discretion to Org to establish what the “discount” is. No support to amend.
Tab for Recommendation 3.14: Many comments support rec as written. ICANN org concerns are similar to Rec 3.11. May need to park the PointQuebec comment as it is connected to the overall PointQuebec concerns. The BC does not support the fee waiver and believes it may create financial concerns for ICANN. Supports a reasonable fee structure based on the cost recovery principle.
Reminder that the population of existing ROs that can apply for variants is limited and actual interest from those existing ROs may be limited. The fee waiver is in recognition of the long wait for existing ROs.
Tab for Recommendation 3.15: Many comments support rec as written. Parking the PointQuebec comment again. BC concerns about prioritizing the existing IDN ROs over even other IDNs. Reiterating logic that the existing ROs, presuming they desired variants, have not had an opportunity previously. Therefore, it makes sense to give them priority since this is the first opportunity. Do we need to seek clarity about whether the BC is talking about the immediate next round? If immediate next round, the group does not want to change. If not just the next round, then it is a misunderstanding and no change seems needed.
Tab for Recommendation 3.16: Many comments support rec as written. Parking the PointQuebec comment again. Concern from the CCWP-HR about definition of “established institution”. Noted that this language comes from the Applicant Guidebook and is therefore not suggesting any change from existing practices. May be worth defining “established institution” in glossary.

Action Item: In respect of Rec 3.16, define “established practices”, potentially in the glossary.

Tab for Recommendation 3.17: All comments support rec as written. Awaiting input from GPs however.
Tab for Recommendation 3.18: Many comments support rec as written. Support for suggested change from ICANN org.
Tab for Recommendation 3.19: Many comments support rec as written.

Action Item: Update references to Reserved Names for Recs 3.18 and 3.19.

Tab for Recommendation 3.20: All comments support rec as written.
Tab for Recommendation 3.21: All comments support rec as written.
Tab for Recommendation 3.22: All comments support rec as written. Noted that there are pending recommendations from SubPro that would impact this recommendation. The group may want to consider what will happen if the recommendations are not adopted.
The Board discussion on the pending recommendations related to appeal mechanisms relate to concerns about the one size fits all approach when each process may each have nuances. The Board does not have a problem conceptually with appeals, but may have concerns specific to appeals/challenges in respect of certain areas. The EPDP Team could make a recommendation/IG specific to a challenge process for variants.
Can park the issue for now awaiting resolution on the SubPro recs. Could still consider specific parameters for challenges in this area.

AOB

None

Steven Chan 

Senior Director, Policy Development Support & GNSO Relations

Internet Corporation for Assigned Names and Numbers (ICANN)

12025 Waterfront Drive, Suite 300

Los Angeles, CA 90094-2536 

Email: steve.chan@icann.org

Skype: steve.chan55

Mobile: +1.310.339.4410

Find out more about the GNSO by visiting: https://learn.icann.org/

Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO

Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar