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.

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.
  
  
• 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?
  
  
• 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.