Dear all, Please find below the notes and action items from today’s meeting on Monday, 3 April 2023 at 13:00 UTC. Kind regards, Ariel, Emily, and Steve Notes and Action Items - IDNs EPDP Call – 3 April 2023 Action Items Action Item 1: draft rec as “discounted fee” and specifically call out for comment the options considered. Rationale will also be updated to be consistent with this outcome. Action Item 2: Use “Explanation” or “Meaning” instead of “Definition” for the column header. Action Item 3: Pull in definition into Rec 1.12 Notes Roll Call and SOI Updates * None Welcome and Chair Updates * Given back and forth on list, may ask members to stay on a little bit past the scheduled time to conclude, given this should be the last meeting. * Need to conclude the question of whether an existing IDN RO that wants to apply for a variant in a future round, whether the full application fee should apply. Close off any remaining charter question discussions, e.g., A3 and D1b * There is a substantial rewrite for A3, but should not change the meaning. The updated text is regarding the EPDP Team’s answers to the charter questions, not the recommendations themself. * Given where the recommendations are now, they have progressed beyond the agreement bullets, which were written a while ago. Re-write is to sync up the language. Seeks to make clear when an applicant can still apply, even if a string is deemed to not be able to be submitted, per the algorithmic check; the applicant can then potentially challenge via the DNS stability challenged mechanism. * Recommendation 1.2 re-written to be consistent with that thinking, but hopefully in a clearer manner. * Agreement that it reads clearer, but it’s still a very long paragraph. It might make the public comment process easier if it’s broken up into discrete parts. * The public comment form does have some free-form fields. We should be careful about making the form any longer than it already is. * How much additional time is allowed for the team to review the text? We need to get materials to the team by next Wednesday. Will hopefully get materials to the EPDP Team by Tuesday/Wednesday, taking into account input from today. * Recommendation numbers will be updated. The flow will follow the New gTLD Program process, as was discussed during a previous meeting. * Regarding application fees, need to validate and gain common understanding. * Seems that there are four scenarios we need to consider. First, for an existing RO that applies for variants in the immediate next round, the fee is waived. * Second, if an existing RO applies in a future round, but not the immediate next round, there is an additional fee, but not a full base application fee. * The third scenario is for future applicants where an applicant applies for variants as well, pays a single base application fee. * Fourth scenario is future existing RO, applies in a subsequent round for additional variants, what does the fee look like in that situation? Could be an incremental fee in the future, even if not exceeding [x]. * Validating intent: an application for only variant labels, in a future round (assumption: the primary and one or more variants are delegated), the applicant would be expected to pay the same, full base application fee. * Comment - if just adding variants, should NOT pay the full base application fee. But also not free. Can consider it an “add variant fee”. * The example<https://mm.icann.org/pipermail/gnso-epdp-idn-team/attachments/20230403/21ce2...> from Michael might help with understanding scenarios, including the one just described. This falls under the variant addition base fee scenario (VAB-fee), which is different than the standard base application fee. * Several examples included to capture this VAB-fee scenario. The applicant would NOT pay the full base application fee. * Concept to consider anything above [x] as [y]. * EPDP has already agreed that there would not be a separate process just for variants. Presumably, the application for just variants would need to go through “all the steps”. This is why it seemed that the base application fee (in full) would apply. * It would seem that some elements, like review of the “applicant” would not apply. * Michael’s concept would not preclude the VAB-fee from being equal to the full base application fee amount - it’s flexible. Preference from leadership to call it a discount rather than additional fees. * Some preference for not charging the VAB-fee if under [x], even if it spans across multiple rounds. * Seems there are at least three options for applying for just variants in a future round - full base application fee, discounted application base fee, no fee. * Additional factor - an RO could drop a variant to get below the [x] threshold. Could think of treating this as an absolute number, even if variants are dropped. Does [x] refer to the number applied for or the number of variants maintained? If relative to the application number, it could carry forward. * Some concern that this conversation is getting overly complicated and should stick to principles and leave some for implementation. * Because there were consultants, fee was potentially paid by them instead of directly by the RO. Also noted that we do not know the specifics of how much the incremental cost of evaluating just a variant will be. Action item: draft rec as “discounted fee” and specifically call out for comment the options considered. Rationale will also be updated to be consistent with this outcome. * Rec 2.19 made clearer that breach of RA re: any delegated label (including variants) will affect entire set. * Rec 2.13 references the 2012 AGB to reduce potential ambiguity. May be better to reference the SubPro recommendation rather than the AGB. Discuss Section 3 and Section 5 of Initial Report Section 3: * Members have not all reviewed the glossary, so it might be helpful to just concentrate on the items that have substantive input. Would be helpful to have folks agree on list, even if they think it’s more or less fine. * Sarmad requested to identify key items: * Definition of IDN could point to RFC5890. However, reiterated that this glossary is specific to this report. Could include both elements. * General sentiment is to not try and redefine already defined terms. Existing definition comes from ICANN’s own website. * The specific concern here does not differentiate between A and U-label. * Context - the glossary is aimed at a particular audience and trends towards layman’s language, not technical language. But need to take care that we don’t contradict technical definitions. * Another item is “Delegated” which has both a technical and procedural meaning. Can include a footnote to the technical definition. * The other definitions worth reviewing are the principle-based ones like “Conservatism”. Could try and integrate input from both Donna and Sarmad. * There may be another competing principle of trying to introduce IDN variants and make them usable. * Another principle level one is the” Integrity of the Set”. May want to define what integrity means. And may also want to revisit what unity means. * Some support that the glossary should be general, not the deeper technical meaning (based on who the average reader of this document would be). The purpose is communication. Action item: Use “Explanation” or “Meaning” instead of “Definition” for the column header. * Some concern about syntax in “Label States”. Should remove ambiguity if possible, to illustrate that the label states apply to the primary and variant labels. * “Primary” is also a key term and unclear if we should reference Label, since that is not how it is used in the report. Leaving the term Label in parentheses should be ok. * “Same Entity” now includes application, legal, and operational standpoint context. Use “approved”. * “String” definition distinguishes between when it’s applied (string) and when it’s delegated (gTLD). Could point definition of “label” to “string” since they’re considered interchangeable. Noted that string is unicode but label may be a-label. Section 5: * Need for section comes from Board resolution. Recs do not need to be identical to ccPDP4, but there needs to be a justifiable reason for the difference. * The latest resolution also includes reference to explaining differences with ccPDP4. * Line 1 - difference in terminology. Not related to recommendations, only relevant to glossaries. * Line 2 - ccPDP4 also does not have a ceiling per se, but there is a requirement for “meaningful representation” requirement. * Line 3 - Consistency in the sense that both recommend grandfathering, but ccPDP4 allows for an exception. The Board might have a concern with this one? * Line 4 - The differences stem from the differences in application processes. * There is also an “Additional Topics with Differences” section that is primarily a result of differences in scope between the two groups. * In summary, the suggestion is that differences are not meaningful. Overview of Initial Report sections * Since all text is out, no need to go over this topic in full. Will just highlight more important elements and timeline. * Timeline - Aim is to get full draft out to team on 4 or 5 April, but challenged because of work on fees and glossary. * Allow for one week for team review. Must send all materials for posting on Wednesday 12 Apr. * Communications to Council specify end of April, which allows a few extra days if absolutely needed. * We might seem like we are rushing to the end. If groups think they need more time, need to let us know. Nothing raised, so it seems like the timeline is ok for groups. * For Rec 1.12, should the label states be pulled into the recommendation? Action item: pull in definition into Rec 1.12 * Section 4 is the substance of the report. Seeking agreement on the format, reviewing question A1 as an example. * Question if there is concern about all recommendations and rationale being grouped, which could make readers flip back and forth to get full context. No concerns expressed. * Will Implementation Guidance will also be captured in boxes? May want to indent IG. * Section 6 has two paragraphs that document next steps for Phase 2 charter questions. It also includes that Phase 2a recommendations might get integrated into the Phase 1 report; agreed to delete last paragraph. * One outstanding item is input from GP panel to identify [x]. Could leave for implementation. Could assign well-educated (not arbitrary) number. * Other scripts allow 2-4. * Based on conservatism, number should be as low as possible. There is an opportunity to increase in the future if no issues surface. * In the absence of hearing from Arabic GPs, suggest the team goes with 4, based on other GPs. If so, should call out that input is incoming from Arabic GP. * Other GPs may have input during public comment, not just Arabic GP. * The most any other GP allows is generally 3 (Chinese). However some exceptional cases allow for 4. AOB * No calls scheduled for the next two weeks. 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<mailto:steve.chan@icann.org> Skype: steve.chan55 Mobile: +1.310.339.4410 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...>