Thanks Gabriel for updated item 7 to include the additional information.  I will check with our technical team about providing an updated LOE for this request. Best, Lisa Carter Sr. Program Manager, Strategic Initiatives ICANN From: Gabriel Andrews via Gnso-rdrs-sc <gnso-rdrs-sc@icann.org> Reply-To: Gabriel Andrews <gfandrews@fbi.gov> Date: Monday, July 1, 2024 at 12:01 PM To: "gnso-rdrs-sc@icann.org" <gnso-rdrs-sc@icann.org> Cc: "Sebastien@registry.godaddy" <Sebastien@registry.godaddy> Subject: [Gnso-rdrs-sc] Re: Revising API Feedback: (via requestors shouldering more of the lift for RDRS API burden) This request has now been updated in Item 7 in the revised impressions document [docs.google.com]. Per the call, committee wanted to know the level of effort for creation of a “test domain” that can be used without influencing the RDRS data collection. Committee was seen as not needing to approve creation of technical PoC email address to respond to RDRS technical questions; no objections to ICANN staff taking this action were raised. G From: Andrews, Gabriel F. (STB) (FBI) Sent: Friday, June 28, 2024 11:05 AM To: gnso-rdrs-sc@icann.org Cc: Sebastien@registry.godaddy Subject: Revising API Feedback: (via requestors shouldering more of the lift for RDRS API burden) 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: We’d want a “test domain” we could use to query to test connections without tainting RDRS data collection. 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).