Dear all, 

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

Kind regards,

Ariel, Emily, and Steve

Notes and Action Items - IDNs EPDP Call – 26 January 2023

Action Items

Action Item 1: Staff will seek to integrate changes as listed on slide 5. EPDP Team members will be asked to review redlined changes stemming from this input.

Action item 2: Staff to develop draft Implementation Guidance that ICANN is to maintain a list and allow for it to be available to the public. Group will need to understand and explain rationale for creating a public record.

Action item 3: Staff to seek clarity from ICANN org about what “revoked” means

Action item 4: Develop Implementation Guidance to manage variants of existing gTLDs via addendum/Spec.

Notes

Notes – IDN EPDP – 26 January 2023

Roll Call and SOI Updates / Welcome and Chair Updates

• Happy Lunar Year and happy Australia Day!
• Hadia Elminiawi has been changed from Observer to the ALAC Member

Review spreadsheet of ICANN org input [docs.google.com] and staff assessment of “low-hanging fruit”

• We’ve reviewed pieces before (e.g., Objections, String Sim) but today is first opportunity for systematic review of all input.
• ICANN org reviewed a subset of draft recs that were considered stable at the time of transmission. The rest of the recs can be considered by ICANN org directly during public comment, if necessary.
• Reviewing slide 4 – Overview of which input appears to require EPDP Team deliberations: the ones in red.
• This includes Rec 1.5; Rec 1.12; Rec 1.13; Rec 2.1; Rec 2.2; Rec 2.3; Rec 2.4; Rec 2.6; Rec 2.8
• Leadership and Staff team provided initial assessment of which input seems to require deliberations or not: https://docs.google.com/spreadsheets/d/1PwsbeW2Ihw_qJNzVEnPs-9uW3ZaMZ19oToEhaYMwkB4/edit#gid=1204738441
• The input marked as “No” are suggested to not need deliberations and can presumably allow for redlines to be incorporated to address the input.
• Reviewing slide 5 – Input that may not require discussion
• There are some general inputs that have been applied to the relevant draft recs, for completeness.
• Observations - general agreement with assessment of “No” though one observation regarding IDN gTLD versus gTLD. Generally, it’s important that we are precise in our terminology. This is something we need to all be aware of as we draft our Initial Report.
• Observation – Changing of “activate” type terms to “apply” has been discussed by this group. It is to help differentiate between variant gTLDs following a simpler path by being included with the primary string versus a fuller application process. This comment is in line with the previous comment – we need to be careful and purposeful in our changes, it’s not just a global find and replace.
• Reminder that the text in the slide is highly summarized. Also noted that the specific redlined changes made to the text will also require EPDP Team review.
• Specifically, to the point about “activate” versus “apply” it appears that nearly every step of the SubPro application and evaluation process is relevant and a standalone process is not possible. In addition, “activate” is only after the other steps have taken place, including pre-delegation, contracting. In addition, “activation” in a technical context, has a common meaning that applies to all TLDs, not just variants.
  • This is a reminder that the EPDP Team has committed to developing a glossary.
• “To clarify, my observation is a reaction to Org’s suggestion “to change all instances in the initial report to the same term”. So I guess, if we wanted to go this route, the more inclusive term should be used e.g., gTLD.”
  • A reminder that the specific text should be reviewed in a purposeful way, not just a global replacement. There may be instances where we want to differentiate “IDN gTLD”
• A4 - Update reference to “RZ-LGR-4” to “RZ-LGR-5” or later developed version when applicable. This is just to reference the current version and future versions.
  • Question if there is a conflict between input to A4 and Rec 1.7. Need to make sure we’re not hard-coding a certain version. There may be a reason to reference a specific version if we’re looking backwards.
• Maybe we don’t need to review in detail. Participants can take a moment to review and determine if there are any questions or objections.

Action Item 1: Staff will seek to integrate changes as listed on slide 5. EPDP Team members will be asked to review redlined changes stemming from this input.

• Reviewing slide 6 – Input for A5 – Rec 1.5
• Comment 1 on the slide is about clarification of roles (Org is responsible for implementation and IRT helps validate implementation) and also, whether Org is responsible for updates to the Guidelines from time to time. May want to consider how IDN Implementation Guidelines are to be updated. Could potentially even integrate the best practice guidelines into the IDN Implementation Guidelines, which would allow the best practice guidelines to follow the same procedure.
  • Potential concern, stemming from the fact that IDN Implementation Guidelines are contractually obligated. Would need to understand how best practice guidelines would fit in that structure.
  • Noted that prior to the next round, we might not actually know what the best practice guidelines are for variants; it might need to wait for the next next round. Noted that this guidance should be available before the immediate next round.
  • Observation that this question is generally about ensuring there is a clear scope. Right now, it appears broad (e.g., about ensuring a consistent user experience).
• Reminder of the reason why Rec 1.5 is under A5 – since we are not setting a ceiling value, the group thought having some guidelines will help ROs manage the variant set better.
• Comment 2 on the slide is about “consistent user experience”.
  • Maybe the goal here isn’t about consistent user experience. Is there a better terminology/phrasing that can be used to reflect what this group wants to accomplish?
• Comment 3 on the slide is about scope, whether it should be broad to include UA or narrow, to just be about registries and registrars.
• Comment 4 on the slide suggests changing to implementation guidance since there does not appear to be a requirement.
• Suggestion to take to the list…
• Reviewing slide 7 – Input for A9 0 Rec 1.12
• Comment 1 is regarding maintenance of the label states. Would appear to also apply to Rec 1.13. Is the intention to keep a publicly available list that is actively maintained? Including blocks would greatly expand the maintenance needs.
• There is currently no similar system since IANA only manages delegated strings. However, may want to consider integrating with IANA. Or, it may not be required to maintain a public list.
• The group believes there is value in having the list publicly available.
• May want to include records of change as well.

Action item 2: Staff to develop draft Implementation Guidance that ICANN is to maintain a list and allow for it to be available to the public. Group will need to understand and explain rationale for creating a public record.

• Reviewing slide 8 – Input for A10 – Rec 1.13
• Comment 2 is about maintenance of variants if a primary label is revoked. If there is no primary label this seems to mean there is no set, so what is there to track?
• Need clarity on what “revoked” means. Reminder that the primary string “drives” the contract, with the variants being included in the single RA. If the primary label changes states from delegated or allocated to withheld-same-entity, what happens?
• Variant label dispositions are calculated by the primary label. Change in primary label can change the variant set. Some agreement that the primary label has a special status as the driver of the set.
• Need to clarify - A voluntary removal from the root of the primary should apply to all variants. A change deriving from changes to the RZ-LGR should follow the grandfathering procedure.

Action item 3: Staff to seek clarity from ICANN org about what “revoked” means

• Reiterating that the ICANN org input is about the implications if the primary string is “un-delegated” – what happens to the variants?
• Question about whether the EPDP Team’s assessment that primary and variants can be delegated in the order that the applicant wishes, whether that would impact this question. The “allocation” versus “activation” seems applicable here. The question can be considered in the context of a primary string not being allocated/contracted.
• Take discussion to the list.
• Reviewing slide 9 – Input for B1 – Rec 2.1
• Comment that it’s a bad idea that the same entity principle apply to all existing gTLDs. This question seems to make the single RA concept even worse.
• Can potentially address this question by suggesting an addendum or a new specification. This could appear to be addressed with Implementation Guidance. Support in chat from other members to this idea.

Action item 4: Develop Implementation Guidance to manage variants of existing gTLDs via addendum/Spec.

AOB

• Reminder that approximately a week remains for the EPDP Team to provide input to draft recommendation language.
• Reminder that the week of the 9^th, the meeting will likely be cancelled because of the ICANN org All Hands.
• Comment from the Board liaison – reminder to account for divergence between IDNs EPDP and ccPDP4. Noted 4-5 areas that will be communicated more formally to this group.
• Invitation to join ccPDP4 stress test exercise. The use case is the base parameters of the delegation have changed.

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