June 2024 - Gnso-rdrs-sc - lists.icann.org

Upcoming RDRS Standing Committee calls
by Devan Reed Nov. 13, 2024

Nov. 13, 2024

**We are sending in advance to get dates on everyone’s calendar. Dear all, The .ics is attached for next 8 calls for the RDRS Standing Committee; dates are listed below. The calls take place at 17:30 UTC for 60 minutes. * Monday, 11 March 2024 (invite has been sent) * Monday, 25 March 2024 * Monday, 08 April 2024 * Monday, 22 April 2024 * Monday, 06 May 2024 * Monday, 20 May 2024 * Monday, 03 June 2024 * Monday, 17 June 2024 You should have received an email invite for the next meeting, 11 March; future invites will be sent out closer to the date of the calls. Thank you. With kind regards, Devan

2 1

Re: [Ext] RE: Link to RDRS in RDDS Lookup
by Lisa Carter July 2, 2024

July 2, 2024

Hi Gabriel & Sebastian, To add to what you have both discussed below, ICANN is currently looking into including some additional language and a link to RDRS in the following location on the results page for the domain lookup (see screenshot below). If you can please add your suggestions for the ICANN Lookup Tool (from the email below) to the Impressions Document, the request can be tracked and its progress documented. Thanks. Lisa Carter Sr. Program Manager, Strategic Initiatives ICANN From: Gabriel Andrews <gfandrews(a)fbi.gov> Date: Tuesday, June 18, 2024 at 9:32 AM To: "Sebastien(a)registry.godaddy" <Sebastien(a)registry.godaddy>, Lisa Carter <lisa.carter(a)icann.org>, "gnso-rdrs-sc(a)icann.org" <gnso-rdrs-sc(a)icann.org> Subject: [Ext] RE: Link to RDRS in RDDS Lookup Appreciate your thoughts on this Sebastien. Especially as you check in with your team to explore whether/how notification can be done “in the data”. For what it’s worth, I think your instinct to “go for the lookup box” is exactly consistent with user behavior. If I may expand on my thinking: the link to RDRS is most useful when it is a) presented alongside the notification that data has been redacted, and b) when it is agnostic of the query tool being used (meaning it will be seen regardless of whether the requestor is using godaddy.com/whois vs lookup.icann.org vs centralops.net vs domaintools vs command line etc). Any mechanism capable of satisfying those two principles would be welcome, but the only one I can think of is via having the RDDS (WHOIS/RDAP) data itself carrying the link to RDRS (i.e., presented “in the data”). As to why I view it important to be tool agnostic: it’s my understanding there are potentially thousands of WHOIS/RDAP lookup tools. Maybe more. Despite our familiarity as ICANN insiders with https://lookup.icann.org [lookup.icann.org] , I’d be surprised if it broke the top10 most commonly used in the wild. In LE circles, I knew a lot of case agents/analysts used centralops.net [centralops.net] , and so I had separately asked their admins to link to RDRS in their outputs; they were responsive and swift - but again, it only helps those who happen to use centralops… and does nothing for the other 10 or 100 or 1000 ways of doing the RDDS query. I happen to think centralops put their notification in as good a place as possible for users of their tool (after the user goes for the lookup box, as you can see below), but… a) it’s still not directly alongside the “REDACTED FOR PRIVACY” notification, meaning its still possible to be missed, and b) the challenge of how to reach the users of the other thousand ways of doing a WHOIS/RDAP query remain. Hence why I am so very grateful to you for exploring with your GoDaddy team whether/how awareness/promotion of RDRS can be put “in the Data”, to ensure that with the very same breath that the user is told that the data is redacted they are also told where they can go to request it. More along the lines of ~ With gratitude, G PS – This goes a bit in the weeds, but to expand upon a concern Sarah Wyld had voiced, in the RDAP response profile, there is a “MUST” in 2.7.4.3 which reads: … which carries an obligation for more text than I could fit into a single legible slide. If I interpret the policy correctly (inviting ICANN staff to tell me otherwise) the actual text output would have to include such text at minimum, but could include more (per IV.1.1.1) …and thus could read as: “REDACTED FOR PRIVACY Some of the data in this object has been removed. If you have lawful need of this data, visit rdrs.icann.org” Welcoming corrections to my understanding if I’m off base on this. From: Sebastien--- via Gnso-rdrs-sc <gnso-rdrs-sc(a)icann.org> Sent: Tuesday, June 18, 2024 2:00 AM To: Lisa Carter <lisa.carter(a)icann.org>; gnso-rdrs-sc(a)icann.org Subject: [EXTERNAL EMAIL] - [Gnso-rdrs-sc] Link to RDRS in RDDS Lookup Dear Team, After a number of requests to include RDRS information in the our Registration Data Lookup Tools, including in the latest GAC Communiqué - IV. Issues of Importance to the GAC - 6. Registration Data Request Service (RDRS), I have had a look at what I believe we do and could do better. On the ICANN site https://lookup.icann.org/en [lookup.icann.org] The information appears prominently on the landing page (second paragraph), but I suspect may be missed by people not specifically looking for it, because 1/ users will tend to go for the Lookup box before reading anything else, and 2/ because of the “Nonpublic registration data” title. Specifically looking for it, I managed to miss it on my first review of the page, try a random lookup to look for it on the response page, and find it only coming back to the landing page – I might not be the sharpest amongst us. Can I suggest? For the title of the paragraph to also contain Registration Data Request Service and RDRS - these are the terms we use in all our communications. Nonpublic registration data isn’t. The repeat the block at the bottom of the response page. It is at the point of not finding the sought data that RDRS will come most relevant. I am happy to add this to the new Impressions Document if there is any traction. ------------ As promised I am also engaging with GoDaddy Registrar and Registry to see if/how we could add the relevant at the bottom of our RDDS responses. Kindly, Sebastien Ducos GoDaddy Registry | Senior Client Services Manager +33612284445 France & Australia sebastien(a)registry.godaddy

2 2

Re: [Ext] RE: Email thread for discussing voluntary inclusion of ccTLDs
by Lisa Carter July 2, 2024

July 2, 2024

Hi Gabriel, Please find my comments to your questions below in red. Thanks Lisa Carter Sr. Program Manager, Strategic Initiatives ICANN From: Gabriel Andrews <gfandrews(a)fbi.gov> Date: Thursday, June 6, 2024 at 11:18 AM To: "gnso-rdrs-sc(a)icann.org" <gnso-rdrs-sc(a)icann.org>, Lisa Carter <lisa.carter(a)icann.org> Subject: [Ext] RE: Email thread for discussing voluntary inclusion of ccTLDs To continue the conversation: @ Lisa: Per your note that “all RDDS requirements for ccTLDs are Unstandardized/Unenforceable”, I think I might be missing your point, and hope to clarify ~ i. Speaking to “Unenforceable”, we seem to be in consensus that all RDRS participation is strictly voluntary, and that any ccTLD participation would also be voluntary. While participation in RDRS is voluntary, RDRS does rely on other contractual obligations for gTLD registries such as the availability and supported format of their WHOIS service (and RDAP in the future), obligations that do not exist for ccTLDs. ii. As for “Unstandardized”, is this to suggest that the lack of standardization is preventing ICANN from determining whether/not a ccTLD request is associated with a participating registrar? It was my understanding that the initial lookup done at the start of a RDRS request is always capable to determining the registrar, regardless of whether it’s gTLD or ccTLD. Is that incorrect? Similar to the above response, for RDRS to determine a domain name’s sponsoring registrar based on the registry operator’s WHOIS service, the service must be compliant with the relevant policy and contractual requirements which are not applicable to ccTLD registry operators, and define the location and supported formats of the WHOIS service. Additionally, determining the sponsoring registrar of a domain name is done using identifiers that are applicable only to ICANN-accredited registrars, which may not be the case for domain names in ccTLDs. iii. What LOE would it be to run the initial domain query as you already are, but only “error out for ccTLD” reasons if the query does not successfully identify a participating registrar? We are still assessing the level of effort (LOE), but we would likely require additional analysis to agree on the desired behavior and to consider new scenarios. That being said, based on a preliminary discussion with the team and considering the reasons outlined above, the likely LOE has been estimated to be 'very high' as indicated in the Impressions Document. @ all: Having heard from a small # of ccTLD operators a desire to participate in RDRS, i. Would voluntary ccTLD participation in RDRS help provide us lessons that might be factored into consideration of whether/how ccTLD voluntary mechanisms might be employed in a SSAD/ successor systems? /ps - added below an edit to the initial email, w the critical clarification “ccTLD” From: Andrews, Gabriel F. (STB) (FBI) Sent: Thursday, June 6, 2024 10:51 AM To: gnso-rdrs-sc(a)icann.org Subject: Email thread for discussing voluntary inclusion of ccTLDs Hi all – Noting the desire to “clean up” the impressions document, I hoped to shift from a margin comment conversation to an email conversation for the specific issue of whether/not RDRS can pass requests to participating registrars regardless of whether/not the domain is a ccTLD. Below are pasted the original feedback topic, and the subsequent margin comments. I will next respond to my own email (this) to continue the discussion, but wanted to make a clean break before adding anything new. Cheers, G Gabriel Andrews 11:33 AM May 22 Pinned for further discussion. Existing RDS/WHOIS queries provide this information a non-zero % of time - is this intended to say technical staff can't guarantee to have the info 100% of the time? Clarity sought. Anonymous 8:38 AM May 30 In other words: what other info does ICANN tech staff think is needed in order to route the request to the registrar as is done in gTLD contexts? Anonymous 8:39 AM May 30 Additionally: PSWG is hearing from some ccTLD operators their desire to voluntarily participate in RDRS, which may assist in solving any challenges. Lisa Carter 9:03 AM Today Just an FYI that RDDS requirements for ccTLDs are Unstandardized/Unenforceable as there is no contract for ccTLDs with ICANN.

2 5

Revising API Feedback: (via requestors shouldering more of the lift for RDRS API burden)
by Gabriel Andrews July 1, 2024

July 1, 2024

Hi Standing Committee Team, Sebastien: Would you kindly add to the agenda for the next call the discussion topic "API: Revised request to reduce ICANN staff burden / LOE" Having spoken with technical staff on my end, I sense an opportunity to shoulder some of the burden of the "API" request we'd previously assigned a high LoE to. This is taking the tack suggested by Steve Crocker to standardize connections from our end, rather than asking ICANN staff to create new API specific to the RDRS. If we can do this successfully, it might also help inform some important parallel work on issues pertaining to LE identity validation. There would still be an "ask" of ICANN staff, but a much reduced one: 1. We'd want a "test domain" we could use to query to test connections without tainting RDRS data collection. 2. We'd want a little help understanding ICANN's existing API structure > meaning asking ICANN to designating a technical point of contact (email address) that requestor group engineers could send technical q's to if needed. I'm hopeful this could shortcut an otherwise high level of effort ask, and remove a good deal of the burden for it from ICANN shoulders. I seek SC concurrence to bless ICANN staff to take actions 1 & 2 above. -Gabriel PS - Q for clarity: do we know if requestors receive an email from ICANN whenever the "status" of their request changes? I'm told by the engineers this could be relevant (and preferred).

1 1

Letter to Greg DiBiase and Council
by Sebastien＠registry.godaddy July 1, 2024

July 1, 2024

Dear Standing Committee, As discussed on our call last week, please find attached my proposed letter to Greg and Council suggesting/inviting Council or the Requestor+Responder communities directly, to further the more political questions of what constitute requests; allowing to focus on our Pilot Monitoring mandate. Please review and comment. Absent any changes I will send it following our call Monday. Kindly, Sebastien Ducos GoDaddy Registry | Senior Client Services Manager [signature_1642351011] +33612284445 France & Australia sebastien(a)registry.godaddy<mailto:sebastien@registry.godaddy>

5 9

REMINDER | Meeting Invitation | RDRS Standing Committee | Monday, 01 July 2024
by Devan Reed June 28, 2024

June 28, 2024

Dear all, The next RDRS Standing Committee call is scheduled for Monday, 01 July 2024 at 17:30 UTC for 60 minutes. To join - Zoom Information: Main Zoom Webinar link: https://icann.zoom.us/j/92181477886?pwd=TlJHTU5EY1d3bUxLV2s3UStPS2MxZz09 <https://urldefense.com/v3/__https:/icann.zoom.us/j/92181477886?pwd=TlJHTU5E…> Passcode: Z@S07?t=v5 Audio only option: Webinar ID: 921 8147 7886 Passcode: 3121016458 International numbers available: https://icann.zoom.us/u/acS1yc2A1 <https://urldefense.com/v3/__https:/icann.zoom.us/u/acS1yc2A1__;!!PtGJab4!9A…> Members, alternates, and observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send apologies to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior <https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Wiki agenda page: https://community.icann.org/x/DoC0F * Check your time zone: https://tinyurl.com/26w37hwk <https://urldefense.com/v3/__https:/tinyurl.com/26w37hwk__;!!PtGJab4!9skcrnq…> ONLY for Members & Alternates * Please join via the above Zoom Webinar link and staff will promote you to panelist. * Please select “ Everyone” when posting to the chat for everyone to see your chat and so it’s captured in the recording. Only for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. * Observers will not be able to use chat or raise hands. Thank you. Kind regards, Julie Policy Team Supporting the GNSO

1 0

REMINDER | Meeting Invitation | RDRS Standing Committee | Monday, 01 July 2024
by Terri Agnew June 27, 2024

June 27, 2024

Hello, We are resending invite as it was reported some did not receive this. Thanks! Terri From: Julie Bisland via Gnso-secs <gnso-secs(a)icann.org> Reply-To: Julie Bisland <julie.bisland(a)icann.org> Date: Monday, June 17, 2024 at 2:01 PM To: "gnso-rdrs-sc(a)icann.org" <gnso-rdrs-sc(a)icann.org> Cc: "gnso-secs(a)icann.org" <gnso-secs(a)icann.org> Subject: [gnso-secs] Meeting Invitation | RDRS Standing Committee | Monday, 01 July 2024 Dear all, The next RDRS Standing Committee call is scheduled for Monday, 01 July 2024 at 17:30 UTC for 60 minutes. To join - Zoom Information: Main Zoom Webinar link: https://icann.zoom.us/j/92181477886?pwd=TlJHTU5EY1d3bUxLV2s3UStPS2MxZz09 <https://urldefense.com/v3/__https:/icann.zoom.us/j/92181477886?pwd=TlJHTU5E…> Passcode: Z@S07?t=v5 Audio only option: Webinar ID: 921 8147 7886 Passcode: 3121016458 International numbers available: https://icann.zoom.us/u/acS1yc2A1 <https://urldefense.com/v3/__https:/icann.zoom.us/u/acS1yc2A1__;!!PtGJab4!9A…> Members, alternates, and observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send apologies to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior <https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Wiki agenda page: https://community.icann.org/x/DoC0F * Check your time zone: https://tinyurl.com/26w37hwk [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/26w37hwk__;!!PtGJab4!5MtYcR1…> ONLY for Members & Alternates * Please join via the above Zoom Webinar link and staff will promote you to panelist. * Please select “ Everyone” when posting to the chat for everyone to see your chat and so it’s captured in the recording. Only for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. * Observers will not be able to use chat or raise hands. Thank you. Kind regards, Julie Policy Team Supporting the GNSO

1 0

2024-06-17 RDRS Standing Committee - Meeting #10
by Feodora Hamza June 27, 2024

June 27, 2024

Dear RDRS Standing Committee, Please find below the main discussion points and action items from last week`s meeting. The next meeting is scheduled for Monday, 1 July at 17:30 UTC. Kind regards, Feodora and Caitlin 2024-06-17 RDRS Standing Committee - Meeting #10<https://community.icann.org/pages/viewpage.action?pageId=311230543> AI: SC Chair to send letter to GNSO Council and inform them about out-of-scope matters regarding RDRS and for them to share with CPH. AI: SC Chair suggested to inquire the GNSO Council about the follow up policy process after the RDRS pilot phase ends. AI: ICANN Org to investigate the possibility to represent integer numbers with percentage of total by month in total for Metric 8. (table on request types) AI: ICANN Org to go ahead and implement that change to metric 10 based on original request. AI: ICANN Org to consider percentage between ccTLD and gTLD request to see if ccTLD inclusion is warranted. AI: ICANN Org to complete the transition of old impressions document into new format by Monday 24 June. AI: SC members to add “ownership” of change request in new impressions document before next meeting. AI: ICANN Org to add additional columns on “impact for successor system”. AI: ICANN Org to consider an additional tap in impressions document for lessons learnt. AI: Chair to check with SC, who will attend on 1st of July? If the participants list is too low, the SC meeting will be moved to the week after. (8 July) 1. Welcome 2. ICANN80 RDRS Sessions Debrief/Discussion * There were 3 sessions taking place during ICANN80 that discussed RDRS * 1 working session, 2 community sessions * Outcome: mostly positive, some misunderstandings have been clarified like the privacy/proxy clarification. * SC members pointed out that some users might be overwhelmed with the terminology used on RDRS to explain the system. * SC members pointed out to some users that explained that their disclosure rate was lower via RDRS than having gone directly to the registrar. * SC members suggested that when we discuss enhancements, we should ask the following questions: Should we do it? And for what benefit? * SC members pointed out that there is a lack of awareness that the RDRS exists. Maybe more outreaches should be done? How are we measuring demand? AI: SC Chair to send letter to GNSO Council and inform them about out-of-scope matters regarding RDRS and for them to share with CPH. AI: SC Chair suggested to inquire the GNSO Council about the follow up policy process after the RDRS pilot phase ends. 1. RDRS Usage Metrics Report * Discuss and agree on the list of new metrics to add to the monthly reports * SC members suggested for Metric 8 that underneath each of the integer numbers in the table. What if we had a percentage of total? AI: ICANN Org to investigate the possibility to represent integer numbers with percentage of total by month in total for Metric 8. (table on request types) · ICANN Org asked for consent regarding change requests related to metric 10 – add the percentages and the number totals by month and since the launch of RDRS. AI: ICANN Org to go ahead and implement that change to metric 10 based on original request. · SC members asked to add percentage between ccTLD and gTLD request to see if ccTLD inclusion is warranted. ICANN will investigate adding this to Metric 10. · SC Chair provided historical reasons why ccTLDs were not included in the RDRS pilot phase. AI: ICANN Org to consider percentage between ccTLD and gTLD request to see if ccTLD inclusion is warranted. · ICANN Org explained there may be a small number of ccTLD requests compared to the gTLD requests. This might not show any significant number in percentage. ICANN org will investigate further and provide update to SC 1. RDRS System Enhancements * Next for Registrars i.Discuss and agree on the next enhancements (Priority 2, 6 & 7?) from the Impressions Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/14b6bG1Odmx-p…> · Next for Requesters i.Discuss and agree on the next enhancements (Priority 1, 2,or 3?) from Impressions Document 1. Update on Impression Document requested changes and management * New design of impressions document has been welcome. * Request by ICANN org for SC to provide all requests for enhancement in the document. AI: ICANN Org to complete the transition of old impressions document into new format by Monday 24 June. · New requests to the impressions document can then be added by SC after that. AI: SC members to add “ownership” of change request in new impressions document before next meeting. · SC members suggested adding an additional column for “impact on successor system”. This would allow a mechanism to make clear that SC is not asking for big issues to be solved within the next 18 months but highlighted that they need to be considered for the successor. AI: ICANN Org to add additional columns on “impact for successor system”. AI: ICANN Org to consider an additional tap in impressions document for lessons learnt. 6. AOB · Follow up on some questions from the Standing Committee on our last call. We did not get to cover this on the call. · Corrected Usage Metrics Reports for March and April have been published · Usage Metrics Report for May will be published this week. AI: Chair to check with SC, who will attend on 1st of July? If the participants list is too low, the SC meeting will be moved to the week after. (8 July) Feodora Hamza Policy Development Support Manager (GNSO) Internet Corporation for Assigned Names and Numbers (ICANN) Mobile: +32 496 30 24 15 Email: feodora.hamza(a)icann.org<mailto:feodora.hamza@icann.org> Website: www.icann.org<http://www.icann.org>

2 2

Re: RDRS Enhancements Released Today/
by Lisa Carter June 26, 2024

June 26, 2024

Hello All, The following RDRS enhancements have been released to production today: Registrar (NSp) Enhancements Request submission date now shows inside the request in Naming Service portal Request now defaults to have the accordion arrows open (instead of closed) so registrar can see the full request without clicks. Request List View – Last request in list should no longer be blocked by footer of the page RDRS (Platform) Requestor Enhancements: Address & phone number is now required; Organization/Affiliation field is new and optional Increased character limit from 1000 to 2000 for all open text boxes. Updated language to better explain what “expedited” means in RDRS Added language to explain that providing misleading content, including representing yourself as law enforcement if you are not employed by or an official representative of a law enforcement agency, is a violation of the RDRS Terms of Service. Thanks Lisa Lisa Carter Sr. Program Manager, Strategic Initiatives ICANN From: Lisa Carter <lisa.carter(a)icann.org> Date: Monday, June 17, 2024 at 7:29 AM To: Sarah Wyld <swyld(a)tucows.com>, "gnso-rdrs-sc(a)icann.org" <gnso-rdrs-sc(a)icann.org> Subject: Re: [Gnso-rdrs-sc] Re: Draft proposed agenda - RDRS Standing Committee Meeting - Monday, 17 June 2024 Hi Sarah, Yes, as mentioned in the previous Standing Committee meeting, the next set of enhancements will be released at the end of June. I am reviewing all items for the release with our team on Thursday this week, with the goal of releasing the items next week. Kind regards, Lisa Carter Sr. Program Manager, Strategic Initiatives ICANN From: Sarah Wyld via Gnso-rdrs-sc <gnso-rdrs-sc(a)icann.org> Organization: Tucows Reply-To: Sarah Wyld <swyld(a)tucows.com> Date: Monday, June 17, 2024 at 5:10 AM To: "gnso-rdrs-sc(a)icann.org" <gnso-rdrs-sc(a)icann.org> Subject: [Gnso-rdrs-sc] Re: Draft proposed agenda - RDRS Standing Committee Meeting - Monday, 17 June 2024 Hi all, Thanks for this agenda, Caitlin! Is an update on the rollout of the current round of changes part of item 4? I look forward to confirmation that the address field is mandatory, etc. Thank you! Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/they swyld(a)tucows.com On 2024-06-16 5:20 a.m., Caitlin Tubergen via Gnso-rdrs-sc wrote: Dear RDRS Standing Committee Members, With apologies for the delay, please find below the agenda for the upcoming meeting of the RDRS Standing Committee on Monday, 17 June 2024 at 17:30 UTC. Best regards, Feodora and Caitlin -- RDRS Standing Committee Meeting Monday, 17 June 2024 at 17:30 UTC Proposed Agenda Welcome ICANN80 RDRS Sessions Debrief/Discussion RDRS Usage Metrics Report Discuss and agree on the list of new metrics to add to the monthly reports RDRS System Enhancements Next for Registrars 1. Discuss and agree on the next enhancements (Priority 2, 6 & 7?) from the Impressions Document [docs.google.com] Next for Requestors 1. Discuss and agree on the next enhancements (Priority 1, 2,or 3?) from Impressions Document Update on Impression Document requested changes and management AOB Follow up on some questions from the Standing Committee on our last call Corrected Usage Metrics Reports for March and April have been published Usage Metrics Report for May will be published this week. _______________________________________________ Gnso-rdrs-sc mailing list -- gnso-rdrs-sc(a)icann.org To unsubscribe send an email to gnso-rdrs-sc-leave(a)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.

2 1

Rr Request - update outcomes
by Sarah Wyld June 25, 2024

June 25, 2024

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(a)tucows.com

3 3