2. are you intending “underlying registration data” to mean “information pertaining to the customer of the affiliated privacy or proxy service”? Yes, I am. I didn't want to change too much content, so I was not looking to add a definition, Also, as this is not a PDP, I would assume a definition here would only pertain to this specific report.  I was just trying to clarify, maybe I missed that mark, but since we read it the "same" maybe not.

3. I think I understood in past discussion the two key obstacles identified by RrSG to the RDRS functioning for Urgent Request purposes were a) lack of authentication of (in particular LEA) requestors, and b) lack of push functionality to notify the Rr when a request was made. That was my concern, mostly the immediacy of relay. I don't have an issue with enumerating these, but again I was trying to not be too verbose.

Roger et al –

1. Re: 3.4, constructive edits.
2. Re: 4.1, this is a good example of why its going to be very important for us to all be sure we’re using the same words the same ways. I think I understand and agree with your suggestion here, but to clarify, when you write: 

“We note that in a few places the report references the option to "disclose the information associated with Affiliated P/P Providers" when in fact the data would be the underlying registration data (not the Providers’ data), this should be clarified. ”

… are you intending “underlying registration data” to mean “information pertaining to the customer of the affiliated privacy or proxy service”?  I think you are… just want to be sure I’m not misunderstanding.   If yes, perhaps we might wish to define the term “underlying registration data” (for the purpose of this report) and use it as consistent shorthand throughout?

3. Re: #6 Priority Levels, you write:

“The Registrars believe that in its current form, the RDRS is not the appropriate system to use for Urgent requests as defined in the in-progress Registration Data Policy implementation work.”

I think I understood in past discussion the two key obstacles identified by RrSG to the RDRS functioning for Urgent Request purposes were a) lack of authentication of (in particular LEA) requestors, and b) lack of push functionality to notify the Rr when a request was made.   Is that correct?  If yes, it could be constructive to enumerate those two points as the functional prerequisites.

G

Good Afternoon,

After review, the RrSG would like to suggest a few clarifying edits to make the document more readable and accurate:

1. Recommendation Rationale for 3.4

The RDRS is currently voluntary for registrars, but requestors may not know which registrars are not participating. For that reason, if a requestor submits a request only to receive a response of, “Registrar is not participating in RDRS,” that is an unsatisfactory experience for the requestor. In circumstances where a non-participating registrar provides a link to their request form or request system, and that link is then included in RDRS responses involving the non-participating registrar, this would improve the requestor experience by directing the requestor to the appropriate place to send a request.  

The word "currently" should be removed as it is unnecessary; the RDRS is voluntary for registrars. 

A request cannot be submitted if the registrar is not participating; this should instead say "attempts to initiate a request" or "performs a search".

2. 4.1. Privacy/Proxy Data

The RDRS SC notes that there is currently no requirement for registrars to disclose P/P data within the RDRS or SSAD. While some participating registrars voluntarily choose to disclose the information associated with Affiliated P/P Providers, the Standing Committee recommends, based on the feedback from requestors, the GNSO Council should consider the question of if there should be a requirement for registrars to disclose P/P information from Affiliated P/P Providers in the RDRS or its successor for further policy work. 

The key issue here is the use of the term disclose. There is no requirement under any ICANN Policy or contract to disclose registration data, including in the context of domains using a registrar’s Affiliated Privacy service. The words “currently” and "within the RDRS or SSAD" should be removed from the first sentence, and “disclose” in the last sentence should be changed to “consider requests for underlying data”. 

The Standing Committee should recommend the Council consider if the request process for disclosure requests for domains registered with Affiliated Privacy service domains can be improved or streamlined; the Council cannot mandate registrars to disclose P/P information or underlying registration data as only the registrar can make that disclosure determination.

We note that in a few places the report references the option to "disclose the information associated with Affiliated P/P Providers" when in fact the data would be the underlying registration data (not the Providers’ data), this should be clarified.  

3. Chart - #6 Priority levels

“For “urgent requests” specifically, the SC notes that timelines for this category of requests are currently being discussed within the EPDP Phase 1 Implementation Review Team. Any agreement on timelines for urgent requests under the Registration Data Policy need to match what is in RDRS for consistency”

The Registrars believe that in its current form, the RDRS is not the appropriate system to use for Urgent requests as defined in the in-progress Registration Data Policy implementation work. As such, the second sentence should be removed.

Thanks

Roger

From: Feodora Hamza via Gnso-rdrs-sc <gnso-rdrs-sc@icann.org>
Sent: Wednesday, October 29, 2025 1:50 AM
To: gnso-rdrs-sc@icann.org <gnso-rdrs-sc@icann.org>
Subject: [Gnso-rdrs-sc] Re: Kind reminder: For review: Updated draft RDRS SC report

Dear RDRS SC, a kind reminder for the below. Draft Report: https: //docs. google. com/document/d/1K3SbhEInIGpY5idi_LWpzFR5tLova63A/edit?usp=sharing&ouid=117322705262957836966&rtpof=true&sd=true [docs. google. com]. Kind regards, Feodora

ZjQcmQRYFpfptBannerStart

ZjQcmQRYFpfptBannerEnd

Dear RDRS SC,

a kind reminder for the below.

Draft Report: https://docs.google.com/document/d/1K3SbhEInIGpY5idi_LWpzFR5tLova63A/edit?usp=sharing&ouid=117322705262957836966&rtpof=true&sd=true [docs.google.com].

Kind regards,

Feodora

Dear RDRS SC,

hope you are enjoying Dublin.

This is a kind reminder to review the updated RDRS report based on the RDRS discussions at ICANN84. Please review the document and suggest if anything has not been reflected properly or if we should amend any language by 29 October 16:00 IST. If there are any concerns raised by the deadline, we will keep the RDRS SC session on Wednesday to discuss those concerns. If there are no further substantial comments, we would cancel that session.

The SC agreed to include  (highlighted in green)

• A brief intro how PC has been considered in the report
• A summary of the PC under each recommendation/rationale
• The additional rec item 3.4
• Additional rationale based on PC in the rec 5 table
• Updates to the rec 5 table on SSAD rec 10 and 17 in terms of how the rec should be treated

Draft Report: https://docs.google.com/document/d/1K3SbhEInIGpY5idi_LWpzFR5tLova63A/edit?usp=sharing&ouid=117322705262957836966&rtpof=true&sd=true [docs.google.com].

Kind regards,

Feodora

Dear RDRS SC,

Thank you for today`s sessions. As discussed, please find below the link the the updated RDRS SC report.

The SC agreed to include  (highlighted in green)

• A brief intro how PC has been considered in the report
• A summary of the PC under each recommendation/rationale
• The additional rec item 3.4
• Additional rationale based on PC in the rec 5 table
• Updates to the rec 5 table on SSAD rec 10 and 17 in terms of how the rec should be treated

https://docs.google.com/document/d/1K3SbhEInIGpY5idi_LWpzFR5tLova63A/edit?usp=sharing&ouid=117322705262957836966&rtpof=true&sd=true [docs.google.com].

The sections have been updated based on today’s discussion.

Please review the document and suggest if anything has not been reflected properly or if we should amend any language by 29 October 16:00 IST

Thank you and enjoy ICANN84.

Kind regards,

Feodora and Caitlin