Proposal for reconciling competing issues related to Urgent requests
Folks, Attached is a proposed way forward regarding Urgent requests. Thanks, Steve
Em 17 de jul. de 2023, à(s) 14:00, Steve Crocker via IRT.RegDataPolicy <irt.regdatapolicy@icann.org> escreveu:
Folks,
Attached is a proposed way forward regarding Urgent requests.
Which is partly an implementation of a different policy than the GNSO/Board approved one, partly the same issue with imposing 7x8 coverage of lawyer personnel for contracted parties. Rubens
If I heard correctly, the Phase I WG said they couldn’t reach agreement on the details and left it to the implementation team— that’s us — to work out the details. In my view, that’s exactly where this proposal fits. If this group feels this proposal cannot be adopted because it doesn’t fit within the confines of the policy decisions made earlier, we’re going to wind up without a workable solution. That will lead to reopening the policy process and returning to exactly where we are now. Better for us to propose a workable solution. This proposal implies some expense for ICANN but little or no additional expense to registrars. Steve Sent from my iPhone
On Jul 17, 2023, at 1:58 PM, Rubens Kuhl via IRT.RegDataPolicy <irt.regdatapolicy@icann.org> wrote:
Em 17 de jul. de 2023, à(s) 14:00, Steve Crocker via IRT.RegDataPolicy <irt.regdatapolicy@icann.org> escreveu:
Folks,
Attached is a proposed way forward regarding Urgent requests.
Which is partly an implementation of a different policy than the GNSO/Board approved one, partly the same issue with imposing 7x8 coverage of lawyer personnel for contracted parties.
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.
Em 17 de jul. de 2023, à(s) 15:09, Steve Crocker <steve@shinkuro.com> escreveu:
If I heard correctly, the Phase I WG said they couldn’t reach agreement on the details and left it to the implementation team— that’s us — to work out the details. In my view, that’s exactly where this proposal fits.
If this group feels this proposal cannot be adopted because it doesn’t fit within the confines of the policy decisions made earlier, we’re going to wind up without a workable solution. That will lead to reopening the policy process and returning to exactly where we are now. Better for us to propose a workable solution.
With the difference that the policy process is only limited by the charter, while the implementation is limited by the policy outcome. So I wouldn’t assume that the policy process couldn’t achieve what the implementation team did not. Also to note is that only the urgent request aspect of the policy would need a focused policy process. Everything else in the RegData PDP could move forward. So, instead of 2 business days, those requests would get up to 30 days for the time being.
This proposal implies some expense for ICANN but little or no additional expense to registrars.
Last I heard lawyers are not free on any reasonable jurisdiction, so there is additional - and significant - expense to registrars. Rubens
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. Upon receiving the call from ICANN, the registrar decides what to do. There is no obligation to keep attorneys on duty if they don’t want to. All that’s required is to field the call and act rationally. The definition of “act rationally” is deliberately not included. ICANN would maintain a record of each incident, including the identity of the requester. ICANN would have the authority to filter out requests that do not appear to require urgent attention. ICANN would presumably treat requests from known trusted requesters more favorably than requests from unknown requesters. Steve On Mon, Jul 17, 2023 at 9:44 PM Rubens Kuhl via IRT.RegDataPolicy < irt.regdatapolicy@icann.org> wrote:
Em 17 de jul. de 2023, à(s) 15:09, Steve Crocker <steve@shinkuro.com> escreveu:
If I heard correctly, the Phase I WG said they couldn’t reach agreement on the details and left it to the implementation team— that’s us — to work out the details. In my view, that’s exactly where this proposal fits.
If this group feels this proposal cannot be adopted because it doesn’t fit within the confines of the policy decisions made earlier, we’re going to wind up without a workable solution. That will lead to reopening the policy process and returning to exactly where we are now. Better for us to propose a workable solution.
With the difference that the policy process is only limited by the charter, while the implementation is limited by the policy outcome. So I wouldn’t assume that the policy process couldn’t achieve what the implementation team did not.
Also to note is that only the urgent request aspect of the policy would need a focused policy process. Everything else in the RegData PDP could move forward. So, instead of 2 business days, those requests would get up to 30 days for the time being.
This proposal implies some expense for ICANN but little or no additional
expense to registrars.
Last I heard lawyers are not free on any reasonable jurisdiction, so there is additional - and significant - expense to registrars.
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.
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
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.
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<mailto:irt.regdatapolicy@icann.org>> wrote:
Em 17 de jul. de 2023, à(s) 22:59, Steve Crocker <steve@shinkuro.com<mailto: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<mailto:IRT.RegDataPolicy@icann.org> https://mm.icann.org/mailman/listinfo/irt.regdatapolicy<https://protect-us.mimecast.com/s/xGavC2kQyWF8YAZFnsFg0?domain=mm.icann.org> _______________________________________________ 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<https://protect-us.mimecast.com/s/gdtGC31Pzws2kV9hqvOLo?domain=icann.org>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://protect-us.mimecast.com/s/v3B3C4xPALSlVG9TB-nwH?domain=icann.org>). 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.
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 <https://protect-us.mimecast.com/s/xGavC2kQyWF8YAZFnsFg0?domain=mm.icann.org>
_______________________________________________ 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 <https://protect-us.mimecast.com/s/gdtGC31Pzws2kV9hqvOLo?domain=icann.org>) and the website Terms of Service (https://www.icann.org/privacy/tos <https://protect-us.mimecast.com/s/v3B3C4xPALSlVG9TB-nwH?domain=icann.org>). 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.
Em 18 de jul. de 2023, à(s) 09:11, Elizabeth Bacon <bbacon@pir.org> escreveu:
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?
The options I see are 1) Revert to the language that went out for public comment 2) Having no language at all on urgent requests and send this specific issue to the policy process Rubens
Of these two choices, (1) is, IMO, a non-starter. (2), sending it back to the policy process, is a poor but available path. If this is the path the group chooses, I recommend including a cover note that conveys this proposal as a possible solution but the group viewed it as outside its remit to consider. Steve On Tue, Jul 18, 2023 at 10:55 AM Rubens Kuhl via IRT.RegDataPolicy < irt.regdatapolicy@icann.org> wrote:
Em 18 de jul. de 2023, à(s) 09:11, Elizabeth Bacon <bbacon@pir.org> escreveu:
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?
The options I see are 1) Revert to the language that went out for public comment 2) Having no language at all on urgent requests and send this specific issue to the policy process
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.
Em 18 de jul. de 2023, à(s) 11:59, Steve Crocker <steve@shinkuro.com> escreveu:
Of these two choices, (1) is, IMO, a non-starter. (2), sending it back to the policy process, is a poor but available path. If this is the path the group chooses, I recommend including a cover note that conveys this proposal as a possible solution but the group viewed it as outside its remit to consider.
Why a text approved by this IRT would be a non-starter puzzles me. It’s actually the only text that got consensus at any point in this IRT existence, while all the other suggestions from Org and from IRT members did not. Which is why not following any of the two choices I mentioned would be an immediate trigger for an RfR. We either respect the consensus and compromise reached before, or we throw it away completely and start over. Replacing by anything lacking consensus is not an option. Rubens
Wouldn’t that view render the public comment process and subsequent review, analysis and response from the ICANN team a nullity? In my view, we have more options than the two identified below and it’s worth exploring them. Kind regards, Laureen Kapin Assistant Director for International Consumer Protection Office of International Affairs Federal Trade Commission lkapin@ftc.gov From: IRT.RegDataPolicy <irt.regdatapolicy-bounces@icann.org> On Behalf Of Rubens Kuhl via IRT.RegDataPolicy Sent: Tuesday, July 18, 2023 11:20 AM To: Dennis Chang via IRT.RegDataPolicy <irt.regdatapolicy@icann.org> Subject: Re: [IRT.RegDataPolicy] [EXTERNAL] Proposal for reconciling competing issues related to Urgent requests Em 18 de jul. de 2023, à(s) 11:59, Steve Crocker <steve@shinkuro.com> escreveu: Of these two choices, (1) is, IMO, a non-starter. (2), sending it back to the policy process, is a poor but available path. If this is the path the group chooses, I recommend including a cover note that conveys this proposal as a possible solution but the group viewed it as outside its remit to consider. Why a text approved by this IRT would be a non-starter puzzles me. It’s actually the only text that got consensus at any point in this IRT existence, while all the other suggestions from Org and from IRT members did not. Which is why not following any of the two choices I mentioned would be an immediate trigger for an RfR. We either respect the consensus and compromise reached before, or we throw it away completely and start over. Replacing by anything lacking consensus is not an option. Rubens
Em 18 de jul. de 2023, à(s) 12:25, Kapin, Laureen <LKAPIN@ftc.gov> escreveu:
Wouldn’t that view render the public comment process and subsequent review, analysis and response from the ICANN team a nullity? In my view, we have more options than the two identified below and it’s worth exploring them.
The many e-mails and call hours discussing this proves that comments are not being nulled; they are being throughly considered, but in the multi stakeholder model someone not liking an outcome is only that. As our sister organization says, "Rough consensus is achieved when all issues are addressed, but not necessarily accommodated”. Top-down decision making belongs in other governance structures, not in a multi stakeholder setting. Rubens
We’ll have to agree to disagree Rubens. We will continue the discussion later this week but please note – 1) several SG's disagree with the current view (not just "someone"); 2) the public comments expressing concerns with the proposed approach were sufficiently persuasive to convince ICANN Org’s review team to reconsider given the importance of the topic and magnitude of concerns conveyed; 3) the stakeholder's who are most likely to make urgent requests continue to have grave concerns with the current approach; and 4) the optics of recommending a response to urgent requests that is not fit for purpose are not good, especially given the current focus on the topic of DNS Abuse Kind regards, Laureen Kapin Assistant Director for International Consumer Protection Office of International Affairs Federal Trade Commission lkapin@ftc.gov -----Original Message----- From: IRT.RegDataPolicy <irt.regdatapolicy-bounces@icann.org> On Behalf Of Rubens Kuhl via IRT.RegDataPolicy Sent: Tuesday, July 18, 2023 11:31 AM To: Dennis Chang via IRT.RegDataPolicy <irt.regdatapolicy@icann.org> Subject: Re: [IRT.RegDataPolicy] [EXTERNAL] Proposal for reconciling competing issues related to Urgent requests
Em 18 de jul. de 2023, à(s) 12:25, Kapin, Laureen <LKAPIN@ftc.gov> escreveu:
Wouldn’t that view render the public comment process and subsequent review, analysis and response from the ICANN team a nullity? In my view, we have more options than the two identified below and it’s worth exploring them.
The many e-mails and call hours discussing this proves that comments are not being nulled; they are being throughly considered, but in the multi stakeholder model someone not liking an outcome is only that. As our sister organization says, "Rough consensus is achieved when all issues are addressed, but not necessarily accommodated”. Top-down decision making belongs in other governance structures, not in a multi stakeholder setting. 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.
Em 18 de jul. de 2023, à(s) 12:39, Kapin, Laureen <LKAPIN@ftc.gov> escreveu:
We’ll have to agree to disagree Rubens. We will continue the discussion later this week but please note –
1) several SG's disagree with the current view (not just "someone");
Including a number of SGs with members in this IRT, the same IRT that approved this exact text in the first place…
2) the public comments expressing concerns with the proposed approach were sufficiently persuasive to convince ICANN Org’s review team to reconsider given the importance of the topic and magnitude of concerns conveyed;
Whether ICANN Org is looking at the subject or at “optics” is something to be determined. But Org will have to choose between throwing away the PDP manual and please some actors. And I will be sure to uphold the PDP manual and the bylaws.
3) the stakeholder's who are most likely to make urgent requests continue to have grave concerns with the current approach; and 4) the optics of recommending a response to urgent requests that is not fit for purpose are not good, especially given the current focus on the topic of DNS Abuse
The main feature of the proposed language is the phrase “without undue delay”. That’s where it clearly states the treatment urgent requests require. All the other attempts of clarifying that only created hazardous situations that only fitted the convenience of some jurisdictions (like no longer than 3 calendar days). Since you mentioned, DNS Abuse amendments are a good example of what can be accomplished without unrealistic expectations (like on-call lawyers), which is why they will be in force long before this policy. Rubens
I knew you were wedded to the last word 😉. Kind regards, Laureen Kapin Assistant Director for International Consumer Protection Office of International Affairs Federal Trade Commission lkapin@ftc.gov From: IRT.RegDataPolicy <irt.regdatapolicy-bounces@icann.org> On Behalf Of Rubens Kuhl via IRT.RegDataPolicy Sent: Tuesday, July 18, 2023 11:58 AM To: Dennis Chang via IRT.RegDataPolicy <irt.regdatapolicy@icann.org> Subject: Re: [IRT.RegDataPolicy] [EXTERNAL] Proposal for reconciling competing issues related to Urgent requests Em 18 de jul. de 2023, à(s) 12:39, Kapin, Laureen <LKAPIN@ftc.gov> escreveu: We’ll have to agree to disagree Rubens. We will continue the discussion later this week but please note – 1) several SG's disagree with the current view (not just "someone"); Including a number of SGs with members in this IRT, the same IRT that approved this exact text in the first place… 2) the public comments expressing concerns with the proposed approach were sufficiently persuasive to convince ICANN Org’s review team to reconsider given the importance of the topic and magnitude of concerns conveyed; Whether ICANN Org is looking at the subject or at “optics” is something to be determined. But Org will have to choose between throwing away the PDP manual and please some actors. And I will be sure to uphold the PDP manual and the bylaws. 3) the stakeholder's who are most likely to make urgent requests continue to have grave concerns with the current approach; and 4) the optics of recommending a response to urgent requests that is not fit for purpose are not good, especially given the current focus on the topic of DNS Abuse The main feature of the proposed language is the phrase “without undue delay”. That’s where it clearly states the treatment urgent requests require. All the other attempts of clarifying that only created hazardous situations that only fitted the convenience of some jurisdictions (like no longer than 3 calendar days). Since you mentioned, DNS Abuse amendments are a good example of what can be accomplished without unrealistic expectations (like on-call lawyers), which is why they will be in force long before this policy. Rubens
I support the proposition of June 7 *For Urgent Requests for Lawful Disclosure, Registrar and Registry Operator MUST acknowledge and respond without undue delay, but no more than 24 hours two (2) business days from receipt.* This for me is useful for crises like DNS Abuse and can be comprehensive for large time zone matters. regards *Betty FAUSTA -* Mobile : +590 (0) 690 4973 09 (Guadeloupe) Fax : +33 (0) 972 2278 55 Contacts : Skype BETFAU | Pin BBM : 76521821 | Whats'app &Viber Le mar. 18 juill. 2023, à 12 h 00, Kapin, Laureen via IRT.RegDataPolicy < irt.regdatapolicy@icann.org> a écrit :
I knew you were wedded to the last word 😉.
Kind regards,
Laureen Kapin
Assistant Director for International Consumer Protection
Office of International Affairs
Federal Trade Commission
lkapin@ftc.gov
*From:* IRT.RegDataPolicy <irt.regdatapolicy-bounces@icann.org> *On Behalf Of *Rubens Kuhl via IRT.RegDataPolicy *Sent:* Tuesday, July 18, 2023 11:58 AM *To:* Dennis Chang via IRT.RegDataPolicy <irt.regdatapolicy@icann.org> *Subject:* Re: [IRT.RegDataPolicy] [EXTERNAL] Proposal for reconciling competing issues related to Urgent requests
Em 18 de jul. de 2023, à(s) 12:39, Kapin, Laureen <LKAPIN@ftc.gov> escreveu:
We’ll have to agree to disagree Rubens. We will continue the discussion later this week but please note –
1) several SG's disagree with the current view (not just "someone");
Including a number of SGs with members in this IRT, the same IRT that approved this exact text in the first place…
2) the public comments expressing concerns with the proposed approach were sufficiently persuasive to convince ICANN Org’s review team to reconsider given the importance of the topic and magnitude of concerns conveyed;
Whether ICANN Org is looking at the subject or at “optics” is something to be determined. But Org will have to choose between throwing away the PDP manual and please some actors. And I will be sure to uphold the PDP manual and the bylaws.
3) the stakeholder's who are *most* likely to make urgent requests continue to have grave concerns with the current approach; and
4) the optics of recommending a response to urgent requests that is not fit for purpose are not good, especially given the current focus on the topic of DNS Abuse
The main feature of the proposed language is the phrase “without undue delay”. That’s where it clearly states the treatment urgent requests require. All the other attempts of clarifying that only created hazardous situations that only fitted the convenience of some jurisdictions (like no longer than 3 calendar days).
Since you mentioned, DNS Abuse amendments are a good example of what can be accomplished without unrealistic expectations (like on-call lawyers), which is why they will be in force long before this policy.
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.
Em 19 de jul. de 2023, à(s) 13:32, BF <bettyfausta@gmail.com> escreveu:
I support the proposition of June 7 For Urgent Requests for Lawful Disclosure, Registrar and Registry Operator MUST acknowledge and respond without undue delay, but no more than 24 hours two (2) business days from receipt. This for me is useful for crises like DNS Abuse and can be comprehensive for large time zone matters.
This policy is about urgent disclosure requests, not DNS Abuse. For DNS Abuse there are contractual provisions other than Reg Data Policy. Conflating the issues is not helpful. Rubens
Thanks for this exchange. Urgent requests (which only apply to circumstances that pose an imminent threat to life, of serious bodily injury, to critical infrastructure, or of child exploitation) may or may not involve DNS Abuse (perhaps more likely re: threats to infrastructure) but certainly involve very grave situations. That’s the rationale for the 24 hour response timeframe. Looking forward to our discussion later today. Kind regards, Laureen Kapin Assistant Director for International Consumer Protection Office of International Affairs Federal Trade Commission lkapin@ftc.gov From: IRT.RegDataPolicy <irt.regdatapolicy-bounces@icann.org> On Behalf Of Rubens Kuhl via IRT.RegDataPolicy Sent: Wednesday, July 19, 2023 12:55 PM To: Dennis Chang via IRT.RegDataPolicy <irt.regdatapolicy@icann.org> Subject: Re: [IRT.RegDataPolicy] [EXTERNAL] Proposal for reconciling competing issues related to Urgent requests Em 19 de jul. de 2023, à(s) 13:32, BF <bettyfausta@gmail.com> escreveu: I support the proposition of June 7 For Urgent Requests for Lawful Disclosure, Registrar and Registry Operator MUST acknowledge and respond without undue delay, but no more than 24 hours two (2) business days from receipt. This for me is useful for crises like DNS Abuse and can be comprehensive for large time zone matters. This policy is about urgent disclosure requests, not DNS Abuse. For DNS Abuse there are contractual provisions other than Reg Data Policy. Conflating the issues is not helpful. Rubens
Hello all, We should keep DNS Abuse separate from this Urgent disclosure request conversation. DNS Abuse, which is defined as phishing, pharming, malware, botnets, and spam when delivering the other four types of Abuse, has (in comparison to Urgent disclosure requests) a different process for escalation to the Registrar's Abuse contact (often not the same person as the one evaluating the disclosure request), and a completely different review and decision-making process. Identifying malware or phishing on a website is a completely different skillset than conducting a legal balancing test of rights. The differences in these two problems and processes also mean that the time it takes to address them is different. Although 24 hours has been accepted for responding to abuse reports it is not what the Phase 1 EPDP team agreed on for answering disclosure requests and it is not a reasonable timeframe for registrars to be held to meet. It cannot be what this IRT includes in the Policy. -- Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/they swyld@tucows.com From: Kapin, Laureen via IRT.RegDataPolicy Sent: July 19, 2023 1:14 PM To: Rubens Kuhl; Dennis Chang via IRT.RegDataPolicy Subject: Re: [IRT.RegDataPolicy] [EXTERNAL] Proposal for reconcilingcompeting issues related to Urgent requests Thanks for this exchange. Urgent requests (which only apply to circumstances that pose an imminent threat to life, of serious bodily injury, to critical infrastructure, or of child exploitation) may or may not involve DNS Abuse (perhaps more likely re: threats to infrastructure) but certainly involve very grave situations. That’s the rationale for the 24 hour response timeframe. Looking forward to our discussion later today. Kind regards, Laureen Kapin Assistant Director for International Consumer Protection Office of International Affairs Federal Trade Commission lkapin@ftc.gov From: IRT.RegDataPolicy <irt.regdatapolicy-bounces@icann.org> On Behalf Of Rubens Kuhl via IRT.RegDataPolicy Sent: Wednesday, July 19, 2023 12:55 PM To: Dennis Chang via IRT.RegDataPolicy <irt.regdatapolicy@icann.org> Subject: Re: [IRT.RegDataPolicy] [EXTERNAL] Proposal for reconciling competing issues related to Urgent requests Em 19 de jul. de 2023, à(s) 13:32, BF <bettyfausta@gmail.com> escreveu: I support the proposition of June 7 For Urgent Requests for Lawful Disclosure, Registrar and Registry Operator MUST acknowledge and respond without undue delay, but no more than 24 hours two (2) business days from receipt. This for me is useful for crises like DNS Abuse and can be comprehensive for large time zone matters. This policy is about urgent disclosure requests, not DNS Abuse. For DNS Abuse there are contractual provisions other than Reg Data Policy. Conflating the issues is not helpful. Rubens
It's a non-starter because it's not fit for purpose. None of us, at any level in this organization, should support a proposal which is broken on its face. As I said in my initial entry into this dialog, if a matter is Urgent, with a definition stated in terms of imminent threat to life or limb, the relevant time frame is seconds or minutes, not days. Steve On Tue, Jul 18, 2023 at 11:20 AM Rubens Kuhl via IRT.RegDataPolicy < irt.regdatapolicy@icann.org> wrote:
Em 18 de jul. de 2023, à(s) 11:59, Steve Crocker <steve@shinkuro.com> escreveu:
Of these two choices, (1) is, IMO, a non-starter. (2), sending it back to the policy process, is a poor but available path. If this is the path the group chooses, I recommend including a cover note that conveys this proposal as a possible solution but the group viewed it as outside its remit to consider.
Why a text approved by this IRT would be a non-starter puzzles me. It’s actually the only text that got consensus at any point in this IRT existence, while all the other suggestions from Org and from IRT members did not.
Which is why not following any of the two choices I mentioned would be an immediate trigger for an RfR. We either respect the consensus and compromise reached before, or we throw it away completely and start over. Replacing by anything lacking consensus is not an option.
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.
participants (6)
-
BF -
Elizabeth Bacon -
Kapin, Laureen -
Rubens Kuhl -
Sarah Wyld -
Steve Crocker