Beth,

Thanks for your response.  I disagree with you on three points:
  1. Choosing a timeframe somewhere in the 24 hour to three business days range for a response to an Urgent request is not a viable solution.

    Irrespective of any claimed policy decisions that have been made earlier, a decision limited to this range of possibilities would fail a fundamental requirement that the solution be fit for purpose.  Not fit for purpose is a showstopper.

  2. I believe Dennis -- or perhaps someone else -- pointed out that the Phase I PDP WG explicitly left it to this group to fill in the details on how to address Urgent requests.  This is very much within the scope of this group to provide a constructive solution.

  3. The Small Team is focused on the launch of the Registration Data Request System (RDRS), the lightweight alternative to SSAD.  The only SLA associated with the RDRS  is the time it will take for the RDRS to post a requester's input on its site.  Response times for the registrars is explicitly out of scope for the RDRS.
We have an opportunity here and now to provide a solution that is fit for purpose, imposes essentially no additional costs on the registrars, takes advantage of ICANN's existing infrastructure, and, not incidentally, makes everyone look good.

Steve



On Tue, Jul 18, 2023 at 8:11 AM Elizabeth Bacon <bbacon@pir.org> wrote:

Hi Folks,

While I appreciate the effort to think outside the box, we have a fairly targeted question in front of us: Can we decide on edited language for the timeline to respond to urgent requests, or do we revert to the language that went out for public comment? 

 

I do not think it is within the remit of this IRT to attempt to craft an implement an entirely new process.  That would be a policy discussion and is frankly something that is already being discussed in the GNSO small team.

 

I think it behooves us to focus on identifying an acceptable timeline for the existing process recommended by the ePDP.

Thanks,
Beth

 

From: IRT.RegDataPolicy <irt.regdatapolicy-bounces@icann.org> on behalf of Steve Crocker via IRT.RegDataPolicy <irt.regdatapolicy@icann.org>
Date: Monday, July 17, 2023 at 10:51 PM
To: Rubens Kuhl <rubensk@nic.br>
Cc: Dennis Chang via IRT.RegDataPolicy <irt.regdatapolicy@icann.org>
Subject: [EXTERNAL] Re: [IRT.RegDataPolicy] Proposal for reconciling competing issues related to Urgent requests

CAUTION: This email came from outside your organization. Don’t trust emails, links, or attachments from senders that seem suspicious or you are not expecting.

No.  All the registrar has to do is answer the emergency phone call.  Whomever is capable of dealing with an emergency IT situation should also be clueful enough to do something sensible with an urgent request.  If he decides it's bogus, he can refuse to act.  If he decides it's legitimate, he can take the appropriate action.  And if he decides he can't decide, he can defer a decision until he gets some help.

 

The decision and responsibility still lie with the registrar, but the registrar will have the information passed along by ICANN.  In the worst case, the registrar will take two days to process a truly urgent request, which will likely have negative consequences for the registrar, but the pain won't come from the data protection authority.  But the likelihood of a worst case is small.  There's plenty of room for all parties to communicate and make a sensible decision.

 

Meanwhile, the contract language will protect the registrar from trolls just trying to make the registrar look bad.  And the gathering of data will make future versions of this discussion much less speculative.

 

Steve

 

On Mon, Jul 17, 2023 at 10:29 PM Rubens Kuhl via IRT.RegDataPolicy <irt.regdatapolicy@icann.org> wrote:



> Em 17 de jul. de 2023, à(s) 22:59, Steve Crocker <steve@shinkuro.com> escreveu:
>
> Rubens,
>
> The process would be for calls to be filtered through ICANN.  ICANN would maintain contact phone numbers and email addresses for each registrar.
>
> I’m presuming each registrar already has a point of contact for emergency situations.  For the smallest registrar, this is probably their personal cellphone.


What they currently have is a point of contact for IT emergencies. 2 calendar days require on-call lawyers to decide whether or not releasing that information would trigger privacy regulations fines on them, or not.

But if you add to that package ICANN also taking this liability, indemnifying registrars if a layman on-call makes a bad judgement, that might start to work.


Rubens



_______________________________________________
IRT.RegDataPolicy mailing list
IRT.RegDataPolicy@icann.org
https://mm.icann.org/mailman/listinfo/irt.regdatapolicy

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