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