Hi all, I missed the meeting due to vacation and look forward to catching up with the recording. However, I do want to respond to this point: /> The refusal to allow registrants to check the data in their own registration is a mistake.  This is the first thing a registrant would do in order to develop confidence the system is working properly./ RDRS is not built to support registrants, they have no need to develop confidence in the system. If a registrant wants to confirm that their data is accurate, they should check it in the interface provided by their registrar. If a requestor believes that they're being given registration data that does not match what the registrant has listed on the domain then that's a larger issue and not an RDRS issue. If a requestor believes that they are being given what the registrant has listed and that listed data is inaccurate then there is already a process to report that and trigger an investigation. Processing registration data disclosure requests takes time and costs real money. The Board needs to see accurate data about the overall landscape of disclosure requests, which is not intended to include disclosure to the domain owner (just like how the eventual SSAD is not being contemplated for the purpose of letting domain owners see their own data). We need to ensure that the RDRS is used as intended. *Sarah Wyld, CIPP/E* Policy & Privacy Manager Pronouns: she/they swyld@tucows.com On 2024-01-22 9:54 p.m., Steve Crocker wrote:

During the call today I agreed to send an email with my comments on the first RDRS Usage Metrics report.

* Please use two columns for the data in the Summary.  Use one column for the current reporting period and the other column for the total.  This will cut the number of rows in half and make it easier for the reader to see trends.

* Several of us tried to get the numbers to add up, but there were some discrepancies.  I didn't try to cross check all of the numbers.  The following are just the ones I checked.

o I expected 10.1 (219) to be the sum of 11 (88) and 12.1 (128), but these only add up to 216.  What happened to the other three requests?

o 14.1 through 14.7 subdivide the reasons for denial. They add up to 135.  I expected this to match 13.2 (Denied) which is only 103.

* In the response from the registrar, the reasons for denial and how to repair the defect need to be clearer and more detailed.

* The refusal to allow registrants to check the data in their own registration is a mistake.  This is the first thing a registrant would do in order to develop confidence the system is working properly.

As a separate matter I created an open mailing list for anyone who wants to share their experience with the RDRS.

The mailing list is rdrs-requesters-sharing@shinkuro.com.

The list is completely open.

* Anyone may send a message to the list.  If this becomes unwieldy, I'll impose some restrictions.

* Anyone is permitted to join this list.  Joining the list means you'll see the messages that are sent.

The URL is https://groups.google.com/a/shinkuro.com/g/rdrs-requesters-sharing (I believe you have to sign into Google Groups to be able to join.)  Alternatively, send me a message and I'll be glad to add you.

Feel free to share this message with your colleagues or anyone else.

Feel free to send to the list suggestions about how to use the data accumulated on this list.

Feel free to send me suggestions you don't wish to share publicly.

Thanks,

Steve

_______________________________________________ Gnso-rdrs-sc mailing list Gnso-rdrs-sc@icann.org https://mm.icann.org/mailman/listinfo/gnso-rdrs-sc

_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.

Hi Gabe and Team, I still think this (RNH request for their own domain data) is scope creep. If we look at the EPDP Phase 2 report, we can see that Rec 7 Requestor Purposes lays out several reasons to request data and does *not *include the domain owner wanting to review/confirm their own data. Certainly some data subjects may want to do this, but it's not what the RDRS (or eventual SSAD) is for. Further, domain owners should not expect that the data they receive (about themselves) is the same */set/***of data that would be disclosed to a requestor (as you mention, "to see what data RDRS returns to other requestors whensoever a decision to disclose is made"). In some cases only a */subset /*of the full data set is disclosed to a third party, e.g. only an email address, and so the domain owner may indeed receive more data than someone else looking into the same domain name with a different purpose/legal basis. As such, it could give the domain owner a confusing or incorrect understanding of what other RDRS users will see. Yes, we should gather data about all the requests that happen in the RDRS, but especially as members of this Standing Committee we should understand the purpose of the RDRS and stick to those boundaries so that we can gather the necessary data, allow registrars to address appropriate requests without being required to expend resources on out-of-scope requests, and eventually give the Board the data that they asked for. *Sarah Wyld, CIPP/E* Policy & Privacy Manager Pronouns: she/they swyld@tucows.com On 2024-01-23 12:35 p.m., Gabriel Andrews wrote:

/“We need to ensure that the RDRS is used as intended.”///

Respectfully, Sarah, I find myself disagreeing with the sentiment, insofar as it seems to assume we know better than requestors why they’d want to request data.  I confess I wasn’t privy to all of this teams earlier discussions, and thus my understanding of what the RDRS is /intended/ to do is based on ICANN’s published documents, but from those, the intent of RDRS seems clearly intended “*/to gather/* */usage and demand data/*”.  Whether or not we properly anticipated the demand by registrants to self query (e.g., to see what data RDRS returns to other requestors whensoever a decision to disclose is made), it now appears obvious that such a demand exists.  Any eventual SSAD, it seems, should also anticipate such self-query demand. I’d suggest we gather data about it.  And if other (legally valid) requests are made for equally unanticipated reasons, I’d suggest we gather data about those, too.

This isn’t to discount or ignore the real world costs associated with such requests, mind you, but as we heard yesterday from some of our registrars counterparts, overall demand isn’t as high as some feared it might be at the start, so perhaps we can gather data on the costs associated with this self-query subtype of demand before assuming they are unsustainable?

~G

PS- providing context for the quotation, from ICANN’s RDRS FAQ <https://www.icann.org/en/system/files/files/rdrs-requestors-faqs-07nov23-en....>:

What is the Registration Data Request Service (RDRS)? …/The service *is intended to gather usage and demand data that can inform the ICANN Board’s consideration of the requirements related to a System for Standardized Access/Disclosure (SSAD)*, and ongoing consultations with the Generic Names Supporting Organization (GNSO) Council who developed these recommendations./

*From:* Gnso-rdrs-sc <gnso-rdrs-sc-bounces@icann.org> *On Behalf Of *Sarah Wyld *Sent:* Tuesday, January 23, 2024 7:11 AM *To:* gnso-rdrs-sc@icann.org *Subject:* [EXTERNAL EMAIL] - Re: [Gnso-rdrs-sc] Follow up comments re RDRS Usage Metrics

Hi all,

I missed the meeting due to vacation and look forward to catching up with the recording. However, I do want to respond to this point:

/> //The refusal to allow registrants to check the data in their own registration is a mistake.  This is the first thing a registrant would do in order to develop confidence the system is working properly./

RDRS is not built to support registrants, they have no need to develop confidence in the system. If a registrant wants to confirm that their data is accurate, they should check it in the interface provided by their registrar.

If a requestor believes that they're being given registration data that does not match what the registrant has listed on the domain then that's a larger issue and not an RDRS issue. If a requestor believes that they are being given what the registrant has listed and that listed data is inaccurate then there is already a process to report that and trigger an investigation.

Processing registration data disclosure requests takes time and costs real money. The Board needs to see accurate data about the overall landscape of disclosure requests, which is not intended to include disclosure to the domain owner (just like how the eventual SSAD is not being contemplated for the purpose of letting domain owners see their own data). We need to ensure that the RDRS is used as intended.

*Sarah Wyld, CIPP/E*

Policy & Privacy Manager Pronouns: she/they

swyld@tucows.com

On 2024-01-22 9:54 p.m., Steve Crocker wrote:

During the call today I agreed to send an email with my comments on the first RDRS Usage Metrics report.

* Please use two columns for the data in the Summary.  Use one column for the current reporting period and the other column for the total.  This will cut the number of rows in half and make it easier for the reader to see trends. * Several of us tried to get the numbers to add up, but there were some discrepancies.  I didn't try to cross check all of the numbers.  The following are just the ones I checked.

o I expected 10.1 (219) to be the sum of 11 (88) and 12.1 (128), but these only add up to 216.  What happened to the other three requests? o 14.1 through 14.7 subdivide the reasons for denial. They add up to 135.  I expected this to match 13.2 (Denied) which is only 103.

* In the response from the registrar, the reasons for denial and how to repair the defect need to be clearer and more detailed. * The refusal to allow registrants to check the data in their own registration is a mistake.  This is the first thing a registrant would do in order to develop confidence the system is working properly.

As a separate matter I created an open mailing list for anyone who wants to share their experience with the RDRS.

The mailing list is rdrs-requesters-sharing@shinkuro.com.

The list is completely open.

·Anyone may send a message to the list.  If this becomes unwieldy, I'll impose some restrictions.

·Anyone is permitted to join this list.  Joining the list means you'll see the messages that are sent.

The URL is https://groups.google.com/a/shinkuro.com/g/rdrs-requesters-sharing (I believe you have to sign into Google Groups to be able to join.)  Alternatively, send me a message and I'll be glad to add you.

Feel free to share this message with your colleagues or anyone else.

Feel free to send to the list suggestions about how to use the data accumulated on this list.

Feel free to send me suggestions you don't wish to share publicly.

Thanks,

Steve

_______________________________________________

Gnso-rdrs-sc mailing list

Gnso-rdrs-sc@icann.org

https://mm.icann.org/mailman/listinfo/gnso-rdrs-sc

_______________________________________________

By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.

Hi, "registrants may want to know which subsets of their data will be returned to various classes of requesters." - sure, but getting their own data from RDRS won't answer that. *Sarah Wyld, CIPP/E* Policy & Privacy Manager Pronouns: she/they swyld@tucows.com On 2024-01-23 3:25 p.m., Steve Crocker wrote:

Sarah,

Thanks for your detailed response.  Your comment that different sets of data might be disclosed to different requesters is particularly helpful.  As you're already seeing, some requesters will want to check that the data returned for their registrations is consistent with what they expect.  As you've pointed out, that's outside the specified scope of the RDRS. That said, to simply rule this out of scope is not likely to remove the pressure to support this use case.  Further, in keeping with your comment, registrants may want to know which subsets of their data will be returned to various classes of requesters.

Steve

On Tue, Jan 23, 2024 at 1:18 PM Sarah Wyld <swyld@tucows.com> wrote:

Hi Gabe and Team,

I still think this (RNH request for their own domain data) is scope creep.

If we look at the EPDP Phase 2 report, we can see that Rec 7 Requestor Purposes lays out several reasons to request data and does *not *include the domain owner wanting to review/confirm their own data. Certainly some data subjects may want to do this, but it's not what the RDRS (or eventual SSAD) is for.

Further, domain owners should not expect that the data they receive (about themselves) is the same */set/***of data that would be disclosed to a requestor (as you mention, "to see what data RDRS returns to other requestors whensoever a decision to disclose is made"). In some cases only a */subset /*of the full data set is disclosed to a third party, e.g. only an email address, and so the domain owner may indeed receive more data than someone else looking into the same domain name with a different purpose/legal basis. As such, it could give the domain owner a confusing or incorrect understanding of what other RDRS users will see.

Yes, we should gather data about all the requests that happen in the RDRS, but especially as members of this Standing Committee we should understand the purpose of the RDRS and stick to those boundaries so that we can gather the necessary data, allow registrars to address appropriate requests without being required to expend resources on out-of-scope requests, and eventually give the Board the data that they asked for.

*Sarah Wyld, CIPP/E*

Policy & Privacy Manager Pronouns: she/they

swyld@tucows.com

On 2024-01-23 12:35 p.m., Gabriel Andrews wrote:

...

/“We need to ensure that the RDRS is used as intended.”/

Respectfully, Sarah, I find myself disagreeing with the sentiment, insofar as it seems to assume we know better than requestors why they’d want to request data.  I confess I wasn’t privy to all of this teams earlier discussions, and thus my understanding of what the RDRS is /intended/ to do is based on ICANN’s published documents, but from those, the intent of RDRS seems clearly intended “*/to gather/* */usage and demand data/*”. Whether or not we properly anticipated the demand by registrants to self query (e.g., to see what data RDRS returns to other requestors whensoever a decision to disclose is made), it now appears obvious that such a demand exists.  Any eventual SSAD, it seems, should also anticipate such self-query demand. I’d suggest we gather data about it.  And if other (legally valid) requests are made for equally unanticipated reasons, I’d suggest we gather data about those, too.

This isn’t to discount or ignore the real world costs associated with such requests, mind you, but as we heard yesterday from some of our registrars counterparts, overall demand isn’t as high as some feared it might be at the start, so perhaps we can gather data on the costs associated with this self-query subtype of demand before assuming they are unsustainable?

~G

PS- providing context for the quotation, from ICANN’s RDRS FAQ <https://www.icann.org/en/system/files/files/rdrs-requestors-faqs-07nov23-en....>:

What is the Registration Data Request Service (RDRS)? …/The service *is intended to gather usage and demand data that can inform the ICANN Board’s consideration of the requirements related to a System for Standardized Access/Disclosure (SSAD)*, and ongoing consultations with the Generic Names Supporting Organization (GNSO) Council who developed these recommendations./

*From:* Gnso-rdrs-sc <gnso-rdrs-sc-bounces@icann.org> <mailto:gnso-rdrs-sc-bounces@icann.org> *On Behalf Of *Sarah Wyld *Sent:* Tuesday, January 23, 2024 7:11 AM *To:* gnso-rdrs-sc@icann.org *Subject:* [EXTERNAL EMAIL] - Re: [Gnso-rdrs-sc] Follow up comments re RDRS Usage Metrics

Hi all,

I missed the meeting due to vacation and look forward to catching up with the recording. However, I do want to respond to this point:

/> //The refusal to allow registrants to check the data in their own registration is a mistake.  This is the first thing a registrant would do in order to develop confidence the system is working properly./

RDRS is not built to support registrants, they have no need to develop confidence in the system. If a registrant wants to confirm that their data is accurate, they should check it in the interface provided by their registrar.

If a requestor believes that they're being given registration data that does not match what the registrant has listed on the domain then that's a larger issue and not an RDRS issue. If a requestor believes that they are being given what the registrant has listed and that listed data is inaccurate then there is already a process to report that and trigger an investigation.

Processing registration data disclosure requests takes time and costs real money. The Board needs to see accurate data about the overall landscape of disclosure requests, which is not intended to include disclosure to the domain owner (just like how the eventual SSAD is not being contemplated for the purpose of letting domain owners see their own data). We need to ensure that the RDRS is used as intended.

*Sarah Wyld, CIPP/E*

Policy & Privacy Manager Pronouns: she/they

swyld@tucows.com

On 2024-01-22 9:54 p.m., Steve Crocker wrote:

During the call today I agreed to send an email with my comments on the first RDRS Usage Metrics report.

* Please use two columns for the data in the Summary.  Use one column for the current reporting period and the other column for the total.  This will cut the number of rows in half and make it easier for the reader to see trends. * Several of us tried to get the numbers to add up, but there were some discrepancies.  I didn't try to cross check all of the numbers.  The following are just the ones I checked.

o I expected 10.1 (219) to be the sum of 11 (88) and 12.1 (128), but these only add up to 216.  What happened to the other three requests? o 14.1 through 14.7 subdivide the reasons for denial.  They add up to 135.  I expected this to match 13.2 (Denied) which is only 103.

* In the response from the registrar, the reasons for denial and how to repair the defect need to be clearer and more detailed. * The refusal to allow registrants to check the data in their own registration is a mistake.  This is the first thing a registrant would do in order to develop confidence the system is working properly.

As a separate matter I created an open mailing list for anyone who wants to share their experience with the RDRS.

The mailing list is rdrs-requesters-sharing@shinkuro.com.

The list is completely open.

·Anyone may send a message to the list.  If this becomes unwieldy, I'll impose some restrictions.

·Anyone is permitted to join this list.  Joining the list means you'll see the messages that are sent.

The URL is https://groups.google.com/a/shinkuro.com/g/rdrs-requesters-sharing (I believe you have to sign into Google Groups to be able to join.) Alternatively, send me a message and I'll be glad to add you.

Feel free to share this message with your colleagues or anyone else.

Feel free to send to the list suggestions about how to use the data accumulated on this list.

Feel free to send me suggestions you don't wish to share publicly.

Thanks,

Steve

_______________________________________________

Gnso-rdrs-sc mailing list

Gnso-rdrs-sc@icann.org

https://mm.icann.org/mailman/listinfo/gnso-rdrs-sc

_______________________________________________

By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.

_______________________________________________ Gnso-rdrs-sc mailing list Gnso-rdrs-sc@icann.org https://mm.icann.org/mailman/listinfo/gnso-rdrs-sc

_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.