[IRT.RegDataPolicy] Urgent requests RE: Input on Section 11.6 andSection 10 of the OneDoc.

[Sarah Wyld]

Hi all,

I thought we had finally reached agreement at our last meeting that we could compromise on 2 business days total (I’m not really concerned with how it’s divided between ack and response), it’s disappointing to be revisiting this conversation yet again. 

As we have expressed, the recommendation said “X business days” and I still think 2 business days is a reasonable turnaround time, especially since there are dedicated LEA contact points that Registrars must maintain and which LEA can use in emergencies. 

Thank you,

-- 
Sarah Wyld, CIPP/E

Policy & Privacy Manager
Pronouns: she/her

swyld at tucows.com 
+1.416 535 0123 Ext. 1392



From: Kapin, Laureen via IRT.RegDataPolicy
Sent: July 20, 2021 9:28 AM
To: Alex Deacon; LEWIS-EVANS, Christopher
Cc: irt.regdatapolicy at icann.org
Subject: [IRT.RegDataPolicy] Urgent requests RE: Input on Section 11.6 andSection 10 of the OneDoc.

I agree with Alex regarding his analysis of the requirements for urgent requests.  In thinking this through further, I observe that there is no requirement in Phase 1, that urgent requests must be acknowledged. Hence, consistent with our goal of streamlining the timeline for urgent requests, we propose a response "without undue delay, but no more than 24 hours from receipt."  



Kind regards,
Laureen Kapin

Acting Assistant Director
Division of Consumer Response and Operations
Bureau of Consumer Protection
Federal Trade Commission

From: IRT.RegDataPolicy <irt.regdatapolicy-bounces at icann.org> On Behalf Of Alex Deacon via IRT.RegDataPolicy
Sent: Monday, July 19, 2021 8:14 PM
To: Dennis Chang via IRT.RegDataPolicy <irt.regdatapolicy at icann.org>
Subject: [IRT.RegDataPolicy] Input on Section 11.6 and Section 10 of the OneDoc.

Team,

A few thoughts on the One Doc.   I've added these as comments in the OneDoc as well....

Section 11.6

The logic in the IRT Workbook Disclosure Logic tab is flawed as it mirrors the acknowledgement requirements for non-urgent requests (2 business days) even though the Policy clearly states that a separate timeline is required for Urgent requests.   

We seem to have conveniently forgotten that Urgent requests have been defined narrowly in Section 3.10.   (""Urgent Requests for Lawful  Disclosure” are limited to circumstances that pose an imminent threat to life, serious bodily injury, critical infrastructure, or child exploitation in cases where disclosure of the data is necessary in combatting or addressing this threat. Critical infrastructure means the physical and cyber systems that are vital in that their incapacity or destruction would have a debilitating impact on economic security or public safety.) 

A two business day maximum response time (as currently defined) would mean that a compliant response could take 3 (or more!) calendar days depending on weekends and holidays and the like. 

If we all agree that Urgent requests will only be used as defined in Section 3.10, then any maximum response time more than 24 hours renders useless the concept of an "Urgent Request".  This seems unacceptable (and dangerous!) to me.  

Section 10

In my OneDoc comment of June 14 - I suggested new first paragraph at the end of the section must be removed.   We must not add RDAP technical implementation details into a policy document - this is a terrible and unuseful idea.  

Here is my original comment as an FYI - "The reason we are debating the use of these words is because we seem to be assuming a particular "data element delivery" technology.   The policy, and this doc, should be technology agnostic.   In terms of this doc the terms "shown" and "displayed" are appropriate (it describes the policy).   Any detail about how a particular technology should be used (e.g. "must be blank" or "must be null" or "must not be included") is inappropriate for this doc and should be included in the RDAP profile doc.     Based on that the additional text added should be removed."

Regards, 
Alex



___________
Alex Deacon
Cole Valley Consulting
alex at colevalleyconsulting.com
+1.415.488.6009


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/irt.regdatapolicy/attachments/20210720/f717c55f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 66DD891F1CD140B8B082E775A55F2328[12673401728].png
Type: image/png
Size: 3031 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/irt.regdatapolicy/attachments/20210720/f717c55f/66DD891F1CD140B8B082E775A55F232812673401728.png>