Hi All,

Please find below the notes and action items from the 03 August 2023 IDNs EPDP meeting #90 at 12:00 UTC.

Best Regards,

Ariel, Steve, and Dan

ACTION ITEMS

1. Leadership to consider amendment to the rationale of Rec 4.2 by taking into account the new input from ICANN org.
2. Leadership to consider amendment to Rec 4.4 by taking into account the new input from ICANN org. 
3. Leadership to consider amendment to Rec 5.3 by taking into account ICANN org input.
4. Leadership to consider amendment to Rec 6.2 and discuss the semantic differences between “Process” and “Evaluate”. 
5. Leadership to check with GDS and the RySG regarding the proposed additional text to Recommendation 7.1
6. Leadership to consider amendment to Rec 7.3 and soften the language. The Team will solicit RySG feedback on Rec 7.3 and the complexity of RAs
7. Leadership to propose an overarching statement on registration data protection in order to address the CCWP-HR’s input for 7.7, 7.8, 7.9, 7.12, and 7.13. 
8. Leadership to consider amendment to Rec 7.10 by taking into account ICANN org’s input. 
9. EPDP Team to further discuss ICANN org’s input for IG 7.14.
10. Leadership to consider amendment to Rec 8.2 by taking into account ICANN org comment.
11. Leadership to consider replacing “can” with a more appropriate word in Rec 8.5. 
12. Leadership to consider amendment to Rec 8.7 by taking into account ICANN org input. 

NOTES

ROLL CALL AND SOI UPDATES 

• No Updates

WELCOME AND CHAIR UPDATES

• The Chair provided an introduction to this week’s meeting

CONTINUE WITH PUBLIC COMMENT REVIEW

• ICANN staff reviewed the new input from ICANN org to Preliminary Recommendation 4.2, which was received in the past week (not from the public comment proceeding). The Leadership will consider proposing an amendment to the rationale of Rec 4.2 for the EPDP Team to consider .

· ACTION ITEM: Leadership to consider amendment to the rationale of Rec 4.2 by taking into account the new input from ICANN org.  

• Recommendation 4.4 recently received an ICANN org input not through the public comment process. The input was about a potential oversight on omitting reserved names and two-character ASCII strings in the recommendation language. The observation was accepted by the team.

• ACTION ITEM: Leadership to consider amendment to Rec 4.4 by taking into account the new input from ICANN org. 

• For recommendation 5.3, the team discussed the proposal of revised language from ICANN org. For consistency, the Team agreed with the suggestion and Leadership also committed to ensure that small semantic inconsistencies would be resolved or at least not impact the intent of the recommendations. 

• ACTION ITEM: Leadership to consider amendment to Rec 5.3 by taking into account ICANN org input. 

• Recommendation 6.2 contained a discussion on the definition of “processed” in the recommendation and the rules for “processing elements” in the contention set. Leadership will discuss this further as there were no comments from the team. 

· A comment in chat stated “Perhaps ...... 6.2 The entire variant label set of an applied-for primary gTLD string (no matter whether it is an ASCII string or an IDN string) that is placed in the contention set must be processed together.”

· ACTION ITEM: Leadership to consider amendment to Rec 6.2 and discuss the semantic differences between “Process” and “Evaluate”.

• A comment from the Registries Stakeholder Group (RySG) was received for Recommendation 7.1 and the team reviewed this comment. A participant gave feedback on the suggested language by the RySG and Leadership discussed the role of Service Level Agreements (SLAs) in the Registry Agreement. This input provides a point of clarity to standardize the SLAs in the proposed text, specifically that the SLAs for each Variant Label are the same.

• A comment in chat asked, “But does this not go further than Recommendation to an extent?” 
• Another comment asked about the difference between “substantially similar” and “same”  with regards to the SLAs. 

• This spurred discussion of seeking guidance from ICANN Global Domains and Strategy (GDS) and the RySG for more context
  
  
  
• ACTION ITEM: Leadership to check with GDS and the RySG regarding the proposed additional text to Recommendation 7.1
  
  
  
• For recommendation 7.3, two comments were marked as “Significant Change Required” and the team discussed both of them. One was from ICANN org and one was from the Cross Community Working Party on ICANN and Human Rights (CCWP-HR). 
  • The comment from ICANN org received agreement from the team in the spirit of uniformity, but also had discussion on the potential softening of the recommendation.
    • One member of the team mentioned that the specific factors of the comment about the Registry Agreement may be out of scope of the EPDP Charter, but this was pushed back on by the Chair. The Chair did agree to soften the language though. 

• The softening of language was agreed to by multiple team members.
  
  
  
• ACTION ITEM: Leadership to consider amendment to Rec 7.3 and soften the language. The Team will solicit RySG feedback on Rec 7.3 and the complexity of RAs
• There was also discussion about a possible transition period required for the Registry Operators 

• For recommendations 7.5 and 7.6, the comments from PointQuebec cannot be addressed at this time.
  
  
  
• Recommendation 7.7 received a comment from CCWP-HR and leadership discussed the comment, with regards to scope and 

• There was a discussion as to why Recommendations 7.7 and 7.8 differ and a push to harmonize the two recommendations. This would minimize the potential misinterpretation of the recommendations. An overarching statement regarding registration data protection would be a good way to address it.

• ACTION ITEM: Leadership to propose an overarching statement on registration data protection in order to address the CCWP-HR’s input for 7.7, 7.8, 7.9, 7.12, and 7.13.
  
  
  
• Recommendation 7.10 discussion centered around the term and definition of “successor”. This is the only occasion this term is used in the Phase 1 Initial Report, and it is suggested by ICANN org to affirm the application of the Same Entity Principle in the recommendation language. There were no objections to the term “successor” (so it will be retained in the recommendation), but leadership will work to include the “same entity” principle in the recommendation.
  • ACTION ITEM: Leadership to consider amendment to Rec 7.10 by taking into account ICANN org’s input.
    
    
    
• For I.G. 7.14, there was pushback from the team on the ICANN org input, without agreement from the team on how to amend the I.G.. Leadership will review further how to address this item. 
  • ACTION ITEM: EPDP Team to further discuss ICANN org’s input for IG 7.14.
    
    
    
• Rec 8.1 had extensive discussion in the last meeting (#88) and there will be no change to the recommendations based on the comments, but strengthen the Implementation Guidances 3.6, 3.9, and 3.9

• Recommendation 8.2 received multiple comments, including submissions from RySG, ICANN Org, and CCWP-HR

• RySG proposed a small wording change, while ICANN org and CCWP-HR had significant changes required. 

• A participant voiced the opinion that ICANN org should be the responsible party for developing the framework. 
• A different participant discussed the RySG comment in an attempt to add context to the guidelines and the binding / non-binding nature of them. 
• It was proposed that the team take another look at the preferred method of dissemination comment. Some proposed actions included adding to part G of the charter (Implementation Guidance), adding to the ICANN website, or adding to the documents / resources that the Contracted Parties create to assist each other with different tasks.
• A comment in chat asked if “this be a part of the IRT, in the sense that the IRT would oversee the staff development of the framework (which would naturally go out for public comment etc)”
  • ACTION ITEM: Leadership to consider amendment to Rec 8.2 by taking into account ICANN org comment. 

• Similar to Rec 8.2, I.G. 8.3 had a similar comment to add that the guidelines would be non-binding.
  
  
  
• Recommendation 8.5 had a comment from ICANN org that related to the semantics contained in RFC 2119 (“MUST", “MUST NOT”, "SHOULD", “SHOULD NOT”, “REQUIRED”, and "MAY") and the potential to replace the word “can” in the recommendation, which was not objected to by the team.

• ACTION ITEM: Leadership to consider replacing “can” with a more appropriate word in Rec 8.5.
  
  
  
• On recommendation 8.7, ICANN org provided two comments in support, but with wording changes. 
  • The chair discussed how there is a desire to harmonize with established documents (for example the Procedure to Develop and Maintain the Label Generation Rules for the Root Zone in Respect of IDNA Labels) on the Generation Panels (GPs) maintaining backwards compatibility.

• One recommendation is to say something along the line as “Look at the stability principle of the LGR procedure” 
• Another recommendation is to keep the recommendation but append a disclaimer to it.
• ACTION ITEM: Leadership to consider amendment to Rec 8.7 by taking into account ICANN org input. 

AOB

• The Chair adjourned the meeting.