Dear Steve,

Thank you for sharing these details and suggestions with us. Please find below the project team’s responses:

“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.”
- ICANN org response: Thank you for this suggestion. We are incorporating this into the next version of the metrics report, to be published in February.
“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?”
  - ICANN org response: Some of the metrics in the report are not time-bound due to the statistical software we are using to pull data from the RDRS. While most of the data is extracted based on the set time frame (in this case from 28 Nov. to 31 Dec.), several metrics reflect the data as of the time we pulled it.

The number of ‘open requests’ in Metric 11 is not time-bound. These reflect the total requests submitted since the system’s launch to requestors on 28 Nov, 2023. Whereas Metrics 10 and 12 are limited to the reporting period of 28 Nov.-31 Dec. 2023. Consequently, the data will not add up perfectly depending on when it was pulled. While ICANN org will be running the report as close to the set time frame as possible to minimize this issue, we are unable to completely eliminate this discrepancy.

Essentially, the ‘open requests’ metric counts all requests created between dates A and B that are not canceled and do not have a decision date set. The ‘closed request’ metric counts all requests with a decision date between dates A and B and have a status that is not pending, submitted, or canceled. So, there may be some shift to the numbers as a request opened in December and closed in January does not reconcile itself until the following report etc. In addition, it’s important to note that an open request does not necessarily mean open within the reporting period but one that was open up until the reporting period came to a close.

The team plans to explore how to better define these nuances within the upcoming reporting periods to provide clarity for the reader.

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.”

§ ICANN org response: The registrar can choose more than one reason as their denial reason for any given request, thus, metrics 14.1-14.7 added together will not match up with the total number of denied requests as reflected in metric 13.2.

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

§ ICANN org response: The registrar always has the option to communicate with the requestor outside the system if they require further information or must do so to provide the registration data if the request is approved. ICANN org will share this feedback with registrars as it engages with them to better understand their experiences in issuing denials. Greater usage over time may reveal what guidance would be helpful to requestors and registrars, as we gain greater insight from requestor feedback surveys about their experiences or guidance provided when their requests have been denied. In addition, ICANN org will engage with registrars to understand how they are using this service, and explore ways to improve the communication.

I hope this information is helpful. Please let me know of any further clarity we can provide on the data.

Thank you again for your feedback,

Eleeza

From: Gnso-rdrs-sc <gnso-rdrs-sc-bounces@icann.org> on behalf of Steve Crocker <steve@shinkuro.com>
Date: Monday, January 22, 2024 at 6:54 PM
To: "gnso-rdrs-sc@icann.org" <gnso-rdrs-sc@icann.org>, "gnso-secs@icann.org" <gnso-secs@icann.org>
Subject: [Gnso-rdrs-sc] Follow up comments re RDRS Usage Metrics

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 [groups.google.com] (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