Dear all,

Please find below the notes and action items from today’s meeting on Thursday, 7 July 2022 at 13:30 UTC.

Kind regards,

Ariel, Steve, and Emily

Action Items:

Action Item 1: Members to respond to Ariel’s email about availability to meet with ccPDP4 on 26 July.

Action Item 2: EPDP Team members to review anonymized results of the survey of existing Chinese and Arabic IDN gTLD operators about their interest in activating variants, shared by staff on the mailing list. 

Action Item 3: EPDP Team members from RrSG and RySG will ask their groups if there are known examples of use cases 2, 3, 4 that already exist. 

Notes – IDNs EPDP Call – 7 July 2022

Chair Updates

• The ccPDP4 has requested a meeting with the EPDP Team on areas where the two groups may possibly diverging. The suggested date for the meeting is 26 July.

Action Item 1: Members to respond to Ariel’s email about availability to meet with ccPDP4 on 26 July.

• The ccPDP4 variant sub-team is finalizing recommendations to the ccPDP, so this is a good moment for information sharing and considering the possibility of mid-course correcting where there may be divergence.
• Key area where there may be a divergence: Potential changes to RZ-LGR where an existing TLD is not supported by the RZ-LGR, what happens next. Language regarding grandfathering is different in the two sets of recommendations. ccPDP4 recommendations introduce a threshold at which deselection may be the only way to address a security threat.
• Some divergence may also exist between the outputs of the small group on string similarity and ccPDP4 work on string similarity. cc work is focusing on a level 2 comparison where the EPDP small group is focusing on a “hybrid” level 2-level 3 approach.

• Question: ccPDP did a stress-testing exercise at ICANN74. Is this something we should consider? Is this approach applicable to our work?
• Response: Stress-test during ICANN74 was appreciated by all. The audience provided input that requires additional consideration by the ccPDP4 group. If possible, it is recommended that the EPDP Team does a similar test when recommendations reach a level where this is possible.
• Response: To some extent, the EPDP Team might be doing this along the way, but as we get further in the process, it may be helpful to see if there are additional stress testing that can be completed.

Action Item 2: EPDP Team members to review anonymized results of the survey of existing Chinese and Arabic IDN gTLD operators about their interest in activating variants, shared by staff on the mailing list. 

Charter Question C1

• Preliminary discussion last week: Same entity principle should apply for the registrant.
• Slide 4 – Charter Question C1
• Slide 5 – Scenario 1: Context – A given second-level label beneath each allocated variant TLD must have the “same entity”
• Slide 6 – Scenario 2: Context – All allocatable second-level IDN variant labels that arise from a registration based on a second-level IDN table must have the “same entity”
• Slide 7 – Refresher on IDN Tables
• Question: Is there any reason why the RZ-LGR cannot be used at the second level? That way, we will have a uniform way to enumerate variants.
• Response: RZ-LGR does not support numbers. At the second level you want to have numbers. Also, there might be valid reasons for certain TLDs to not have the same restrictions that are made in the RZ-LGR. For example .cat, they have a letter that was not allowed in the RZ-LGR but that they want at the second level because it is important in the Catalan language.
• Response: IDN tables have been in existence prior to the RZ-LGR. There is not one definitive table per script. From a retrospective perspective, it would be difficult to apply the RZ-LGR to the IDN tables, but there has been an attempt by the Org GDS team to bring some uniformity to the IDN Tables.
• Slide 8 – Example strings
• Slide 9 – Scenario 1: EPDP Deliberation -- A given second-level label beneath each allocated variant TLD of an existing gTLD must only be allocated to the same registrant, or else withheld for possible allocation only to the same registrant
• Slide 10 – Scenario 2: Explanatory Notes
• Comment: The sponsoring Registrar currently has no obligation to maintain the activated second-level variant label throughout its domain name lifecycle. This depends on the registry itself. For some registries it's technically already enforced that variant labels are under the same registrant and registrar.
• Question: Is there any condition attached before you can activate second level variant?
• Response: The points mentioned on the slide are the conditions. There is an addendum to the RA that provides additional conditions related to activation of variants.
• Response: Verisign TLDs do not activate variants. Variants are calculated but they remain blocked, consistent with registry policy.
• Slide 11 – Scenario 2: Case 1 – Same Registrant and Same Registrar: This is the best case scenario – existing Case 1 variants have already satisfied the “same entity” requirement; no further actions are required.
• Slide 12 – Scenario 2: Case 2 – Different Registrants and Same Registrar: Such case may happen when a second-level variant is sold to another registrant under the same registrar after its activation.
• Comment: We need to say that there are going to be no resellers for IDN TLDs or we need to use it in our use cases to ensure that we don’t miss anything.
• Question: This use case is theoretically possible. Are there any cases of this in practice (Scenario 2: Case 2)?
• Response: Four cases in the slides are in theory. It is a big data collection exercise to see the extent of each case existing in practice. At the moment, it is not possible to collect the data in a timely manner. There is no guarantee that we will be able to collect a full data set.
• Response: One member noted that he is not aware of any registries that currently would allow this, but it’s possible that someone has. It might be possible to contact the backend operators. They should know whether they implemented technical rules to avoid these situations.
• Response: One thing to note, even though these four cases are theoretically possible, in practice they are not equally likely. It is possible that some of these cases are extreme corner cases and may not even exist in practice.
• Slide 13 - Scenario 2: Case 3 – Same Registrant and Different Registrars - Such case may happen when a second-level variant is transferred to another registrar after its activation.
• Slide 14 – Scenario 2: Case 4 – Different Registrants and Different Registrars - Such case may happen when a second-level variant is transferred to another registrar after its activation, and is later sold to another registrant.
• Comment: Some of this is dependent on the registry policy. If the registry policy is silent of whether the registrant needs to be the same, it could be the case that the registrant from variants is different. To what extent is it the registry policy that underlines these scenarios?
• Comment: We may not have to consider the specific registry policies. The EPDP Team may want to focus on what requirements will apply in policy.
• Comment: As we look at these cases, we are trying to look at two things: 1. The same entity principle and what is it? 2. The persistence requirement throughout the lifecycle.  Is it desirable to have these outcomes? If no, we should have same entity enforced, persistent throughout lifecycle. Next, we should look at same entity definition – what does registrant mean on a technical level and who will enforce on what level? At the end of the day, it is going to be up the registrant to translate the principle to user experience. Who are we to say that this should not be possible?
• Scenario 2: Discussion Questions
• Discussion Question 1: Do second-level variants in Case 3 (Same Registrant & Different Registrars) meet the “same entity” requirement?
• Question: Do existing registrations have these cases already? Is this completely hypothetical? From previous discussion and SSAC feedback, going forward this should be enforced with the same registrant, same registrar throughout the lifecycle. If we don’t know if they exist, we should do the research.
• Response: We don’t have existing data on this. It may be possible to find out if registries have a current policy on activating variants or perhaps we can ask the backends about current practice. Data collection is time-consuming and responses may not be complete.
• Follow-up: Zone file and whois check could narrow it down quickly to see if these cases exist and how prevalent they are. If these cases exist, the difficulty in addressing them would be significant.
• Comment: It’s been helpful to refer to data so far. It was mentioned that we could ask RSPs. Leadership team can think about whether there is a way to get data from the RSPs, but there is no contractual relationship between ICANN and the RSPs. GDS has done work on IDN Tables, and we can see if there is a way to get information through other means, as well. It would be good to understand the scope of the issue, but it could be difficult to do. Maybe we could, for the moment, look at what to do if these situations did exist.
• Discussion Question 2: Should the “same entity” requirement be retroactively applied to existing second-level variants in cases 2, 3, and 4?
• Discussion Question 3: For non-activated, allocatable variants S1.T2, S2.T2, S3.T1, and S3.T2, is it possible to satisfy the “same entity” requirement for their future allocation in Cases 2-4? If yes, how should they be allocated?  
• Comment: Current situation is that we don’t have variants at the top-level. Whether these scenarios exist or not, there doesn’t seem to be an issue at the moment with variants at the second level are problematic if the same entity doesn’t apply. If these scenarios do exist, it is currently not a problem. It seems that it wouldn’t be problematic to grandfather. It may be when we introduce variants at the top level and we have them at the second level, the situation will be more complex and the same entity rule will become more important.
• Comment: When the top level begins to have variants, that only impacts Chinese and Arabic. We are talking about existing labels and only Chinese and Arabic will have allocatable variants.
• Comment: Suggestion for data collection - check with the Ry and Rr stakeholder groups to see if they know of such a possibility. If someone says yes, we know it needs to be addressed. If no one says yes, we are in the same position we are in now.

Action Item 3: EPDP Team members from RrSG and RySG will ask their groups if there are known examples of use cases 2, 3, 4 that already exist. 

• Suggestion: Perhaps we can say that if this were to happen (cases of existing strings not compatible with the forward-looking policy), the registry needs to come up with a plan. Keep the overarching policy high-level.
• Response: It’s not a good idea to leave it to the registries to implement. In other situations, this approach has resulted in delays, lack of uniformity, and lack of transparency in the past.

AOB

• ALAC would like more time to review Group 2 questions. The deadline was 8 July. This will be extended for everyone by one week.