I support Sarah's suggestion. With respect to "Registrars are also sensitive that the ability to adjust an outcome would cause fluctuation on the reporting metrics," adherence to the current design in order to keep the measurements comparable over time is the wrong perspective. It might have been a relevant perspective if the experiment had been designed more thoroughly and more carefully. However, the idea that the statistics being collected will provide a solid basis for future decision-making is wrong. The RDRS and the collection of data does not meet the basic requirements for validity for a statistical experiment. Sarah's feedback is far more relevant in terms of understanding what a system should look like and how to design a better system. Steve On Fri, Jun 21, 2024 at 9:14 AM Sarah Wyld via Gnso-rdrs-sc < gnso-rdrs-sc@icann.org> wrote:
Hello Team,
Several registrars have expressed a desire for 'request update' functionality to be built in to the RDRS. I thought it would be worth discussing before submitting it as a formal request in the Impressions Doc.
As reminder, there is no 'pending input' status; instead, a ticket is submitted and remains in 'open' status until the registrar closes it with a response outcome. This leads to some tickets remaining open for extended periods, as the registrar awaits input external to the RDRS.
What I hear from registrars is:
- I would like to to close a ticket because I asked for more info and then later when they provide it, change the outcome (to disclosed or denied as appropriate). This would let me log outcomes more accurately (indicating when I responded to the request) - I want to put tickets in a 'pending input' status and have them automatically close if the requestor does not provide more info within a specific timeframe. In that case then it would be useful to be able reopen the ticket instead of create a new one if the requestor comes back after that timeframe.
Registrars are also sensitive that the ability to adjust an outcome would cause fluctuation on the reporting metrics, however I think that since it would result in (a) fewer re-requests and (b) more accurate reported outcomes, and also since our purpose is primarily to track request volume which would be more correct if requests can be adjusted rather than duplicative requests being created, this seems like a positive change to me.
It would perhaps be worth considering if we could add a new metric to show how many requests were closed as requiring more info and then adjusted to a different outcome later on.
Thank you, --
*Sarah Wyld, CIPP/E*
Policy & Privacy Manager Pronouns: she/they
swyld@tucows.com _______________________________________________ Gnso-rdrs-sc mailing list -- gnso-rdrs-sc@icann.org To unsubscribe send an email to gnso-rdrs-sc-leave@icann.org
_______________________________________________ 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.
-- Sent by a Verified [image: Sent by a Verified sender] <https://wallet.unumid.co/authenticate?referralCode=tcp16fM4W47y> sender