Dear SSAD SRT Members,

Below, please find the notes and action items from the SSAD SRT meeting on Tuesday, 23 June 2026.

Thank you.

Best regards,

Caitlin on behalf of the SSAD SRT GNSO Support Team

--

Action Items

For SSAD SRT members:

• By Tuesday, 30 June: In preparation for our next meeting on Tuesday, 30 June, please familiarize yourselves with the original recommendation text and the feedback from the RDRS Standing Committee on Recs. 4, 9, and 18.
• By Tuesday, 7 July: Please review the straw person text and provide feedback for Recs. 3, 5, and 7. Additional feedback can be provided in the straw person document or via the email list. Where possible, SRT members are requested to provide proposed text to address concerns.
• Continue reviewing the updated text for Rec. 6 and Rec. 8 and provide additional feedback in the document or on list, including proposed text to address your concerns, where possible. 

For SSAD SRT Leadership:

• Leadership to create and distribute a chart to track:

• Recommendations where initial readouts are completed, including dates when these were completed
• Recommendations where initial readouts are outstanding, including the projected dates these will take place 
• Recommendations where updated proposed text has been distributed, including associated due dates and dates for planned future discussion 

Notes

1. Welcome (5 min)

· Thank you for the hard work during ICANN86.

· The plan for today’s meeting is to have a short recap of the discussions at ICANN86. 

· Because our main agenda for today is to do an initial readout of Recs. 3, 5, and 7, we will not spend a lot of time going over the substance of ICANN86 discussions. 

· There will, however, be additional time to revisit these recommendations. 

· As promised during ICANN86, we plan to do an initial readout of all 18 SSAD recommendations since the recommendations are very interconnected and interrelated. Going forward with an initial readout is important so that the team can understand how the 18 recommendations fit together and see if there is potential overlap. 

· Following the progress made during ICANN86, the Leadership Team has been working on a detailed work plan, which we will be sharing soon.

· As we go through the recommendations, if a topic warrants a smaller, more nimble discussion, we have the option to schedule targeted small group meetings.

· Lastly, I did want to make one note about the updated timing of the meeting. 

· Prior to ICANN86, we identified a time leading up to ICANN86 with the understanding that we would send another Doodle poll following ICANN86 to see if that time still worked. At the time, several members said the original time did not work well for them.

· I am aware the new meeting time poses different challenges to other colleagues.

· Our group is spread across many time zones, so it will be difficult to find a time that accommodates everyone. 

· However, other GNSO groups have rotated their call times to ensure that all members are able to participate during a favorable time zone. Leadership is currently discussing a meeting rotation to ensure do not disadvantage any geographic region. 

2. ICANN86 Recap (10 min)

· We spent ICANN86 discussing the five recommendations that the RDRS SC marked as high level of effort to modify:

· Rec 1 and 2 (Authentication)

· Rec 6 (Priority Levels)

· Rec 8 (Contracted Party Authorization)

· Rec 10 (SLAs) 

· We spent our Day 0 meeting focusing on Recommendations 1, 2, and 10. 

· We then had three work sessions and discussed Rec. 6 and Rec. 8. 

· These recs, in theory, will have the most substantive changes based on the learnings from the RDRS pilot. 

· Feedback from SRT:

· SRT members received some feedback that non-members are interested in participating in discussions, so perhaps during the sessions at ICANN87, we could consider opening up sessions or providing dedicated time for non-members to provide feedback and suggestions. 

· This could be disruptive, so perhaps consider a short, non-working session where we seek broader feedback from the community at ICANN87.

· The slides and previous notes and straw person documents summarize the discussions at ICANN86, so we will not take time to read through these now. 

3. Review of Rec 3, 5, and 7 (55 min)

• During our discussions at ICANN86, we touched on other related recommendations, including Rec. 3 (what elements are required in a request), Rec. 5 (response requirements, which is closely related to Contracted Party Authorization), and Rec. 7 (requestor purposes). 
• Rec. 3 was highlighted as a low level of effort to modify, so there are a few small change suggestions for the group to discuss.
• Rec. 5 was highlighted as a medium level of effort to modify and deals with response requirements. This topic sounds familiar because it is closely related to Rec. 8 (Contracted Party Authorization), and we will discuss that overlap. 
• Rec. 7 was considered low level of effort to modify, and there are very few changes to the strawman text for Rec. 7. 
• Generally speaking, a low level of effort to modify means that there should only be minor to moderate modifications based on the RDRS findings. 
• You will have seen that the straw person text is very similar to the original text. 
• As we review the text, please consider if the proposed modifications by the Leadership Team are acceptable. If not, what is missing or needs further modification?
• If there is a concern, proposing updated redline text is always appreciated.
• Suggestion from the SRT - consider changing the term data controller to data holder, as data controller may not always be relevant for entities like ccTLDs. 

• Recommendation 3

• The Standing Committee found Rec. 3 to be a low level of effort to modify. 
• The Standing Committee’s discussions focused largely around ensuring the SSAD form is user-friendly and easy for requestors to understand. 
• The Standing Committee noted that during implementation, there could be a focus group of requestors and contracted parties to ensure the request form is user-friendly but provides Contracted Parties what they need.
• There was the suggestion of including tool tips and other features to help requestors in filling out forms correctly.
• Some SC members suggested simplifying the form and removing GDPR-specific language to avoid most requestors choosing “other” as their basis for the request. 
• Additionally, some requestors noted the lack of ability for IP holders to provide documentation certifying their IP rights.
• The next two slides have been provided to show the elements in a complete RDRS request, and the request categories. These slides are provided for background information.

• SSAD SRT Initial Feedback to Straw Text for Rec. 3:

• The form should inform the requestor about respecting the data subject’s human rights. For 3.7, feedback should also be solicited from end users and registrants - not just requestors and Contracted Parties. 
• For 3.3, do these features need to be built into the SSAD? 
• The original recommendations had recommended a Central Gateway Manager would perform certain reviews before sending the request to the Contracted Party. Based on learning from the RDRS, that concept is not likely moving forward. 3.3 is now looking at what needs to be included in the SSAD. If the text is hard to read, we recommend providing alternative text. 
• In 3.2.3, this is the wrong example question b/c it’s necessary for the Requestor to ask for this data because it is not public. Instead, a better question may be, “How will the requested data support pursuit of that legitimate interest or lawful basis?”
• At the end of 3.3 - this should be a capital must. 
• The Must in 3.3 should be should. 
• This discussion is an initial reaction. We will have time to get into more detail on the straw text.
• Please review the text and provide additional feedback in the document or on the mailing list. Proposed updated text makes the process more efficient. The amount of feedback and comments provided assists Leadership in determining how much meeting time to allot to a particular recommendation. 
• We try to allot meeting time to the more difficult topics, so we encourage the team to continue diligently working in the document and on the mailing list. 
• Question: has anything been decided about how this will be implemented?
• In the initial work, the Team tried to be agnostic to this question.
• In general, it is best to leave up to ICANN org re: how to determine the best way to implement recommendations, whether in house or outsourcing. This is best left to a later decision. The important questions now are - what are the requirements?
• The language should be neutral. 

• Recommendation 5
  • Recommendation 5 deals with Response Requirements. 
  • The RDRS Standing Committee’s feedback on Rec. 5 is similar to feedback on other closely related recommendations. 
  • For example, the Standing Committee noted Requestor dissatisfaction with the rationales provided by Registrars for denying requests. 
  • Specifically, requestors noted that the choices from the RDRS “pick list” were insufficient to thoroughly explain the reason for denial.
  • In light of this, the RDRS Standing Committee discussed requiring more detailed, easily understood reasons for denial (this may sound similar to the discussion the SRT has already had in reference to Recommendation 8). 
  • The idea behind this is for the mutual benefit of Contracted Parties and Requestors - improved requests. 
  • Similar to Recommendation 8, the RDRS Standing Committee discussed the addition of a two-way communication method between requestors and contracted parties. 
  • Also, similar to the discussions the SRT had regarding Rec. 8, the RDRS Standing Committee noted that the Contracted Party should ask the requestor for additional information before denying the request (noting that this functionality does not exist in the RDRS but should for the SSAD). 
  • For background information, the next slide shows the “pick list” of response denial reasons. This is provided for the group’s information. 
  • As EPDP background, Rec. 5 was completed earlier in the process, and Rec. 8 was added later, but there was not appetite to revisit Rec. 5 - that may have led to two recommendations that say the same thing slightly differently.
  • There could be issues in implementation if we proceed with two recommendations, so the SRT should consider whether to consolidate the recommendations. 

• SSAD SRT Initial Feedback on Straw Text for Rec. 5
  • Consolidating Rec. 5 and Rec. 8 seems appropriate here. Part of our remit is to ensure the modified recommendation make sense. 
  • Agree there is a lot of overlap, and Rec. 5 and Rec. 8 need to be aligned. We also need to align this with the Registration Data Policy.
  • Agree to streamlining these recommendations. This is part of what the Council means by looking at the recommendations as a package.  The end product should be a package of new recommendations that work together as a unit. 
  • There was a lot of feedback on Rec. 5 from the Standing Committee.  Most of this has been accounted for in Rec. 8, but we want to make sure that RDRS SC feedback is not lost when potentially combining recommendations. 
  • Ensure that in merging recommendations, there are no points that are lost or unaccounted for. 
  • From the requestor’s point of view, there is a big difference in whether the Registrar is trying to communicate what is insufficient in the request or if the request will be rejected no matter what - it is often hard to understand the intention of the registrar. 
  • The response should explain why the request was denied - the reason for rejection should be clear to the requestor about what was missing
  • There is also a section in draft Rec. 8, if the request cannot be determined based on what was provided, then the responding party should say so; however, if the response is an outright denial, the rationale will be provided in the response. 
  • Some businesses may choose to be more helpful to requestors. 

• Recommendation 7 
  • Recommendation 7 provides a non-exhaustive list of requestor purposes for submitting a disclosure request through the SSAD. 
  • Ultimately, the Standing Committee noted this Recommendation should remain as is. 
  • Similar to Rec. 3 and Rec. 5, the Standing Committee noted that additional tool tips or explanatory language could be added to the SSAD to assist Requestors in submitting proper requests. 
  • I’ll now turn the floor back over to Marc to walk through the recommendation language. 
  • Rec. 7 was very important to the requestor community, and the SC did not think this needed to be modified, in part because the recommendation includes a non-exhaustive list. 
  • Rationale text and additional implementation guidance has been added. 
  • 7.1.3 notes the Standing Committee’s recommendation to assist requestors by providing tool tips to submit proper requests. 

• SSAD SRT Initial Feedback to Straw Text for Rec. 7
  • The language re: data verification requests seems difficult to implement. Should this be adjusted? 
  • This is a situation where a client is going to purchase a corporation and needs to do due diligence on domain name portfolios. This was added because this type of situation is not accounted for in the above examples. 
  • If there are ways to make this more clear or implementable, we have the mandate to do this.
  • How were the examples chosen for 7.1.1? Is this supposed to be a dropdown or freeform? 
  • This was not intended to translate directly to a dropdown box or form; that is where Rec. 3 comes into play - what is necessary for a request. Rec. 7 is providing a non-exhaustive list of requestor purposes. 
  • Do we need Rec. 7? We already have Rec. 3 - maybe this is not needed. 
  • SRT to consider whether Rec. 7 is needed.

4. Next Steps on Rec Review (15 min)

· After today’s call, we will have done an initial readout of 10 of the 18 recommendations. 

· We will have an initial readout of the remaining 8 recommendations over the next three meetings. 

· As we go through our work, we’ll be getting updated text out to the group. Please continue providing input, and to the extent possible, provide proposed text to address your concerns. 

· Looking ahead, we will review Recs. 4, 9, and 18, at our next meeting, and we plan to run the meeting very similarly to this meeting. With that in mind, please familiarize yourself with the language of the original recommendations for Recs 4, 9, and 18. 

· There will be time to discuss the proposed changes and comments in the straw document as a group before moving to clean text. 

· It would be helpful for the Leadership Team to provide a chart of what has been reviewed, where updated text has been provided, and the schedule of upcoming review.

· We have circulated updated text from Rec. 6 and Rec. 8. 

· The text was updated based on the discussion at ICANN86. The slides reiterate what was covered via email, so we won’t go over this now.

· The straw person now adds a current clean version of the text for ease of reading - this is not meant to foreclose or discourage further discussion.

5. AOB (5 min)

• None.