Dear All, Please find below the notes from today’s meeting on Friday, 17 December 2021 at 13:30 UTC. The slides from today’s call are attached. As we won’t have a meeting next week, we wish everyone a wonderful holiday season and happy new year! Thank you for all your hard work in the IDNs EPDP effort, and see you online soon in 2022. Best Regards, Ariel, Steve, Emily Action Items: Action Item #1: EPDP Team members to review proposed alternative phrasing for Rec 1.2 (see below) and indicate prior to the next meeting whether there are any concerns. Rec 1.2: SubPro’s limited challenge mechanism for DNS Stability Review applies in cases where the applicant believes that the label is valid as per the RZ-LGR and that the DNS Stability Panel has incorrectly assessed the label as "invalid", thus resulting in the application having been incorrectly disqualified. Notes – IDNs EPDP Call – 17 December 2021 1. Roll call & SOI updates 2. Welcome & Chair updates 3. Scheduling: No call on 23 December. Resume on 6 January? · This is the last meeting before the end of the year – no meeting next week. · Intent is to resume on 6 January. 4. Revisit responses to charter questions A1-A3 · A1-A3 proposed recs were sent to the list – no comments received so far. Will move forward with these. Only small team to 1.2 based on input received. · This is the proposed alternative phrasing for Rec 1.2: SubPro’s limited challenge mechanism for DNS Stability Review applies in cases where the applicant believes that the label is valid as per the RZ-LGR and that the DNS Stability Panel has incorrectly assessed the label as "invalid", thus resulting in the application having been incorrectly disqualified. · Alternative language translates the spirit what has been discussed – challenge to the application of the RZ-LGR, not the RZ-LGR itself. 5. Continued deliberations on Topic A: Consistent Definition and Technical Utilization of RZ-LGR (Topic A working document: live version [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1I9dSd7alSvz9ZFo0SRxEJdbvTXuYKxfZpxcKVhig96o/edit__;!!PtGJab4!vcnQGtbcRGHPTVPWJVwRt1LeYQVMwQNE0jAcVsDqSXYh8affMxtKqjp1Vj6Km67q7QobafSzRA$> in Google Docs, archived versions in MS Word on wiki<https://community.icann.org/display/epdpidn/Working+Documents>) · A6 – a bit more challenging to reflect the conversation in the recommendation language but leadership and staff are working on draft recommendation language. Intent to review this language during the next meeting in January. · A8 – relates to other policies (catch all question), skipping for now. If anything comes up during the discussions that fits in the A8 category it will be parked so that later in the discussions the group can come back to these. a. Charter question A9 b. Charter question A10 – What is the procedure to change the label status for individual variant labels? · A given label in an IDL set may be in one of the following non-exhaustive status: delegated, withheld-same-entity, blocked, allocated, rejected. The WG and the SubPro IRT to coordinate and develop a consistent definition of variant label status in the IDL Set. · Variant labels may take a range of possible states and corresponding actions. A variant management mechanism could encompass both active use of labels and prevention of labels from use in the DNS. · Consistency: have consistent understanding of what different label states entail and use consistent terminology for defining them. · Label states result in different user experiences and impact various Internet stakeholders: o ICANN o Registry Operators o Registrants o Software developers o Law enforcement and security o End users · Ensure the stable and secure operation of the DNS and avoid failures related to DNS resolution or inconsistent resolution. · Integrated Issues Report – a study of issues related to the Management of IDN Variant TLDs (Feb 2012). Some suggestions what the label status could be: o Blocked o Withheld o Allocated o Activated / Active o Delegated o Mirrored · Variant Management Staff Paper – section 3.4 TLD Label States (Jan 2019). Proposed label status: o Blocked o Withheld-same-entity o Rejected o Allocated o Delegated · The list of possible states in Staff Paper was built on the earlier work done in the Integrated Issues Report. Proposed label status is a refinement of the previous work. EPDP Team should consider developing its recommendations based on this latest work. · See also the proposed definition details that can be found in the staff paper: o Blocked: A status of some label with respect to a zone, according to which the label is unavailable for allocation to anyone. The term “to block” denotes the registry taking this action. o Withheld-same-entity: label is set aside for possible allocation only to the same entity of the other labels in the variant set. This is a special case of “withheld”, with the condition made explicit. Note that this status does not guarantee that the label in question will in fact be allocated. o Rejected: A rejected label is set aside on administrative grounds outside the ordinary LGR procedures. Labels that cannot be allocated on visual confusability grounds based on the string similarity review step in the TLD application process, are also Rejected. If a single label in an IDL set is Rejected, it can return to Withheld-same-entity, but the condition is only satisfied I the Rejected status can be removed. o Allocated: a status of some label with respect to a zone, whereby the label is associated administratively to some entity that has requested the label. This term represents the first step on the way to delegation in the DNS. Whne the registry allocates the label, it is effectively making a label a candidate for activation. Allocation does not, however, affect the DNS at all. o Delegated, A status of some label with respect to a zone, indicating that in that zone there re NS resource records at the label. The NS resource records create a zone cut, and require an SOA record for the same owner and name and corresponding NS resource records in the subordinate zone. · See also the example on slide 6 on how different status work. · Possible label state transitions are outlined on slide 7 · Question A9 – Do you agree with the label states and their definitions proposed in Staff Paper? · Question A10 – Do you agree with the label state transitions between states defined in the staff paper? · The original idea was that the EPDP Team and the SubPro IRT would coordinate on this question, but there is no SubPro IRT yet so EPDP Team will go ahead and make assumptions about what the SubPro IRT thinking is likely be. · Are there any other definitions, for example from ccNSO or GNSO, that should be considered by the group? The Integrated Issues Report included ccTLDs and gTLDs so originally community looked at six of types of statuses which were consolidated into the ones that are included in the Variant Management Staff Paper. There are also other terms that have been used, for example synchronized and bundling. Staff paper focused on current state and tried to simplify by suggesting a set of terms that represent the different states that are possible. · If there is a change of service provider, and if the gaining service provider is not willing to support the variant set, one of those variant TLDs in the set would need to go from delegated to allocated but that would be a trigger event that may need to be captured somewhere. May be a rare case. In this case it would also be a transitional state – which would also include sunsetting of the TLD. This is not a straightforward process as at the moment an undelegated TLD would go to EBERO and all the variants would also be undelegated. If the team is of the view that it should be possible to only undelegated one variant TLD, that would need to be a broader discussion and decision as this could result in a fragmentation. · Suggestion to consolidate further – allocated is a transitional or temporary state, which could be a sub-status of withheld-same-entity. From a gTLD side this is indeed transitional even though there are certain elements that come into play. It is similar in the ccTLD space as there are also two steps (string evaluation and delegation). String evaluation is here considered similar to allocation in a gTLD context and is a significant milestone. Need to consider that this framework is designed for both ccTLDs and gTLDs. Delegation could happen several years later and not immediate. · To what extent does allocated relate to allocatable? Allocatable = withheld-same-entity. “Allocated” in this context means the TLD application passed the evaluation and is “approved for delegation in the DNS root” · A rejected status will be kept until the ground for rejection has been removed. · Consider a schema perhaps like this: o Blocked o Withheld-same-entity (allocated) o Withheld-same-entity (rejected) o Withheld-same-entity o Delegated · Are the label status something that the ccNSO is also considering for ccIDNs? Have not discussed this question yet, but will soon. May need to make this specific to gTLDs as the cc process runs slightly different? Scope of this effort is gTLDs but liaisons should see if there is a common ground, if not identical so important to coordinate with ccNSO. · Have noted to the Council that charter implies that SubPro IRT would be in existence, but that is not the case, but will not hold up work but will call out that certain assumptions are made because SubPro IRT is not in existence yet. · How can one look up which “same entity” is eligible for that string, what is a variant of and what is the status? May have missed this question in the charter. If you think this is useful, team could include implementation guidance to update the tool accordingly. TLD entity information is already available in IANA Whois. Maybe this could be included in the catch all question for the EPDP Team to address? · At some point also need to discuss existing TLDs. · Principle is to keep it simple and easy for people to understand. · The rare cases where a label state transitions from Delegated to Allocated exist, especially in the ccTLD space (retired ccTLDs). There is also an example of sunsetting .工行. 6. AOB