Steve,
Good points. I think we learned from the RDRS pilot that measuring SLAs for a system like this is a little nuanced and there needs to be clarity on when the clock starts and stops. Section 10.2 of the straw-person
document has the applicable language:
10.2. For purposes of calculating SLA response time, the EPDP Team recommends the SLA starts when a validated request with all supporting information is provided to the
Registrar by the SSAD and stops when the Registrar responds with either the information requested, a rejection response, or a request for additional information. A reexamination request or a Requestor response with more information would
be considered the start of a new request for SLA calculation purposes.
Please take a look and provide any suggestions you have to improve the language.
Thank you,
Marc
From: Steve Crocker <steve@shinkuro.com>
Sent: Wednesday, June 3, 2026 3:37 AM
To: Anderson, Marc <mcanderson@verisign.com>
Cc: gnso-ssad@icann.org; Steve Crocker <steve@shinkuro.com>
Subject: [EXTERNAL] Re: [Gnso-ssad] SSAD SRT - Straw person citations
|
Caution: This email originated from outside the organization. Do not click links or open attachments unless you
recognize the sender and know the content is safe. |
Marc,
Thanks for this. Let me add one small comment. about SLAs in this context. In earlier discussions about the SLA for Urgent Requests, it became clear to me that the registrars intend
to start the clock when a request is received, and the notion of "received" likely means after someone has seen the request. For requests transmitted through the RDRS, there might be a considerable delay between when the Requestor submitted the request and
when someone in the registrar's people see it due to weekends and holidays.
If we're going to specify an SLA, let's make sure to be clear about the period of time being measured.
Thanks,
Steve
On Tue, Jun 2, 2026 at 2:56 PM Anderson, Marc via Gnso-ssad <gnso-ssad@icann.org>
wrote:
Dear SSAD SRT Members,
Per the good suggestion of a few of you, Support Staff has gone through and added citations and relevant page numbers to the Straw Person.
In many instances, particularly for the LOW LOE recommendations, there is a clear tie to what the RDRS SC recommended and the associated modifications in the Straw Person. In other instances, the RDRS SC may have provided a recommendation such as, "allow for authentication of interested requestor groups, beginning with law enforcement" or "SLAs should be a component of RDRS/successor system, but additional consideration should be given as to how to calculate and report on them in a balanced way" without explaining in detail how to do that. In an instance like that, we took a first cut of how that could happen, but there isn't necessarily clear language as to how to do that or a clear citation to each word in the Straw Person. I believe this provides a good starting point for our discussion.
We have endeavored to consider the interests of all stakeholders, but as we have previously noted and emphasized, we may have missed something or gotten something wrong. It is now the Team's job to closely review the Straw Person and explain, with a rationale, how this could be improved to get to modified recommendations that are implementable, consider the needs around the table, and can be adopted by the Board.
This is a starting point for the team to dive into its work and assignment. While it may not be perfect, a lot of work has gone into this, including providing specific pages of the report for everyone to review. We have done this to help the Team do its job and effectively prepare for ICANN86. There is no perfect Straw Person, but I have closely reviewed this document, and I hope the added citations help provide some clarity to the modified recommendations.
I look forward to hearing constructive discussions in Seville and making progress on our work soon.
Thank you.
Marc Anderson
_______________________________________________
Gnso-ssad mailing list -- gnso-ssad@icann.org
To unsubscribe send an email to gnso-ssad-leave@icann.org
--
Sent by a Verified
sender