Dear SSAD Supplemental Recommendations Team Members,

Below, please find action items and high-level notes from yesterday’s meeting.

Best regards,

Andrew on behalf of the GNSO Support Team

Action Items: 

• All members are to closely review the reading materials highlighted in the Straw Document - including the original recommendation, the modified recommendation, the Standing Committee’s Report, the Board’s resolution, etc.
• Groups to coordinate ahead of ICANN86 so that we can hear reactions from groups rather than individuals.

Reading Materials for Day 0 and ICANN86 meetings: 

• Reading materials have been linked below. For ease of reference, the pages associated with the recommendation have been added. Please note that this is not an exhaustive list, please see the Assignment Form for additional documents. 
  • Recommendation 1 (Authentication)
    • RDRS Standing Committee Report - pages 13 and 35
    • Registration Data Request Service Policy Alignment Analysis - page 12 
    • SSAD ODA - pages 23-30 and 56-59
      
      
  • Recommendation 2 (Accreditation of Governmental Entities)
    • RDRS Standing Committee Report - pages 14 and 35
    • Registration Data Request Service Policy Alignment Analysis - page 12 
    • SSAD ODA - pages 23-30 and 56-59
      
      
  • Recommendation 6 (Priority Levels)
    • RDRS Standing Committee Report - pages 18, 37, 62, and 67-68
    • Registration Data Request Service Policy Alignment Analysis - page 13
    • SSAD ODA - pages 65-66
      
      
  • Recommendation 8 (Contracted Party Authorization) 
    • RDRS Standing Committee Report - pages 20, 37-38
    • SSAD ODA - pages 65, 83, 86, 88-89, 95, 102-103
      
      
  • Recommendation 10 (Determining Variable SLAs for Response Times for SSAD)
    • RDRS Standing Committee Report - pages 22 and 38
    • Registration Data Request Service Policy Alignment Analysis - page 13
    • SSAD ODA - pages 21, 46-47, and 65-66
• Reading materials and the pages that members must read in preparation for the Day 0 meeting are also highlighted in the RDRS SC Feedback row of the strawperson document.

Upcoming Meetings:

• Day 0 in Seville - Sunday, 7 June 2026 10:00 - 18:00 CEST (08:00 - 16:00 UTC)
• ICANN86 - Monday, 8 June 2026 10:00 - 11:15 CEST (08:00 - 09:15 UTC)
• ICANN86 - Wednesday, 10 June 2026 11:45am - 1:15pm CEST (09:45 - 11:15 UTC)
• ICANN86 - Thursday, 11 June 2026 2:45pm - 4:00pm CEST (12:45 - 14:00 UTC)

Important Links:

• Team Wiki
• Strawperson Document
• Assignment Form

High-Level Notes:

1. Welcome

• Support Staff noted that SRT Members may participate on the call while Alternates are asked not to participate unless they are temporarily filling in for a Member. 

• This will be the last meeting before the Day 0 meeting in Seville and ICANN86. 
  
  
1. Recap of Recommendation 11 Discussion and Working Methodology 

• Additional page references noting key required reading for recommendations have been added to the grey RDRS SC Feedback section of the strawperson document. 

• An “SSAD SRT High-Level Flags and Noted Dependencies” row has been added to recommendation 11. This row is for items and dependencies that have been mentioned but may not necessarily belong in recommendation 11. 

• Two recurring themes were identified and shared with members. 

• The first noted theme was regarding the handling of SSAD Terms and Conditions violations. The SRT Lead noted Recommendation 11 may not be the appropriate recommendation to address this theme. The SRT Lead assured the group that this theme will continue to be tracked and addressed in future SRT discussions. 

• The second noted theme was the 18 SSAD recommendations are interconnected and will be revisited when needed. Changes to other recommendations could impact Recommendation 11.

• Members noted further discussions may be needed to explore the usage of “MUST” and revisions to Implementation Guidance.
  
  
2. Plan for ICANN86 Day 0 Meeting

• David Plumb of the Consensus Building Institute introduced himself and noted he will be joining the Day 0 meeting.

• David Plumb noted the benefits of in-person interaction and plans for the SRT to participate in breakout sessions during the Day 0 meeting. 

• David Plumb’s goal is to help members express their key priorities and assist the SRT in finding agreement on a way forward for high level of effort (LOE) recommendations. 

• The focus of the Day 0 meeting will be Recommendation 1 (Authentication), Recommendation 2 (Accreditation of Governmental Entities), and Recommendation 10 (Service-Level Agreement). 

• The Lead emphasized the importance of Members preparing for the ICANN86 sessions by completing all of the required reading (see above in the Reading Materials section). In order to make important progress during our time together, everyone must come prepared.  

• Members are encouraged to ask questions and discuss recommendations on the SRT mailing list. 

• Members were reminded that the SRT is tasked with modifying recommendations. 
  
  
3. Overview of Recommendations denoted by Standing Committee as HIGH level of effort to modify

• High LOE recommendations were identified by the RDRS Standing Committee. The RDRS Standing Committee noted that these recommendations would require either a considerable amount of edits or would be substantially impacted by revisions. 

• Recommendation 1 – Accreditation
  1. Support Staff noted that Recommendation 1 was the longest recommendation in the EPDP and would have been costly to implement according to SSAD ODA estimates
  2. Support Staff explained that initial changes to Recommendation 1 were drafted to address potential high cost, confusion over the difference between accreditation, authentication, and authorization, and the necessity of authenticating law enforcement entities as a starting point. 
  3. The overarching principles considered when modifying recommendation 1 include:

1. High estimated cost of accrediting all users may result in a system that is not adoptable or Board ready;
2. Authentication does not equate to authorization. Registrars must review request to determine if it can authorize the disclosure of the requested data;
3. Authentication of law enforcement entities is important, particularly to facilitate responses to urgent requests; 
4. Exploration of authentication should begin with law enforcement, but did not mean to restrict other interested requestor constituencies;
5. What is the minimum viable product and what can achieve consensus. 
3. Support Staff provided a high-level overview of the changes made to Recommendation 1 in the Strawperson document. 
   
   

• Recommendation 2 - Accreditation of Government Entities
  1. Support Staff mentioned that Recommendation 2 originally envisioned a separate accreditation process for government entities seeking access to nonpublic registration data but would have been costly to implement according to the SSAD ODA . 
  2. Support Staff noted that accreditation of all government entities as envisioned by Recommendation 2 was likely no longer considered for implementation due to cost and complexity. 
  3. Support Staff noted that the RDRS Standing Committee Report advised focusing first on the authentication of law enforcement agents. 
  4. Support Staff provided a high-level overview of the changes made to Recommendation 2 in the Strawperson document.
  5. The overarching principles considered when modifying recommendation 2 include:

1. Authentication of law enforcement entities is important, particularly to facilitate responses to urgent requests; 
2. Exploration of authentication should begin with law enforcement, but did not mean to restrict other interested requestor constituencies. 
   
   

• Recommendation 6 - Priority Levels
  1. Support Staff noted that Recommendation 6 envisioned a system that allowed Requestors to select from three priority levels. 
  2. The RDRS pilot did not implement the three priority levels but did allow for Requestors to flag their request as “expedited”.
  3. Support Staff noted that the RDRS Standing Committee supported keeping priority levels and noted that authentication of law enforcement agents is needed to address urgent requests.
  4. Support Staff provided a high-level overview of the changes made to Recommendation 6 in the Strawperson document. 
  5. The overarching principles considered when modifying recommendation 6 include:

1. Criteria to define an urgent request is provided in the recommendation and matches the current definition used in the updated Registration Data Policy;
2. This recommendation provides the definitional threshold requirements for when access to registration data is needed urgently in response to an imminent threat to life, serious bodily injury, critical infrastructure (online and offline) or child exploitation
3. Registrars must be able to re-categorize requests due to the short timeline for response, and there needs to be a consequence for repeated abuse of priority levels flag
   
   

• Recommendation 8 - Contracted Party Authorization
  1. Support Staff noted that Recommendation 8 goes over the requirement for the registrar to review and respond to SSAD requests. 
  2. Registrars retain the ultimate authority to approve or deny the request due to the liability associated with disclosure. 
  3. Support Staff noted that adjustments to the recommendation may be needed to address confusion around GDPR-specific language
  4. Support Staff provided a high-level overview of the changes made to Recommendation 8 in the Strawperson document.
  5. The overarching principles considered when modifying recommendation 8 include:

1. Registrar must evaluate disclosure requests in accordance with their local laws. SSAD recommendations cannot impede this 
2. RDRS was a voluntary pilot. The SSAD, including any updates as a result of modified recommendations will be mandatory due to consensus policy recommendations 
3. The recommendation was prescriptive to GDPR
4. Requestors noted that the inclusion of GDPR-specific language was confusing, particularly because not all requests fall under GDPR. 
   
   

• Recommendation 10 - Service Level Agreements
  1. Support Staff noted that Recommendation 10 covers SLA requirements for Registrars to respond to SSAD requests. 
  2. Support Staff noted that binding SLAs were not implemented in the RDRS. The Board has mentioned that the successor system needs enforceable SLAs. 
  3. Support Staff provided a high-level overview of the changes made to Recommendation 10 in the Strawperson document.
  4. The overarching principles considered when modifying recommendation 10 include:

1. Timely responses to disclosure requests are important and provide predictability to registrars and requestors.
2. SLAs need to balance registrars’ need to carefully consider the request to avoid improper disclosure with requestors’ need for predictability in terms of response time.
3. The urgent request timeline requires authentication in order to be enforced.

• Members were reminded that these initial changes represent a starting point for discussion and are not finalized Supplemental Recommendations. 
  
  
4. Discussion of Recommendation 17 

• Members did not discuss Recommendation 17 during this meeting. 

• Some members noted that it would be helpful to have a cost analysis for revised recommendation that may be compared to the estimate provided in the SSAD ODA. The SRT should work with org and Board liaisons to understand cost implications and ensure the future system is cost effective. 

• Some members noted they would like to ensure that authentication is thoroughly and holistically discussed. 
  
  
5. Recap of Action Items and Agreements 

• Members to closely review reading materials and the straw document 

• Groups to coordinate ahead of ICANN86 so we may hear reaction from the group’s perspective rather than individual perspectives
  
  
6. AOB 

• Members asked whether it would be helpful to provide suggested edits, comments, and non-general written input ahead of the Day 0 meeting and ICANN Meeting. It would be appropriate to raise topics on the mailing list. Suggested edits and comments to the straw person document are welcomed ahead of the Day 0 meeting. 

• When members suggest an edit or comment, they should consider the motivation behind the edit and be prepared to speak to the suggested edit or comment. 
  
  
7. Next Meeting

• Our next meeting will be on Sunday, 7 June 2026 10:00 - 18:00 CEST (08:00 - 16:00 UTC). 

• The next meeting will be the Day 0 meeting in Seville, Spain.