2025-05-28 Latin Script Diacritics - Meeting #09

Notes/ Action Items

[OUTCOMES]

1. Filled in Spreadsheet [docs.google.com]of relevant recommendations and wrote the consensus in the decision tab
2. Consensus not to change the current objections process and to keep the current policies 5.1-5.5

[ACTION ITEMS]

1. Review objections and process as outlined in the Resources [icann-community.atlassian.net] section of today’s agenda

[NOTES] Meeting #9 Slides [icann-community.atlassian.net]

1. Welcome and SOIs
2. Recap of Meeting #8

Outcomes and Action Items

• For determination of scope, if strings are visually confusingly similar in the SSR process, our PDP is a way to avoid the objection mechanism that exists there. 

3.Charter Question 3 [gnso.icann.org]

Overview of the objection process given for the SSR process 

• Our PDP cannot change or alter anything about the objections process
• Goal of this review is for the WG to understand the existing process 
• These objections processes will occur prior to LD PDP as detailed in the current AGB draft
• Is the notion of precedence important? Can an objector argue that prior rulings were confusingly similar. Based on the arguments of the case at hand regardless of prior?
  • Each case tends to be an isolate process, but panel works in a consistent manner 
• Sarmad added that some objections go beyond what SSR does, which is purely visual comparisons. Not related to meaning or sound, which may become relevant through other objection processes. Objections are a much broader area.  

a.Continue with Review of EPDP IDNs Outputs (Worksheet [docs.google.com] to Leverage Outputs)

• 5.1-5.5 does this PDP need any changes to the existing objections processes, if so, they need to be discussed. Otherwise, current objections processes sufficient? Is there anything that would need additional objection processes? Consensus that changing would be too difficult
• 6.1 string contention is at the heart of the issue and needs to be tailored to the Latin specific case.
• LGR process and not the policy process. If understanding is correct this should be the RZ-LGR process rather than any other process that LD PDP creates
• Dealing with both the variants and not the variants at the same time. There is already a subset of variants. Focus on not ending up with language that everything or nothing is a variant. Both working within the limitations of the scope of RZ-LGR and characters we are working with. Word this carefully. 
• 6.1 nothing should be changed with variant contention sets as RZ-LGR is out of scope. Not applicable as this is an output that LD PDP works within
• 6.2 Suggestion that something similar to this will need to be included. Look at the contention set, probably not automatically confusingly similar, process needs to look at all of those. Response that this already exists that if they are confusingly similar they are put into a contention set. Already part of existing policy.
• This review process is out of scope. The LD PDP works within the outcome of this process. 
• 7.2 The principle makes sense that there is some kind of relationship between two or more of the TLDs that we are talking about. There needs to be something written in the contract that those two or more need to be in relationship and will likely need some amendment or new specification
• 7.3 similar diacritic version to existing TLD contracts will need to be changed accordingly
• 7.4 financial discussions to be discussed as a block later on down the line, once we have all the technical policy decisions in place. Postponed
• 7.5 and 7.4 remain pending with the Board currently and are the only pending recommendations from that report
• 7.6-7.8 same entity principle applies
• 7.9 basic principle applies, but might want further specification in this case. Not an activation of a variant and there is some difference in this. Deal with on a case by case basis. Have to look at exact wording here, not those variant rules. This policy is transferred to a new entity. Same entity principle must be upheld
• 7.10 EBERO acronym emergency back-end registry operator explained. 
• Needs to apply to keep same entity even in EBERO

4.Next Steps

5.AOB