Review RegData complete draft Re: Good News. Urgent Request. IRT supported solution found!
Dear IRT, Attached is a completed draft of the Registration Data Policy including the last two outstanding sections. Section 4.0: Policy Effective Date reflecting the 6+12 plan for the 18-month implementation timeline. Section 10.6: Urgent Request reflecting the solution supported at the IRT meeting last week. (see email below) I believe we now have a good policy that is aligned with all 34 recommendations we will work together to implement. EPDP Phase 1 recommendations (29) May 2019 EPDP Phase 2 Priority 2 Recommendations (4) June 2021 Supplemental Recommendation (1) March 2022 As we discussed at our last IRT meeting, we don’t plan on more IRT meetings before we publish our policy in August 2023. We’ll notify you of the publication date after we have coordinated with our publication team. We may have more IRT meetings after we publish to coordinate and collaborate our implementation, but that decision will come later. For now, we will focus on getting this policy published. If you have questions or comments, I request they be submitted in separate emails with Subject line defining the topic. It will help us to collect the information as we address them together. Thank you all once again and I hope you all support the attached policy language for publication and implementation. Gratefully your, Dennis Chang From: "IRT.RegDataPolicy" <irt.regdatapolicy-bounces@icann.org> on behalf of "Dennis Chang via IRT.RegDataPolicy" <irt.regdatapolicy@icann.org> Reply-To: Dennis Chang <dennis.chang@icann.org> Date: Friday, July 21, 2023 at 8:40 AM To: "irt.regdatapolicy@icann.org" <irt.regdatapolicy@icann.org> Subject: Re: [IRT.RegDataPolicy] RegData IRT Good News. Urgent Request requirement. IRT supported solution found! Dear IRT, If you haven’t heard already, we did it! We found a solution to Urgent Request supported by IRT at our 90 minutes focused working session this week. Thank you so much for not giving up and working as a team to find this solution. It was impressive to see people still listening to one another, appreciating the different views, and truly collaborating to build on ideas to find the compromised solution. A great demonstration of One Team against the problem. What was that solution? * 24 hours. Respond in 24 hours with the info or an explanation for more time needed. * 2 Business Days. No more than 2 Business Days to Respond. How did this happen? First, thanks to Roger and RrSG for the planting the seed with using both 24 hours and 2 business days in the solution. Instead of outright rejecting it, Laureen and others suggested that we build on it. Thomas came in with a key ingredient – the explanation. Initially, we discussed all the options but created this new one listening to the “interest” behind the positions. Business Days was important because of the business realities in various regions around the world. While Calendar Days sets global time consistency, the team agreed that cultural sensitivity to regions was more important. The dread of “silence” with undetermined timeline using “Business Days” was solved with the promise of a response in 24 hours with an explanation. Thanks to Gabriel expressing the “dread” so eloquently. Overall, it was an exciting finale overcoming the toughest challenge for us. As promised, we’ll draft the policy language using the IRT supported requirements and comeback to you, but I wanted to send you this quick note to express my sincere gratitude for wonderfully responding. I thank those guests that joined to support us too. I noted Ashley, RrSG Chair and Becky, ICANN Board and others supporting us behind the scenes. Please convey our sincere appreciation to your team back home too. THANK YOU! Dennis S. Chang GDD Programs Director Phone: +1 213 293 7889 Sykpe: dennisSchang www.icann.org<http://www.icann.org> One World – One Internet
Dear Dennis and colleagues, We appreciate the effort the IRT members and staff have taken to get us to this point. I was very grateful for thoughtfulness and flexibility demonstrated during the call. Nevertheless, the Public Safety Working Group colleagues on the 7/19/23 call (myself, Chris, and Gabe) don’t think the current draft has accurately captured the agreement reached during our discussion because it identifies two separate timelines for extensions of time to respond to urgent requests. I understood our discussion as creating a unified timeline for most requests (“without undue delay, generally within 24 hours”) and then a single opportunity to for an up-to-2 business day extension. The circulated version creates two opportunities and timelines for an extension and creates the potential for a longer total timeline to respond (now 3 business days). I reviewed the recording (most relevant part starts at minute 50) and believe it supports my understanding, particularly Thomas’s distillation of the key components of our agreement toward the end of the discussion. I note that part of the misunderstanding seems to have arisen because the current version, for the first time, separates out the timeline for urgent requests into three separate subsections. The public comment version for urgent requests was set forth in its entirety in10.6. Org’s changes to this provision after the public comment period were also set forth in their entirety in 10.6. These were never broken out or considered as stand-alone components of the urgent request timeline. They were only broken out and separated in the version circulated yesterday. Our 7/19 discussion was focused on the entirety of the timeline to respond and setting a ceiling or limit on the response time. The PSWG participants did not view the discussion as just focusing on a partial ceiling that could be extended not one but two times for a total of three business days. Regarding a ceiling for response times, such a result would put us in a worse position than what Dennis had recently proposed (3 calendar days). For clarity, I think 10.6. and 10.6.1 accurately sets forth our discussion: 10.6. For Urgent Requests for Lawful Disclosure, Registrar and Registry Operator MUST respond, as defined in Section 10.7, without undue delay, generally within 24 hours of receipt. 10.6.1. If Registrar or Registry Operator cannot respond to an Urgent Request for Lawful Disclosure within 24 hours, it MUST notify the requestor within 24 hours of receipt of an Urgent Request for Lawful Disclosure of the need for an extension to respond. Registrar or Registry Operator’s extension notification to the requestor MUST include (a) confirmation that it has reviewed and considered the Urgent Request for Lawful Disclosure on its merits and determined additional time to respond is needed, (b) rationale for why additional time is needed, and (c) the time frame it will respond, as required by Section 10.7, which cannot exceed two (2) business days from the time of the initial receipt of the request. However, I don’t recall that we discussed an additional amount of time beyond the two-business day total response time. Indeed, I thought the whole goal of our discussion was to create a single ceiling beyond the “without undue delay,” generally w/in 24 hours, which we ultimately agreed would expire at 2 business days from receipt. So, I was surprised to see 10.6.2: 10.6.2. In addition to the extension provided for in Section 10.6.1, if responding to an Urgent Request for Lawful Disclosure is complex, or a large number of requests are received by Registrar or Registry Operator, it MAY extend the time for response up to an additional one (1) business day provided it notifies the requestor within (2) business days from the time of the initial receipt of the request of the updated time frame to respond explaining the need for an additional extension of time. The reason that I’m concerned is that we’re now back to a scenario where urgent requests could take three business days to respond to which is what the GAC objected to in its public comment as inconsistent with the nature of an “urgent” request. I think this needs further discussion because I don’t think the current draft accurately reflects what we discussed on 7/19. My suggestion would be to either: 1. Delete 10.6.2 or 2. Add the concepts of “complex” and “large number” to 10.6.1 as part of the rationale that may be shared to justify an extension of time to respond to an urgent request. I suggest that we need an additional call unless this can be resolved via email. 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 Dennis Chang via IRT.RegDataPolicy Sent: Monday, July 24, 2023 5:24 PM To: irt.regdatapolicy@icann.org Subject: [IRT.RegDataPolicy] Review RegData complete draft Re: Good News. Urgent Request. IRT supported solution found! Dear IRT, Attached is a completed draft of the Registration Data Policy including the last two outstanding sections. Section 4.0: Policy Effective Date reflecting the 6+12 plan for the 18-month implementation timeline. Section 10.6: Urgent Request reflecting the solution supported at the IRT meeting last week. (see email below) I believe we now have a good policy that is aligned with all 34 recommendations we will work together to implement. EPDP Phase 1 recommendations (29) May 2019 EPDP Phase 2 Priority 2 Recommendations (4) June 2021 Supplemental Recommendation (1) March 2022 As we discussed at our last IRT meeting, we don’t plan on more IRT meetings before we publish our policy in August 2023. We’ll notify you of the publication date after we have coordinated with our publication team. We may have more IRT meetings after we publish to coordinate and collaborate our implementation, but that decision will come later. For now, we will focus on getting this policy published. If you have questions or comments, I request they be submitted in separate emails with Subject line defining the topic. It will help us to collect the information as we address them together. Thank you all once again and I hope you all support the attached policy language for publication and implementation. Gratefully your, Dennis Chang From: "IRT.RegDataPolicy" <irt.regdatapolicy-bounces@icann.org> on behalf of "Dennis Chang via IRT.RegDataPolicy" <irt.regdatapolicy@icann.org> Reply-To: Dennis Chang <dennis.chang@icann.org> Date: Friday, July 21, 2023 at 8:40 AM To: "irt.regdatapolicy@icann.org" <irt.regdatapolicy@icann.org> Subject: Re: [IRT.RegDataPolicy] RegData IRT Good News. Urgent Request requirement. IRT supported solution found! Dear IRT, If you haven’t heard already, we did it! We found a solution to Urgent Request supported by IRT at our 90 minutes focused working session this week. Thank you so much for not giving up and working as a team to find this solution. It was impressive to see people still listening to one another, appreciating the different views, and truly collaborating to build on ideas to find the compromised solution. A great demonstration of One Team against the problem. What was that solution? * 24 hours. Respond in 24 hours with the info or an explanation for more time needed. * 2 Business Days. No more than 2 Business Days to Respond. How did this happen? First, thanks to Roger and RrSG for the planting the seed with using both 24 hours and 2 business days in the solution. Instead of outright rejecting it, Laureen and others suggested that we build on it. Thomas came in with a key ingredient – the explanation. Initially, we discussed all the options but created this new one listening to the “interest” behind the positions. Business Days was important because of the business realities in various regions around the world. While Calendar Days sets global time consistency, the team agreed that cultural sensitivity to regions was more important. The dread of “silence” with undetermined timeline using “Business Days” was solved with the promise of a response in 24 hours with an explanation. Thanks to Gabriel expressing the “dread” so eloquently. Overall, it was an exciting finale overcoming the toughest challenge for us. As promised, we’ll draft the policy language using the IRT supported requirements and comeback to you, but I wanted to send you this quick note to express my sincere gratitude for wonderfully responding. I thank those guests that joined to support us too. I noted Ashley, RrSG Chair and Becky, ICANN Board and others supporting us behind the scenes. Please convey our sincere appreciation to your team back home too. THANK YOU! Dennis S. Chang GDD Programs Director Phone: +1 213 293 7889 Sykpe: dennisSchang www.icann.org<http://www.icann.org> One World – One Internet
Hi Laureen, Although I did not attend the last IRT meeting, I have been in close consultation with my registrar colleagues. It needs to be made clear that this was a REAL compromise for registrars as it allows taking additional time to respond if necessary. Conducting the balancing test is not as simple as reviewing an abuse complaint (as many have repeatedly explained), and the penalties of improper disclosure are significant. We thus need the flexibility if certain situations require more than 24 hours. Getting rid of the previously agreed upon text of one business day puts us back in a situation where there is no compromise and the registrars will not be able to accept what was agreed to last week. On behalf of the RrSG, I would formally like to raise the concern that it appears that the IRT is being used to develop policy rather than implement recommendations. Others have expressed this concern, and the registrars support efforts to ensure that the final policy aligns with the recommendations. Regards, Owen
On Jul 25, 2023, at 11:34, Kapin, Laureen via IRT.RegDataPolicy <irt.regdatapolicy@icann.org> wrote:
CAUTION: This email originated from outside the organization. Do not click links unless you can confirm the sender and know the content is safe. Dear Dennis and colleagues,
We appreciate the effort the IRT members and staff have taken to get us to this point. I was very grateful for thoughtfulness and flexibility demonstrated during the call. Nevertheless, the Public Safety Working Group colleagues on the 7/19/23 call (myself, Chris, and Gabe) don’t think the current draft has accurately captured the agreement reached during our discussion because it identifies two separate timelines for extensions of time to respond to urgent requests. I understood our discussion as creating a unified timeline for most requests (“without undue delay, generally within 24 hours”) and then a single opportunity to for an up-to-2 business day extension. The circulated version creates two opportunities and timelines for an extension and creates the potential for a longer total timeline to respond (now 3 business days).
I reviewed the recording (most relevant part starts at minute 50) and believe it supports my understanding, particularly Thomas’s distillation of the key components of our agreement toward the end of the discussion.
I note that part of the misunderstanding seems to have arisen because the current version, for the first time, separates out the timeline for urgent requests into three separate subsections. The public comment version for urgent requests was set forth in its entirety in10.6. Org’s changes to this provision after the public comment period were also set forth in their entirety in 10.6. These were never broken out or considered as stand-alone components of the urgent request timeline. They were only broken out and separated in the version circulated yesterday.
Our 7/19 discussion was focused on the entirety of the timeline to respond and setting a ceiling or limit on the response time. The PSWG participants did not view the discussion as just focusing on a partial ceiling that could be extended not one but two times for a total of three business days. Regarding a ceiling for response times, such a result would put us in a worse position than what Dennis had recently proposed (3 calendar days).
For clarity, I think 10.6. and 10.6.1 accurately sets forth our discussion:
10.6. For Urgent Requests for Lawful Disclosure, Registrar and Registry Operator MUST respond, as defined in Section 10.7, without undue delay, generally within 24 hours of receipt.
10.6.1. If Registrar or Registry Operator cannot respond to an Urgent Request for Lawful Disclosure within 24 hours, it MUST notify the requestor within 24 hours of receipt of an Urgent Request for Lawful Disclosure of the need for an extension to respond. Registrar or Registry Operator’s extension notification to the requestor MUST include (a) confirmation that it has reviewed and considered the Urgent Request for Lawful Disclosure on its merits and determined additional time to respond is needed, (b) rationale for why additional time is needed, and (c) the time frame it will respond, as required by Section 10.7, which cannot exceed two (2) business days from the time of the initial receipt of the request.
However, I don’t recall that we discussed an additional amount of time beyond the two-business day total response time. Indeed, I thought the whole goal of our discussion was to create a single ceiling beyond the “without undue delay,” generally w/in 24 hours, which we ultimately agreed would expire at 2 business days from receipt. So, I was surprised to see 10.6.2:
10.6.2. In addition to the extension provided for in Section 10.6.1, if responding to an Urgent Request for Lawful Disclosure is complex, or a large number of requests are received by Registrar or Registry Operator, it MAY extend the time for response up to an additional one (1) business day provided it notifies the requestor within (2) business days from the time of the initial receipt of the request of the updated time frame to respond explaining the need for an additional extension of time.
The reason that I’m concerned is that we’re now back to a scenario where urgent requests could take three business days to respond to which is what the GAC objected to in its public comment as inconsistent with the nature of an “urgent” request.
I think this needs further discussion because I don’t think the current draft accurately reflects what we discussed on 7/19. My suggestion would be to either:
Delete 10.6.2 or Add the concepts of “complex” and “large number” to 10.6.1 as part of the rationale that may be shared to justify an extension of time to respond to an urgent request.
I suggest that we need an additional call unless this can be resolved via email.
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 Dennis Chang via IRT.RegDataPolicy Sent: Monday, July 24, 2023 5:24 PM To: irt.regdatapolicy@icann.org Subject: [IRT.RegDataPolicy] Review RegData complete draft Re: Good News. Urgent Request. IRT supported solution found!
Dear IRT,
Attached is a completed draft of the Registration Data Policy including the last two outstanding sections. Section 4.0: Policy Effective Date reflecting the 6+12 plan for the 18-month implementation timeline. Section 10.6: Urgent Request reflecting the solution supported at the IRT meeting last week. (see email below)
I believe we now have a good policy that is aligned with all 34 recommendations we will work together to implement. EPDP Phase 1 recommendations (29) May 2019 EPDP Phase 2 Priority 2 Recommendations (4) June 2021 Supplemental Recommendation (1) March 2022
As we discussed at our last IRT meeting, we don’t plan on more IRT meetings before we publish our policy in August 2023. We’ll notify you of the publication date after we have coordinated with our publication team. We may have more IRT meetings after we publish to coordinate and collaborate our implementation, but that decision will come later. For now, we will focus on getting this policy published.
If you have questions or comments, I request they be submitted in separate emails with Subject line defining the topic. It will help us to collect the information as we address them together.
Thank you all once again and I hope you all support the attached policy language for publication and implementation.
Gratefully your, Dennis Chang
From: "IRT.RegDataPolicy" <irt.regdatapolicy-bounces@icann.org> on behalf of "Dennis Chang via IRT.RegDataPolicy" <irt.regdatapolicy@icann.org> Reply-To: Dennis Chang <dennis.chang@icann.org> Date: Friday, July 21, 2023 at 8:40 AM To: "irt.regdatapolicy@icann.org" <irt.regdatapolicy@icann.org> Subject: Re: [IRT.RegDataPolicy] RegData IRT Good News. Urgent Request requirement. IRT supported solution found!
Dear IRT,
If you haven’t heard already, we did it!
We found a solution to Urgent Request supported by IRT at our 90 minutes focused working session this week. Thank you so much for not giving up and working as a team to find this solution. It was impressive to see people still listening to one another, appreciating the different views, and truly collaborating to build on ideas to find the compromised solution. A great demonstration of One Team against the problem.
What was that solution? 24 hours. Respond in 24 hours with the info or an explanation for more time needed. 2 Business Days. No more than 2 Business Days to Respond.
How did this happen? First, thanks to Roger and RrSG for the planting the seed with using both 24 hours and 2 business days in the solution. Instead of outright rejecting it, Laureen and others suggested that we build on it. Thomas came in with a key ingredient – the explanation.
Initially, we discussed all the options but created this new one listening to the “interest” behind the positions. Business Days was important because of the business realities in various regions around the world. While Calendar Days sets global time consistency, the team agreed that cultural sensitivity to regions was more important. The dread of “silence” with undetermined timeline using “Business Days” was solved with the promise of a response in 24 hours with an explanation. Thanks to Gabriel expressing the “dread” so eloquently. Overall, it was an exciting finale overcoming the toughest challenge for us.
As promised, we’ll draft the policy language using the IRT supported requirements and comeback to you, but I wanted to send you this quick note to express my sincere gratitude for wonderfully responding.
I thank those guests that joined to support us too. I noted Ashley, RrSG Chair and Becky, ICANN Board and others supporting us behind the scenes. Please convey our sincere appreciation to your team back home too.
THANK YOU!
Dennis S. Chang GDD Programs Director Phone: +1 213 293 7889 Sykpe: dennisSchang www.icann.org <http://www.icann.org/> One World – One Internet
******************** CAUTION: This email originated from outside the organization. Do not click links unless you can confirm the sender and know the content is safe. ********************
_______________________________________________ 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.
Point of Clarification (as I genuinely think this may just be a misunderstanding arising from the last minute nature of the chat on the prior call): Are we all still generally in favor of the Rickert proposal as enunciated by Dennis at the 1:29:07 timestamp here<https://icann.zoom.us/rec/play/z_7AoPc_vg01DIzOgE4RdG5AIayz6v_JgR0ek5tH_7doA...>, and transcribed (in the most general of terms) as [cid:image001.png@01D9BFB7.284919A0] ... ? I had felt at the time that there was a shared degree of optimism that this timeline was common footing (resulting from compromise by all). Still the case? ~Gabriel From: IRT.RegDataPolicy <irt.regdatapolicy-bounces@icann.org> On Behalf Of Owen Smigelski via IRT.RegDataPolicy Sent: Wednesday, July 26, 2023 10:17 AM To: Kapin, Laureen <LKAPIN@ftc.gov> Cc: irt.regdatapolicy@icann.org Subject: [EXTERNAL EMAIL] - Re: [IRT.RegDataPolicy] Concerns that proposed solution does not match 7/19 discussion RE: Review RegData complete draft Re: Good News. Urgent Request. IRT supported solution found! Hi Laureen, Although I did not attend the last IRT meeting, I have been in close consultation with my registrar colleagues. It needs to be made clear that this was a REAL compromise for registrars as it allows taking additional time to respond if necessary. Conducting the balancing test is not as simple as reviewing an abuse complaint (as many have repeatedly explained), and the penalties of improper disclosure are significant. We thus need the flexibility if certain situations require more than 24 hours. Getting rid of the previously agreed upon text of one business day puts us back in a situation where there is no compromise and the registrars will not be able to accept what was agreed to last week. On behalf of the RrSG, I would formally like to raise the concern that it appears that the IRT is being used to develop policy rather than implement recommendations. Others have expressed this concern, and the registrars support efforts to ensure that the final policy aligns with the recommendations. Regards, Owen On Jul 25, 2023, at 11:34, Kapin, Laureen via IRT.RegDataPolicy <irt.regdatapolicy@icann.org<mailto:irt.regdatapolicy@icann.org>> wrote: CAUTION: This email originated from outside the organization. Do not click links unless you can confirm the sender and know the content is safe. Dear Dennis and colleagues, We appreciate the effort the IRT members and staff have taken to get us to this point. I was very grateful for thoughtfulness and flexibility demonstrated during the call. Nevertheless, the Public Safety Working Group colleagues on the 7/19/23 call (myself, Chris, and Gabe) don't think the current draft has accurately captured the agreement reached during our discussion because it identifies two separate timelines for extensions of time to respond to urgent requests. I understood our discussion as creating a unified timeline for most requests ("without undue delay, generally within 24 hours") and then a single opportunity to for an up-to-2 business day extension. The circulated version creates two opportunities and timelines for an extension and creates the potential for a longer total timeline to respond (now 3 business days). I reviewed the recording (most relevant part starts at minute 50) and believe it supports my understanding, particularly Thomas's distillation of the key components of our agreement toward the end of the discussion. I note that part of the misunderstanding seems to have arisen because the current version, for the first time, separates out the timeline for urgent requests into three separate subsections. The public comment version for urgent requests was set forth in its entirety in10.6. Org's changes to this provision after the public comment period were also set forth in their entirety in 10.6. These were never broken out or considered as stand-alone components of the urgent request timeline. They were only broken out and separated in the version circulated yesterday. Our 7/19 discussion was focused on the entirety of the timeline to respond and setting a ceiling or limit on the response time. The PSWG participants did not view the discussion as just focusing on a partial ceiling that could be extended not one but two times for a total of three business days. Regarding a ceiling for response times, such a result would put us in a worse position than what Dennis had recently proposed (3 calendar days). For clarity, I think 10.6. and 10.6.1 accurately sets forth our discussion: 10.6. For Urgent Requests for Lawful Disclosure, Registrar and Registry Operator MUST respond, as defined in Section 10.7, without undue delay, generally within 24 hours of receipt. 10.6.1. If Registrar or Registry Operator cannot respond to an Urgent Request for Lawful Disclosure within 24 hours, it MUST notify the requestor within 24 hours of receipt of an Urgent Request for Lawful Disclosure of the need for an extension to respond. Registrar or Registry Operator's extension notification to the requestor MUST include (a) confirmation that it has reviewed and considered the Urgent Request for Lawful Disclosure on its merits and determined additional time to respond is needed, (b) rationale for why additional time is needed, and (c) the time frame it will respond, as required by Section 10.7, which cannot exceed two (2) business days from the time of the initial receipt of the request. However, I don't recall that we discussed an additional amount of time beyond the two-business day total response time. Indeed, I thought the whole goal of our discussion was to create a single ceiling beyond the "without undue delay," generally w/in 24 hours, which we ultimately agreed would expire at 2 business days from receipt. So, I was surprised to see 10.6.2: 10.6.2. In addition to the extension provided for in Section 10.6.1, if responding to an Urgent Request for Lawful Disclosure is complex, or a large number of requests are received by Registrar or Registry Operator, it MAY extend the time for response up to an additional one (1) business day provided it notifies the requestor within (2) business days from the time of the initial receipt of the request of the updated time frame to respond explaining the need for an additional extension of time. The reason that I'm concerned is that we're now back to a scenario where urgent requests could take three business days to respond to which is what the GAC objected to in its public comment as inconsistent with the nature of an "urgent" request. I think this needs further discussion because I don't think the current draft accurately reflects what we discussed on 7/19. My suggestion would be to either: 1. Delete 10.6.2 or 2. Add the concepts of "complex" and "large number" to 10.6.1 as part of the rationale that may be shared to justify an extension of time to respond to an urgent request. I suggest that we need an additional call unless this can be resolved via email. Kind regards, Laureen Kapin Assistant Director for International Consumer Protection Office of International Affairs Federal Trade Commission lkapin@ftc.gov<mailto:lkapin@ftc.gov> From: IRT.RegDataPolicy <irt.regdatapolicy-bounces@icann.org<mailto:irt.regdatapolicy-bounces@icann.org>> On Behalf Of Dennis Chang via IRT.RegDataPolicy Sent: Monday, July 24, 2023 5:24 PM To: irt.regdatapolicy@icann.org<mailto:irt.regdatapolicy@icann.org> Subject: [IRT.RegDataPolicy] Review RegData complete draft Re: Good News. Urgent Request. IRT supported solution found! Dear IRT, Attached is a completed draft of the Registration Data Policy including the last two outstanding sections. Section 4.0: Policy Effective Date reflecting the 6+12 plan for the 18-month implementation timeline. Section 10.6: Urgent Request reflecting the solution supported at the IRT meeting last week. (see email below) I believe we now have a good policy that is aligned with all 34 recommendations we will work together to implement. EPDP Phase 1 recommendations (29) May 2019 EPDP Phase 2 Priority 2 Recommendations (4) June 2021 Supplemental Recommendation (1) March 2022 As we discussed at our last IRT meeting, we don't plan on more IRT meetings before we publish our policy in August 2023. We'll notify you of the publication date after we have coordinated with our publication team. We may have more IRT meetings after we publish to coordinate and collaborate our implementation, but that decision will come later. For now, we will focus on getting this policy published. If you have questions or comments, I request they be submitted in separate emails with Subject line defining the topic. It will help us to collect the information as we address them together. Thank you all once again and I hope you all support the attached policy language for publication and implementation. Gratefully your, Dennis Chang From: "IRT.RegDataPolicy" <irt.regdatapolicy-bounces@icann.org<mailto:irt.regdatapolicy-bounces@icann.org>> on behalf of "Dennis Chang via IRT.RegDataPolicy" <irt.regdatapolicy@icann.org<mailto:irt.regdatapolicy@icann.org>> Reply-To: Dennis Chang <dennis.chang@icann.org<mailto:dennis.chang@icann.org>> Date: Friday, July 21, 2023 at 8:40 AM To: "irt.regdatapolicy@icann.org<mailto:irt.regdatapolicy@icann.org>" <irt.regdatapolicy@icann.org<mailto:irt.regdatapolicy@icann.org>> Subject: Re: [IRT.RegDataPolicy] RegData IRT Good News. Urgent Request requirement. IRT supported solution found! Dear IRT, If you haven't heard already, we did it! We found a solution to Urgent Request supported by IRT at our 90 minutes focused working session this week. Thank you so much for not giving up and working as a team to find this solution. It was impressive to see people still listening to one another, appreciating the different views, and truly collaborating to build on ideas to find the compromised solution. A great demonstration of One Team against the problem. What was that solution? * 24 hours. Respond in 24 hours with the info or an explanation for more time needed. * 2 Business Days. No more than 2 Business Days to Respond. How did this happen? First, thanks to Roger and RrSG for the planting the seed with using both 24 hours and 2 business days in the solution. Instead of outright rejecting it, Laureen and others suggested that we build on it. Thomas came in with a key ingredient - the explanation. Initially, we discussed all the options but created this new one listening to the "interest" behind the positions. Business Days was important because of the business realities in various regions around the world. While Calendar Days sets global time consistency, the team agreed that cultural sensitivity to regions was more important. The dread of "silence" with undetermined timeline using "Business Days" was solved with the promise of a response in 24 hours with an explanation. Thanks to Gabriel expressing the "dread" so eloquently. Overall, it was an exciting finale overcoming the toughest challenge for us. As promised, we'll draft the policy language using the IRT supported requirements and comeback to you, but I wanted to send you this quick note to express my sincere gratitude for wonderfully responding. I thank those guests that joined to support us too. I noted Ashley, RrSG Chair and Becky, ICANN Board and others supporting us behind the scenes. Please convey our sincere appreciation to your team back home too. THANK YOU! Dennis S. Chang GDD Programs Director Phone: +1 213 293 7889 Sykpe: dennisSchang www.icann.org<https://usg02.safelinks.protection.office365.us/?url=http%3A%2F%2Fwww.icann....> One World - One Internet ******************** CAUTION: This email originated from outside the organization. Do not click links unless you can confirm the sender and know the content is safe. ******************** _______________________________________________ IRT.RegDataPolicy mailing list IRT.RegDataPolicy@icann.org<mailto: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 26 de jul. de 2023, à(s) 15:48, Gabriel Andrews via IRT.RegDataPolicy <irt.regdatapolicy@icann.org> escreveu:
Point of Clarification (as I genuinely think this may just be a misunderstanding arising from the last minute nature of the chat on the prior call):
Are we all still generally in favor of the Rickert proposal as enunciated by Dennis at the 1:29:07 timestamp here <https://icann.zoom.us/rec/play/z_7AoPc_vg01DIzOgE4RdG5AIayz6v_JgR0ek5tH_7doA...>, and transcribed (in the most general of terms) as
<image001.png>
… ?
I had felt at the time that there was a shared degree of optimism that this timeline was common footing (resulting from compromise by all). Still the case?
For simple requests (like: what’s the registration data for domain example.example), it’s still the case. But the policy already had a mechanism for complex requests (like: what’s the registration data for all domains registered to address 1600 Pennsylvania Avenue NW, Washington DC), which wasn’t discussed during the call. And since there was no discussion on that aspect, there is nothing in the transcript about it. Are you suggesting that all requests are equal and should be answered in the same time ? Or that the urgent tag of requests can only be applied to simple requests ? Rubens
Folks, The IRT has reached closure and consensus on the wording for Urgent Requests. Here are the concerns I continue to have. 1. How to reach the registrar So far as I can tell, the proposed procedures and policies do not include a well specified means for reaching a registrar urgently. This seems to me a gap, i.e., an incomplete solution. A gap of this sort means the proposed system is not fit for purpose (NFfP). NFfP is a showstopper. No amount of process or consensus or reference to the policy development process manual overcomes NFfP. Current registrar contact info is idiosyncratic, i.e. not organized in any uniform way. Some of the registrar representatives (Sarah, Owen) claim law enforcement personnel know how to reach them. Some law enforcement personnel (Gabe) say that when law enforcement specific contacts exist, they are not universally known to all law enforcement entities for all registrars. Whois queries now include contact info for reporting Abuses. However, when I suggested LEA could use the Abuse contact, a registrar representative said fielding Abuse reports and fielding Urgent Requests requires different skill sets, and the people on duty to handle Abuse reports cannot be used to field Urgent Requests. This begs further discussion. What will the person fielding Abuse complaints do if the input is from a law enforcement agent presenting an Urgent Request? Further, law enforcement personnel, when asked “What do you actually do in practice?” respond, “We use all available means.” I suggested registrars supply a contact for Urgent Requests, and that it be available only to trusted requesters, principally known law enforcement personnel. Further, ICANN could maintain such a list and act as an intermediary. The financial impact on registrars should be negligible because this only requires reaching a responsible party within the registrar. It does not impose any specific requirement on what the registrar does with the call. Making the contact data available only to trusted personnel and/or having ICANN field the requests would essentially eliminate the registrars’ concerns about being inundated with false requests. If I recall correctly, this was rejected for two distinct reasons. One was an insistence that such calls would necessarily require bringing an attorney into the conversation to determine whether the request is genuinely Urgent and that it is permissible to provide the requested data. The other response was this constituted a new proposal and thus is outside the scope of the Implementation Review Team. 2. Actual data There does not seem to be any data on situations that have arisen in the past that resulted in Urgent Requests. Or, even if the criteria is loosened to include other requests that do not fit the narrowly defined definition of an Urgent Request but nonetheless were urgent (lowercase) and high priority, there doesn’t seem to be any concrete data. This makes it hard to know whether there really needs to be a defined procedure for handling Urgent Requests. I assume the group has nonetheless agreed to this. Going forward, Urgent Requests should be reported and the data reported on a regular basis. As far as I can tell, nothing along this line is included in the current proposal. This is not a showstopper, but it’s a lack and should be addressed. 3. Confusion; Optics The wording embodies two kinds of confusion. First, by emphasizing the maximum response time, it creates the impression that ICANN is officially specifying the response time for Urgent Requests to be measured in days. This is both confusing and a bad look. At the very least, the description of the rule should make it clear that registrars are expected to respond quickly. The specification of a maximum response time is intended to deal with worst case situations, not normal emergencies. Second, the registrars are really looking for protection against harassment or penalty if they haven’t responded quickly. Whether the response time is 24 hours or several days due to vacations is probably not relevant for Urgent Requests. It will be too late. Instead, the purpose of this specification is to protect registrars from having to maintain a standing army of lawyers and to protect themselves from a flood of bogus requests. Much clearer wording would help.
Hi folks, I agree with many of the important points that Steve raises, except for one. I don’t think we have in fact yet reached consensus because as Gabe and I indicated in our emails to the IRT, in our view, the circulated language does not match the discussion we had during the last call. Kind regards, Laureen Kapin Assistant Director International Consumer Protection Federal Trade Commission Sent via mobile phone Please excuse unintended autocorrect outcomes ________________________________ From: IRT.RegDataPolicy <irt.regdatapolicy-bounces@icann.org> on behalf of Steve Crocker via IRT.RegDataPolicy <irt.regdatapolicy@icann.org> Sent: Friday, July 28, 2023 12:31:28 PM To: irt.regdatapolicy@icann.org <irt.regdatapolicy@icann.org> Subject: [IRT.RegDataPolicy] Still concerned about loose ends Folks, The IRT has reached closure and consensus on the wording for Urgent Requests. Here are the concerns I continue to have. 1. How to reach the registrar So far as I can tell, the proposed procedures and policies do not include a well specified means for reaching a registrar urgently. This seems to me a gap, i.e., an incomplete solution. A gap of this sort means the proposed system is not fit for purpose (NFfP). NFfP is a showstopper. No amount of process or consensus or reference to the policy development process manual overcomes NFfP. Current registrar contact info is idiosyncratic, i.e. not organized in any uniform way. Some of the registrar representatives (Sarah, Owen) claim law enforcement personnel know how to reach them. Some law enforcement personnel (Gabe) say that when law enforcement specific contacts exist, they are not universally known to all law enforcement entities for all registrars. Whois queries now include contact info for reporting Abuses. However, when I suggested LEA could use the Abuse contact, a registrar representative said fielding Abuse reports and fielding Urgent Requests requires different skill sets, and the people on duty to handle Abuse reports cannot be used to field Urgent Requests. This begs further discussion. What will the person fielding Abuse complaints do if the input is from a law enforcement agent presenting an Urgent Request? Further, law enforcement personnel, when asked “What do you actually do in practice?” respond, “We use all available means.” I suggested registrars supply a contact for Urgent Requests, and that it be available only to trusted requesters, principally known law enforcement personnel. Further, ICANN could maintain such a list and act as an intermediary. The financial impact on registrars should be negligible because this only requires reaching a responsible party within the registrar. It does not impose any specific requirement on what the registrar does with the call. Making the contact data available only to trusted personnel and/or having ICANN field the requests would essentially eliminate the registrars’ concerns about being inundated with false requests. If I recall correctly, this was rejected for two distinct reasons. One was an insistence that such calls would necessarily require bringing an attorney into the conversation to determine whether the request is genuinely Urgent and that it is permissible to provide the requested data. The other response was this constituted a new proposal and thus is outside the scope of the Implementation Review Team. 2. Actual data There does not seem to be any data on situations that have arisen in the past that resulted in Urgent Requests. Or, even if the criteria is loosened to include other requests that do not fit the narrowly defined definition of an Urgent Request but nonetheless were urgent (lowercase) and high priority, there doesn’t seem to be any concrete data. This makes it hard to know whether there really needs to be a defined procedure for handling Urgent Requests. I assume the group has nonetheless agreed to this. Going forward, Urgent Requests should be reported and the data reported on a regular basis. As far as I can tell, nothing along this line is included in the current proposal. This is not a showstopper, but it’s a lack and should be addressed. 3. Confusion; Optics The wording embodies two kinds of confusion. First, by emphasizing the maximum response time, it creates the impression that ICANN is officially specifying the response time for Urgent Requests to be measured in days. This is both confusing and a bad look. At the very least, the description of the rule should make it clear that registrars are expected to respond quickly. The specification of a maximum response time is intended to deal with worst case situations, not normal emergencies. Second, the registrars are really looking for protection against harassment or penalty if they haven’t responded quickly. Whether the response time is 24 hours or several days due to vacations is probably not relevant for Urgent Requests. It will be too late. Instead, the purpose of this specification is to protect registrars from having to maintain a standing army of lawyers and to protect themselves from a flood of bogus requests. Much clearer wording would help.
Em 28 de jul. de 2023, à(s) 16:39, Kapin, Laureen via IRT.RegDataPolicy <irt.regdatapolicy@icann.org> escreveu:
Hi folks,
I agree with many of the important points that Steve raises, except for one. I don’t think we have in fact yet reached consensus because as Gabe and I indicated in our emails to the IRT, in our view, the circulated language does not match the discussion we had during the last call.
Which is simply wrong, because the language matches what was discussed, since the complex requests issue was not discussed at all. Something can’t match or don’t match a theme that nobody talked to. But if the new language has not reached consensus, which is a decision I’m glad I don’t have to make, we can just go back to the language that reached consensus and was published for public comments. Rubens
Procedurally, the last official version was what the ICANN Org team published after analysis of the public comments. Kind regards, Laureen Kapin Assistant Director International Consumer Protection Federal Trade Commission Sent via mobile phone Please excuse unintended autocorrect outcomes ________________________________ From: IRT.RegDataPolicy <irt.regdatapolicy-bounces@icann.org> on behalf of Rubens Kuhl via IRT.RegDataPolicy <irt.regdatapolicy@icann.org> Sent: Friday, July 28, 2023 12:50:53 PM To: irt.regdatapolicy@icann.org <irt.regdatapolicy@icann.org> Subject: Re: [IRT.RegDataPolicy] Still concerned about loose ends
Em 28 de jul. de 2023, à(s) 16:39, Kapin, Laureen via IRT.RegDataPolicy <irt.regdatapolicy@icann.org> escreveu:
Hi folks,
I agree with many of the important points that Steve raises, except for one. I don’t think we have in fact yet reached consensus because as Gabe and I indicated in our emails to the IRT, in our view, the circulated language does not match the discussion we had during the last call.
Which is simply wrong, because the language matches what was discussed, since the complex requests issue was not discussed at all. Something can’t match or don’t match a theme that nobody talked to. But if the new language has not reached consensus, which is a decision I’m glad I don’t have to make, we can just go back to the language that reached consensus and was published for public comments. Rubens
Em 28 de jul. de 2023, à(s) 17:18, Kapin, Laureen <LKAPIN@ftc.gov> escreveu:
Procedurally, the last official version was what the ICANN Org team published after analysis of the public comments.
That version never reached consensus, so it can’t be part of a Consensus Policy, capital C, capital P. And not being a Consensus Policy, it can’t be enforced on contracted parties. Trying to move that version forward would only cause more delays, besides making Org lose all credibility to uphold the PDP Manual and the bylaws. And the material for the accountability mechanisms that will be triggered is readily available in the archive for this mailing list and in the transcripts, like in “ICANN Org decided by itself it would do like this”. If PSWG wants to push ICANN Org off a cliff, it’s doing a good job at that. Rubens
Hi all, Please see my responses to Steve below in-line. Regards, Owen
On Jul 28, 2023, at 12:31, Steve Crocker via IRT.RegDataPolicy <irt.regdatapolicy@icann.org> wrote:
CAUTION: This email originated from outside the organization. Do not click links unless you can confirm the sender and know the content is safe. Folks,
The IRT has reached closure and consensus on the wording for Urgent Requests. Here are the concerns I continue to have.
1. How to reach the registrar
So far as I can tell, the proposed procedures and policies do not include a well specified means for reaching a registrar urgently. This seems to me a gap, i.e., an incomplete solution. A gap of this sort means the proposed system is not fit for purpose (NFfP). NFfP is a showstopper. No amount of process or consensus or reference to the policy development process manual overcomes NFfP.
Current registrar contact info is idiosyncratic, i.e. not organized in any uniform way. Some of the registrar representatives (Sarah, Owen) claim law enforcement personnel know how to reach them. Some law enforcement personnel (Gabe) say that when law enforcement specific contacts exist, they are not universally known to all law enforcement entities for all registrars.
I did not claim that LEA know how to reach registrars. I stated that the RAA (in Section 3.18.2) requires all registrars to maintain a contact to receive abuse complaints from LEA. The RAA, however, does not require this contact to be public (as once a contact becomes public, it becomes a honeypot and loses its value). If a registrar will not provide LEA with the dedicated LEA contact, ICANN Compliance 100% can require the registrar to do so. Recent ICANN audits have also tested LEA abuse contacts and made registrars remediate if it was determined that they were noncompliant. I am very frustrated seeing the whole “we don’t know how to contact registrars” line, because for 10 years, the RAA has required registrars to provide these contacts. I also know that ICANN has terminated registrars for not providing the proper contacts.
Whois queries now include contact info for reporting Abuses. However, when I suggested LEA could use the Abuse contact, a registrar representative said fielding Abuse reports and fielding Urgent Requests requires different skill sets, and the people on duty to handle Abuse reports cannot be used to field Urgent Requests.
This was a requirement in the 2013 RAA, and I’ll be blunt, it was a complete disaster. The 2013 RAA required abuse contacts to be an email address, which resulted in almost 100% of emails being spam. Because the abuse contact was originally supposed to be towards the top of the whois output, a decent amount of people assumed the abuse contact was the registrant’s contact leading to more confusion. Many registrars now automate the abuse email to reply with a link to a form to ensure the proper data is supplied and to reduce spam. ICANN also allowed abuse emails to be displayed towards the bottom of whois output. And yes, an LEA contact should be different than an abuse contact. The requirements in the RAA for an abuse complaint are to "take reasonable and prompt steps to investigate and respond appropriately” which is a lot different than the LEA obligation, which require a non-automated response within 24 hours. Namecheap processes over 1 million abuse complaints a year, so yes, LEA and data disclosure requests should be through a different contact so they can be timely identified and actioned.
This begs further discussion. What will the person fielding Abuse complaints do if the input is from a law enforcement agent presenting an Urgent Request? Further, law enforcement personnel, when asked “What do you actually do in practice?” respond, “We use all available means.”
Again, as I have stated repeatedly, disclosure requests should be separate from abuse complaints. Registrars do not just have one single queue for handling the myriad of inquiries we receive- whois inaccuracy, UDRP provider emails, customer support inquiries, web hosting requests, DMCA complaints, ICANN tickets, ccTLD tickets, etc, etc, etc. Some of these require special training to respond to (e.g. LEA abuse complaints), whereas others can be handled by low level/introductory support staff. Disclosure requests require legal review. Lawyers are not working these queues, and for many smaller registrars, the lawyers are outside counsel. We need to stop conflating disclosure requests with general registrar requests/inquires such as abuse complaints, because they require a significant level of sophistication that the other 99.9% of requests do not require. Although Namecheap does not maintain data, I can confirm that a large number of people use our abuse queue to submit data disclosure requests. This is despite that our website clearly states how to request data, and it is completely outside of our abuse process. Yes, those requests are delayed because our abuse team is trained to process… abuse complaints.
I suggested registrars supply a contact for Urgent Requests, and that it be available only to trusted requesters, principally known law enforcement personnel. Further, ICANN could maintain such a list and act as an intermediary. The financial impact on registrars should be negligible because this only requires reaching a responsible party within the registrar. It does not impose any specific requirement on what the registrar does with the call. Making the contact data available only to trusted personnel and/or having ICANN field the requests would essentially eliminate the registrars’ concerns about being inundated with false requests.
I disagree that the financial impact is negligible. As the registrars have stated on numerous occasions, data disclosure requests require legal review. Lawyers are expensive. Keeping such a lawyer (or lawyers) on call 24/7/365 is cost prohibited for Namecheap, and we are one of the largest registrars in the world. This would be impossible for most (if not all) registrars. The penalties for improper disclosure are staggeringly high, which is why lawyers have to be involved (plus it is a legal balancing process, not looking to see if a domain is phishing or not). The potential liability for suspending a benign site for abuse is so much lower.
If I recall correctly, this was rejected for two distinct reasons. One was an insistence that such calls would necessarily require bringing an attorney into the conversation to determine whether the request is genuinely Urgent and that it is permissible to provide the requested data. The other response was this constituted a new proposal and thus is outside the scope of the Implementation Review Team.
Yes, this is correct. Lawyers will always be involved in a data disclosure request due to the high risk of improper disclosure and the nature of the balancing test. I am concerned that this fact does not appear to acknowledged by those who continue to insist on impossibly short disclosure periods.
2. Actual data
There does not seem to be any data on situations that have arisen in the past that resulted in Urgent Requests. Or, even if the criteria is loosened to include other requests that do not fit the narrowly defined definition of an Urgent Request but nonetheless were urgent (lowercase) and high priority, there doesn’t seem to be any concrete data.
This makes it hard to know whether there really needs to be a defined procedure for handling Urgent Requests. I assume the group has nonetheless agreed to this. Going forward, Urgent Requests should be reported and the data reported on a regular basis.
Agreed there should be data.
As far as I can tell, nothing along this line is included in the current proposal. This is not a showstopper, but it’s a lack and should be addressed.
3. Confusion; Optics
The wording embodies two kinds of confusion. First, by emphasizing the maximum response time, it creates the impression that ICANN is officially specifying the response time for Urgent Requests to be measured in days. This is both confusing and a bad look. At the very least, the description of the rule should make it clear that registrars are expected to respond quickly. The specification of a maximum response time is intended to deal with worst case situations, not normal emergencies.
A fine under the GDPR can be up to 2% of a company’s worldwide annual revenue. While I appreciate the optics and the need for urgent requests (and in most scenarios Namecheap can accommodate an urgent request), I cannot commit my company to an impossible timeline that could result in a $5 million fine if Namecheap makes an improper disclosure. I’m a lawyer, so I cannot approach this by looking at "most scenarios". I need to look at the extreme cases, because that is how we ensure we can comply all of the time. Because I guarantee, at some point, the “worst case” scenario will arise, and a registrar will either lose an accreditation or face a massive fine.
Second, the registrars are really looking for protection against harassment or penalty if they haven’t responded quickly. Whether the response time is 24 hours or several days due to vacations is probably not relevant for Urgent Requests. It will be too late. Instead, the purpose of this specification is to protect registrars from having to maintain a standing army of lawyers and to protect themselves from a flood of bogus requests.
Which should I tell my boss we should risk: a multimillion dollar fine, or losing our ability to do business? I cannot tell him to do either. We need to have a reasonable timeframe for disclosure request that is indeed measured in business days because that is what the policy stated.
Much clearer wording would help.
******************** CAUTION: This email originated from outside the organization. Do not click links unless you can confirm the sender and know the content is safe. ********************
_______________________________________________ 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.
Owen, In my view, all of the registrars have to supply all of the legitimate law enforcement agencies with points of contact that are immediately reachable for Urgent Requests. And it has to be testable and tested. Until we have that in place, we don't have a working system. Steve On Fri, Jul 28, 2023 at 4:21 PM Owen Smigelski via IRT.RegDataPolicy < irt.regdatapolicy@icann.org> wrote:
Hi all,
Please see my responses to Steve below in-line.
Regards,
Owen
On Jul 28, 2023, at 12:31, Steve Crocker via IRT.RegDataPolicy < irt.regdatapolicy@icann.org> wrote:
*CAUTION: **This email originated from outside the organization. Do not click links unless you can confirm the sender and know the content is safe.* Folks,
The IRT has reached closure and consensus on the wording for Urgent Requests. Here are the concerns I continue to have.
1. How to reach the registrar
So far as I can tell, the proposed procedures and policies do not include a well specified means for reaching a registrar urgently. This seems to me a gap, i.e., an incomplete solution. A gap of this sort means the proposed system is not fit for purpose (NFfP). NFfP is a showstopper. No amount of process or consensus or reference to the policy development process manual overcomes NFfP.
Current registrar contact info is idiosyncratic, i.e. not organized in any uniform way. Some of the registrar representatives (Sarah, Owen) claim law enforcement personnel know how to reach them. Some law enforcement personnel (Gabe) say that when law enforcement specific contacts exist, they are not universally known to all law enforcement entities for all registrars.
I did not claim that LEA know how to reach registrars.
I stated that the RAA (in Section 3.18.2) requires all registrars to maintain a contact to receive abuse complaints from LEA. The RAA, however, does not require this contact to be public (as once a contact becomes public, it becomes a honeypot and loses its value). If a registrar will not provide LEA with the dedicated LEA contact, ICANN Compliance 100% can require the registrar to do so.
Recent ICANN audits have also tested LEA abuse contacts and made registrars remediate if it was determined that they were noncompliant. I am very frustrated seeing the whole “we don’t know how to contact registrars” line, because for 10 years, the RAA has required registrars to provide these contacts. I also know that ICANN has terminated registrars for not providing the proper contacts.
Whois queries now include contact info for reporting Abuses. However, when I suggested LEA could use the Abuse contact, a registrar representative said fielding Abuse reports and fielding Urgent Requests requires different skill sets, and the people on duty to handle Abuse reports cannot be used to field Urgent Requests.
This was a requirement in the 2013 RAA, and I’ll be blunt, it was a complete disaster.
The 2013 RAA required abuse contacts to be an email address, which resulted in almost 100% of emails being spam. Because the abuse contact was originally supposed to be towards the top of the whois output, a decent amount of people assumed the abuse contact was the registrant’s contact leading to more confusion. Many registrars now automate the abuse email to reply with a link to a form to ensure the proper data is supplied and to reduce spam. ICANN also allowed abuse emails to be displayed towards the bottom of whois output.
And yes, an LEA contact should be different than an abuse contact. The requirements in the RAA for an abuse complaint are to "take reasonable and prompt steps to investigate and respond appropriately” which is a lot different than the LEA obligation, which require a non-automated response within 24 hours. Namecheap processes over 1 million abuse complaints a year, so yes, LEA and data disclosure requests should be through a different contact so they can be timely identified and actioned.
This begs further discussion. What will the person fielding Abuse complaints do if the input is from a law enforcement agent presenting an Urgent Request? Further, law enforcement personnel, when asked “What do you actually do in practice?” respond, “We use all available means.”
Again, as I have stated repeatedly, disclosure requests should be separate from abuse complaints. Registrars do not just have one single queue for handling the myriad of inquiries we receive- whois inaccuracy, UDRP provider emails, customer support inquiries, web hosting requests, DMCA complaints, ICANN tickets, ccTLD tickets, etc, etc, etc. Some of these require special training to respond to (e.g. LEA abuse complaints), whereas others can be handled by low level/introductory support staff.
Disclosure requests require legal review. Lawyers are not working these queues, and for many smaller registrars, the lawyers are outside counsel. We need to stop conflating disclosure requests with general registrar requests/inquires such as abuse complaints, because they require a significant level of sophistication that the other 99.9% of requests do not require.
Although Namecheap does not maintain data, I can confirm that a large number of people use our abuse queue to submit data disclosure requests. This is despite that our website clearly states how to request data, and it is completely outside of our abuse process. Yes, those requests are delayed because our abuse team is trained to process… abuse complaints.
I suggested registrars supply a contact for Urgent Requests, and that it be available only to trusted requesters, principally known law enforcement personnel. Further, ICANN could maintain such a list and act as an intermediary. The financial impact on registrars should be negligible because this only requires reaching a responsible party within the registrar. It does not impose any specific requirement on what the registrar does with the call. Making the contact data available only to trusted personnel and/or having ICANN field the requests would essentially eliminate the registrars’ concerns about being inundated with false requests.
I disagree that the financial impact is negligible.
As the registrars have stated on numerous occasions, data disclosure requests require legal review. Lawyers are expensive. Keeping such a lawyer (or lawyers) on call 24/7/365 is cost prohibited for Namecheap, and we are one of the largest registrars in the world. This would be impossible for most (if not all) registrars. The penalties for improper disclosure are staggeringly high, which is why lawyers have to be involved (plus it is a legal balancing process, not looking to see if a domain is phishing or not). The potential liability for suspending a benign site for abuse is so much lower.
If I recall correctly, this was rejected for two distinct reasons. One was an insistence that such calls would necessarily require bringing an attorney into the conversation to determine whether the request is genuinely Urgent and that it is permissible to provide the requested data. The other response was this constituted a new proposal and thus is outside the scope of the Implementation Review Team.
Yes, this is correct. Lawyers will always be involved in a data disclosure request due to the high risk of improper disclosure and the nature of the balancing test. I am concerned that this fact does not appear to acknowledged by those who continue to insist on impossibly short disclosure periods.
2. Actual data
There does not seem to be any data on situations that have arisen in the past that resulted in Urgent Requests. Or, even if the criteria is loosened to include other requests that do not fit the narrowly defined definition of an Urgent Request but nonetheless were urgent (lowercase) and high priority, there doesn’t seem to be any concrete data.
This makes it hard to know whether there really needs to be a defined procedure for handling Urgent Requests. I assume the group has nonetheless agreed to this. Going forward, Urgent Requests should be reported and the data reported on a regular basis.
Agreed there should be data.
As far as I can tell, nothing along this line is included in the current proposal. This is not a showstopper, but it’s a lack and should be addressed.
3. Confusion; Optics
The wording embodies two kinds of confusion. First, by emphasizing the maximum response time, it creates the impression that ICANN is officially specifying the response time for Urgent Requests to be measured in days. This is both confusing and a bad look. At the very least, the description of the rule should make it clear that registrars are expected to respond quickly. The specification of a maximum response time is intended to deal with worst case situations, not normal emergencies.
A fine under the GDPR can be up to 2% of a company’s worldwide annual revenue. While I appreciate the optics and the need for urgent requests (and in most scenarios Namecheap can accommodate an urgent request), I cannot commit my company to an impossible timeline that could result in a $5 million fine if Namecheap makes an improper disclosure.
I’m a lawyer, so I cannot approach this by looking at "most scenarios". I need to look at the extreme cases, because that is how we ensure we can comply all of the time. Because I guarantee, at some point, the “worst case” scenario will arise, and a registrar will either lose an accreditation or face a massive fine.
Second, the registrars are really looking for protection against harassment or penalty if they haven’t responded quickly. Whether the response time is 24 hours or several days due to vacations is probably not relevant for Urgent Requests. It will be too late. Instead, the purpose of this specification is to protect registrars from having to maintain a standing army of lawyers and to protect themselves from a flood of bogus requests.
Which should I tell my boss we should risk: a multimillion dollar fine, or losing our ability to do business? I cannot tell him to do either. We need to have a reasonable timeframe for disclosure request that is indeed measured in business days because that is what the policy stated.
Much clearer wording would help.
******************** CAUTION: This email originated from outside the organization. Do not click links unless you can confirm the sender and know the content is safe. ********************
_______________________________________________ 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.
_______________________________________________ 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 Owen, I appreciate your input and agree with you on several points. I believe that there is good intent in the IRT to find a compromise here. I also agree that our goal is to implement the Phase 1 policy, not develop new policy. Simply stated, I think that there was a mismatch between the compromise described during the call and the proffered IRT language. I participated in the last call and reviewed the recordings and there was not discussion of a three-business day ceiling. The GAC expressed concerns about lengthy timelines in its public comment in the first place and the proffered IRT language maintains the original ceiling of three business days. However, during our last call we focused on a ceiling of two business days. I propose the following text to ensure that we implement the compromise discussed on the call which involved the “without undue delay, generally 24 hours” and the opportunity to request extensions of up to two business days: 10.6. For Urgent Requests for Lawful Disclosure, Registrar and Registry Operator MUST respond, as defined in Section 10.7, without undue delay, generally within 24 hours of receipt. 10.6.1. If Registrar or Registry Operator cannot respond to an Urgent Request for Lawful Disclosure within 24 hours, it MUST notify the requestor within 24 hours of receipt of an Urgent Request for Lawful Disclosure of the need for an extension to respond. 10.6.2 Registrar or Registry Operator’s extension notification to the requestor MUST include (a) confirmation that it has reviewed and considered the Urgent Request for Lawful Disclosure on its merits and determined additional time to respond is needed, (b) rationale for why additional time is needed (including if a request is complex or the Registrar or Registry Operator received a large number of requests), and (c) the time frame it will respond, as required by Section 10.7, which cannot exceed two (2) business days from the time of the initial receipt of the request. For context, here is what ICANN Org offered after it assessed the public comments: 10.6. For Urgent Requests for Lawful Disclosure, Registrar and Registry Operator MUST acknowledge and respond without undue delay, but no more than 24 hours from receipt. If responding to an Urgent Request for Lawful Disclosure is complex, or a large number are received by Registrar or Registry Operator, it MAY extend the time for response up to an additional one (1) business day from the date of receipt of the Urgent Request for Lawful Disclosure, provided it gives notice to the requestor within the initial 24 hour period and explains the need for an extension of time. This construct shows that original structure comprised an initial period and one additional opportunity for an extension, not two. I ask that folks review the recordings and then seriously consider this PSWG revision. We believe it is faithful to the compromise reached during the call. Kind regards, Laureen Kapin Assistant Director for International Consumer Protection Office of International Affairs Federal Trade Commission lkapin@ftc.gov From: Owen Smigelski <owen.smigelski@namecheap.com> Sent: Wednesday, July 26, 2023 1:17 PM To: Kapin, Laureen <LKAPIN@ftc.gov> Cc: Dennis Chang <dennis.chang@icann.org>; irt.regdatapolicy@icann.org Subject: Re: [IRT.RegDataPolicy] Concerns that proposed solution does not match 7/19 discussion RE: Review RegData complete draft Re: Good News. Urgent Request. IRT supported solution found! Hi Laureen, Although I did not attend the last IRT meeting, I have been in close consultation with my registrar colleagues. It needs to be made clear that this was a REAL compromise for registrars as it allows taking additional time to respond if necessary. Conducting the balancing test is not as simple as reviewing an abuse complaint (as many have repeatedly explained), and the penalties of improper disclosure are significant. We thus need the flexibility if certain situations require more than 24 hours. Getting rid of the previously agreed upon text of one business day puts us back in a situation where there is no compromise and the registrars will not be able to accept what was agreed to last week. On behalf of the RrSG, I would formally like to raise the concern that it appears that the IRT is being used to develop policy rather than implement recommendations. Others have expressed this concern, and the registrars support efforts to ensure that the final policy aligns with the recommendations. Regards, Owen On Jul 25, 2023, at 11:34, Kapin, Laureen via IRT.RegDataPolicy <irt.regdatapolicy@icann.org> wrote: CAUTION: This email originated from outside the organization. Do not click links unless you can confirm the sender and know the content is safe. Dear Dennis and colleagues, We appreciate the effort the IRT members and staff have taken to get us to this point. I was very grateful for thoughtfulness and flexibility demonstrated during the call. Nevertheless, the Public Safety Working Group colleagues on the 7/19/23 call (myself, Chris, and Gabe) don’t think the current draft has accurately captured the agreement reached during our discussion because it identifies two separate timelines for extensions of time to respond to urgent requests. I understood our discussion as creating a unified timeline for most requests (“without undue delay, generally within 24 hours”) and then a single opportunity to for an up-to-2 business day extension. The circulated version creates two opportunities and timelines for an extension and creates the potential for a longer total timeline to respond (now 3 business days). I reviewed the recording (most relevant part starts at minute 50) and believe it supports my understanding, particularly Thomas’s distillation of the key components of our agreement toward the end of the discussion. I note that part of the misunderstanding seems to have arisen because the current version, for the first time, separates out the timeline for urgent requests into three separate subsections. The public comment version for urgent requests was set forth in its entirety in10.6. Org’s changes to this provision after the public comment period were also set forth in their entirety in 10.6. These were never broken out or considered as stand-alone components of the urgent request timeline. They were only broken out and separated in the version circulated yesterday. Our 7/19 discussion was focused on the entirety of the timeline to respond and setting a ceiling or limit on the response time. The PSWG participants did not view the discussion as just focusing on a partial ceiling that could be extended not one but two times for a total of three business days. Regarding a ceiling for response times, such a result would put us in a worse position than what Dennis had recently proposed (3 calendar days). For clarity, I think 10.6. and 10.6.1 accurately sets forth our discussion: 10.6. For Urgent Requests for Lawful Disclosure, Registrar and Registry Operator MUST respond, as defined in Section 10.7, without undue delay, generally within 24 hours of receipt. 10.6.1. If Registrar or Registry Operator cannot respond to an Urgent Request for Lawful Disclosure within 24 hours, it MUST notify the requestor within 24 hours of receipt of an Urgent Request for Lawful Disclosure of the need for an extension to respond. Registrar or Registry Operator’s extension notification to the requestor MUST include (a) confirmation that it has reviewed and considered the Urgent Request for Lawful Disclosure on its merits and determined additional time to respond is needed, (b) rationale for why additional time is needed, and (c) the time frame it will respond, as required by Section 10.7, which cannot exceed two (2) business days from the time of the initial receipt of the request. However, I don’t recall that we discussed an additional amount of time beyond the two-business day total response time. Indeed, I thought the whole goal of our discussion was to create a single ceiling beyond the “without undue delay,” generally w/in 24 hours, which we ultimately agreed would expire at 2 business days from receipt. So, I was surprised to see 10.6.2: 10.6.2. In addition to the extension provided for in Section 10.6.1, if responding to an Urgent Request for Lawful Disclosure is complex, or a large number of requests are received by Registrar or Registry Operator, it MAY extend the time for response up to an additional one (1) business day provided it notifies the requestor within (2) business days from the time of the initial receipt of the request of the updated time frame to respond explaining the need for an additional extension of time. The reason that I’m concerned is that we’re now back to a scenario where urgent requests could take three business days to respond to which is what the GAC objected to in its public comment as inconsistent with the nature of an “urgent” request. I think this needs further discussion because I don’t think the current draft accurately reflects what we discussed on 7/19. My suggestion would be to either: 1. Delete 10.6.2 or 2. Add the concepts of “complex” and “large number” to 10.6.1 as part of the rationale that may be shared to justify an extension of time to respond to an urgent request. I suggest that we need an additional call unless this can be resolved via email. 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 Dennis Chang via IRT.RegDataPolicy Sent: Monday, July 24, 2023 5:24 PM To: irt.regdatapolicy@icann.org Subject: [IRT.RegDataPolicy] Review RegData complete draft Re: Good News. Urgent Request. IRT supported solution found! Dear IRT, Attached is a completed draft of the Registration Data Policy including the last two outstanding sections. Section 4.0: Policy Effective Date reflecting the 6+12 plan for the 18-month implementation timeline. Section 10.6: Urgent Request reflecting the solution supported at the IRT meeting last week. (see email below) I believe we now have a good policy that is aligned with all 34 recommendations we will work together to implement. EPDP Phase 1 recommendations (29) May 2019 EPDP Phase 2 Priority 2 Recommendations (4) June 2021 Supplemental Recommendation (1) March 2022 As we discussed at our last IRT meeting, we don’t plan on more IRT meetings before we publish our policy in August 2023. We’ll notify you of the publication date after we have coordinated with our publication team. We may have more IRT meetings after we publish to coordinate and collaborate our implementation, but that decision will come later. For now, we will focus on getting this policy published. If you have questions or comments, I request they be submitted in separate emails with Subject line defining the topic. It will help us to collect the information as we address them together. Thank you all once again and I hope you all support the attached policy language for publication and implementation. Gratefully your, Dennis Chang From: "IRT.RegDataPolicy" <irt.regdatapolicy-bounces@icann.org> on behalf of "Dennis Chang via IRT.RegDataPolicy" <irt.regdatapolicy@icann.org> Reply-To: Dennis Chang <dennis.chang@icann.org> Date: Friday, July 21, 2023 at 8:40 AM To: "irt.regdatapolicy@icann.org" <irt.regdatapolicy@icann.org> Subject: Re: [IRT.RegDataPolicy] RegData IRT Good News. Urgent Request requirement. IRT supported solution found! Dear IRT, If you haven’t heard already, we did it! We found a solution to Urgent Request supported by IRT at our 90 minutes focused working session this week. Thank you so much for not giving up and working as a team to find this solution. It was impressive to see people still listening to one another, appreciating the different views, and truly collaborating to build on ideas to find the compromised solution. A great demonstration of One Team against the problem. What was that solution? * 24 hours. Respond in 24 hours with the info or an explanation for more time needed. * 2 Business Days. No more than 2 Business Days to Respond. How did this happen? First, thanks to Roger and RrSG for the planting the seed with using both 24 hours and 2 business days in the solution. Instead of outright rejecting it, Laureen and others suggested that we build on it. Thomas came in with a key ingredient – the explanation. Initially, we discussed all the options but created this new one listening to the “interest” behind the positions. Business Days was important because of the business realities in various regions around the world. While Calendar Days sets global time consistency, the team agreed that cultural sensitivity to regions was more important. The dread of “silence” with undetermined timeline using “Business Days” was solved with the promise of a response in 24 hours with an explanation. Thanks to Gabriel expressing the “dread” so eloquently. Overall, it was an exciting finale overcoming the toughest challenge for us. As promised, we’ll draft the policy language using the IRT supported requirements and comeback to you, but I wanted to send you this quick note to express my sincere gratitude for wonderfully responding. I thank those guests that joined to support us too. I noted Ashley, RrSG Chair and Becky, ICANN Board and others supporting us behind the scenes. Please convey our sincere appreciation to your team back home too. THANK YOU! Dennis S. Chang GDD Programs Director Phone: +1 213 293 7889 Sykpe: dennisSchang www.icann.org<http://www.icann.org/> One World – One Internet ******************** CAUTION: This email originated from outside the organization. Do not click links unless you can confirm the sender and know the content is safe. ******************** _______________________________________________ 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.
Please consider my last email to also comprise a response to your earlier email requesting proposed revisions by 8/2. Kind regards, Laureen Kapin Assistant Director International Consumer Protection Federal Trade Commission Sent via mobile phone Please excuse unintended autocorrect outcomes ________________________________ From: IRT.RegDataPolicy <irt.regdatapolicy-bounces@icann.org> on behalf of Kapin, Laureen via IRT.RegDataPolicy <irt.regdatapolicy@icann.org> Sent: Monday, July 31, 2023 7:21:32 PM Cc: irt.regdatapolicy@icann.org <irt.regdatapolicy@icann.org> Subject: Re: [IRT.RegDataPolicy] Concerns that proposed solution does not match 7/19 discussion RE: Review RegData complete draft Re: Good News. Urgent Request. IRT supported solution found! Hi Owen, I appreciate your input and agree with you on several points. I believe that there is good intent in the IRT to find a compromise here. I also agree that our goal is to implement the Phase 1 policy, not develop new policy. Simply stated, I think that there was a mismatch between the compromise described during the call and the proffered IRT language. I participated in the last call and reviewed the recordings and there was not discussion of a three-business day ceiling. The GAC expressed concerns about lengthy timelines in its public comment in the first place and the proffered IRT language maintains the original ceiling of three business days. However, during our last call we focused on a ceiling of two business days. I propose the following text to ensure that we implement the compromise discussed on the call which involved the “without undue delay, generally 24 hours” and the opportunity to request extensions of up to two business days: 10.6. For Urgent Requests for Lawful Disclosure, Registrar and Registry Operator MUST respond, as defined in Section 10.7, without undue delay, generally within 24 hours of receipt. 10.6.1. If Registrar or Registry Operator cannot respond to an Urgent Request for Lawful Disclosure within 24 hours, it MUST notify the requestor within 24 hours of receipt of an Urgent Request for Lawful Disclosure of the need for an extension to respond. 10.6.2 Registrar or Registry Operator’s extension notification to the requestor MUST include (a) confirmation that it has reviewed and considered the Urgent Request for Lawful Disclosure on its merits and determined additional time to respond is needed, (b) rationale for why additional time is needed (including if a request is complex or the Registrar or Registry Operator received a large number of requests), and (c) the time frame it will respond, as required by Section 10.7, which cannot exceed two (2) business days from the time of the initial receipt of the request. For context, here is what ICANN Org offered after it assessed the public comments: 10.6. For Urgent Requests for Lawful Disclosure, Registrar and Registry Operator MUST acknowledge and respond without undue delay, but no more than 24 hours from receipt. If responding to an Urgent Request for Lawful Disclosure is complex, or a large number are received by Registrar or Registry Operator, it MAY extend the time for response up to an additional one (1) business day from the date of receipt of the Urgent Request for Lawful Disclosure, provided it gives notice to the requestor within the initial 24 hour period and explains the need for an extension of time. This construct shows that original structure comprised an initial period and one additional opportunity for an extension, not two. I ask that folks review the recordings and then seriously consider this PSWG revision. We believe it is faithful to the compromise reached during the call. Kind regards, Laureen Kapin Assistant Director for International Consumer Protection Office of International Affairs Federal Trade Commission lkapin@ftc.gov From: Owen Smigelski <owen.smigelski@namecheap.com> Sent: Wednesday, July 26, 2023 1:17 PM To: Kapin, Laureen <LKAPIN@ftc.gov> Cc: Dennis Chang <dennis.chang@icann.org>; irt.regdatapolicy@icann.org Subject: Re: [IRT.RegDataPolicy] Concerns that proposed solution does not match 7/19 discussion RE: Review RegData complete draft Re: Good News. Urgent Request. IRT supported solution found! Hi Laureen, Although I did not attend the last IRT meeting, I have been in close consultation with my registrar colleagues. It needs to be made clear that this was a REAL compromise for registrars as it allows taking additional time to respond if necessary. Conducting the balancing test is not as simple as reviewing an abuse complaint (as many have repeatedly explained), and the penalties of improper disclosure are significant. We thus need the flexibility if certain situations require more than 24 hours. Getting rid of the previously agreed upon text of one business day puts us back in a situation where there is no compromise and the registrars will not be able to accept what was agreed to last week. On behalf of the RrSG, I would formally like to raise the concern that it appears that the IRT is being used to develop policy rather than implement recommendations. Others have expressed this concern, and the registrars support efforts to ensure that the final policy aligns with the recommendations. Regards, Owen On Jul 25, 2023, at 11:34, Kapin, Laureen via IRT.RegDataPolicy <irt.regdatapolicy@icann.org> wrote: CAUTION: This email originated from outside the organization. Do not click links unless you can confirm the sender and know the content is safe. Dear Dennis and colleagues, We appreciate the effort the IRT members and staff have taken to get us to this point. I was very grateful for thoughtfulness and flexibility demonstrated during the call. Nevertheless, the Public Safety Working Group colleagues on the 7/19/23 call (myself, Chris, and Gabe) don’t think the current draft has accurately captured the agreement reached during our discussion because it identifies two separate timelines for extensions of time to respond to urgent requests. I understood our discussion as creating a unified timeline for most requests (“without undue delay, generally within 24 hours”) and then a single opportunity to for an up-to-2 business day extension. The circulated version creates two opportunities and timelines for an extension and creates the potential for a longer total timeline to respond (now 3 business days). I reviewed the recording (most relevant part starts at minute 50) and believe it supports my understanding, particularly Thomas’s distillation of the key components of our agreement toward the end of the discussion. I note that part of the misunderstanding seems to have arisen because the current version, for the first time, separates out the timeline for urgent requests into three separate subsections. The public comment version for urgent requests was set forth in its entirety in10.6. Org’s changes to this provision after the public comment period were also set forth in their entirety in 10.6. These were never broken out or considered as stand-alone components of the urgent request timeline. They were only broken out and separated in the version circulated yesterday. Our 7/19 discussion was focused on the entirety of the timeline to respond and setting a ceiling or limit on the response time. The PSWG participants did not view the discussion as just focusing on a partial ceiling that could be extended not one but two times for a total of three business days. Regarding a ceiling for response times, such a result would put us in a worse position than what Dennis had recently proposed (3 calendar days). For clarity, I think 10.6. and 10.6.1 accurately sets forth our discussion: 10.6. For Urgent Requests for Lawful Disclosure, Registrar and Registry Operator MUST respond, as defined in Section 10.7, without undue delay, generally within 24 hours of receipt. 10.6.1. If Registrar or Registry Operator cannot respond to an Urgent Request for Lawful Disclosure within 24 hours, it MUST notify the requestor within 24 hours of receipt of an Urgent Request for Lawful Disclosure of the need for an extension to respond. Registrar or Registry Operator’s extension notification to the requestor MUST include (a) confirmation that it has reviewed and considered the Urgent Request for Lawful Disclosure on its merits and determined additional time to respond is needed, (b) rationale for why additional time is needed, and (c) the time frame it will respond, as required by Section 10.7, which cannot exceed two (2) business days from the time of the initial receipt of the request. However, I don’t recall that we discussed an additional amount of time beyond the two-business day total response time. Indeed, I thought the whole goal of our discussion was to create a single ceiling beyond the “without undue delay,” generally w/in 24 hours, which we ultimately agreed would expire at 2 business days from receipt. So, I was surprised to see 10.6.2: 10.6.2. In addition to the extension provided for in Section 10.6.1, if responding to an Urgent Request for Lawful Disclosure is complex, or a large number of requests are received by Registrar or Registry Operator, it MAY extend the time for response up to an additional one (1) business day provided it notifies the requestor within (2) business days from the time of the initial receipt of the request of the updated time frame to respond explaining the need for an additional extension of time. The reason that I’m concerned is that we’re now back to a scenario where urgent requests could take three business days to respond to which is what the GAC objected to in its public comment as inconsistent with the nature of an “urgent” request. I think this needs further discussion because I don’t think the current draft accurately reflects what we discussed on 7/19. My suggestion would be to either: 1. Delete 10.6.2 or 2. Add the concepts of “complex” and “large number” to 10.6.1 as part of the rationale that may be shared to justify an extension of time to respond to an urgent request. I suggest that we need an additional call unless this can be resolved via email. 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 Dennis Chang via IRT.RegDataPolicy Sent: Monday, July 24, 2023 5:24 PM To: irt.regdatapolicy@icann.org Subject: [IRT.RegDataPolicy] Review RegData complete draft Re: Good News. Urgent Request. IRT supported solution found! Dear IRT, Attached is a completed draft of the Registration Data Policy including the last two outstanding sections. Section 4.0: Policy Effective Date reflecting the 6+12 plan for the 18-month implementation timeline. Section 10.6: Urgent Request reflecting the solution supported at the IRT meeting last week. (see email below) I believe we now have a good policy that is aligned with all 34 recommendations we will work together to implement. EPDP Phase 1 recommendations (29) May 2019 EPDP Phase 2 Priority 2 Recommendations (4) June 2021 Supplemental Recommendation (1) March 2022 As we discussed at our last IRT meeting, we don’t plan on more IRT meetings before we publish our policy in August 2023. We’ll notify you of the publication date after we have coordinated with our publication team. We may have more IRT meetings after we publish to coordinate and collaborate our implementation, but that decision will come later. For now, we will focus on getting this policy published. If you have questions or comments, I request they be submitted in separate emails with Subject line defining the topic. It will help us to collect the information as we address them together. Thank you all once again and I hope you all support the attached policy language for publication and implementation. Gratefully your, Dennis Chang From: "IRT.RegDataPolicy" <irt.regdatapolicy-bounces@icann.org> on behalf of "Dennis Chang via IRT.RegDataPolicy" <irt.regdatapolicy@icann.org> Reply-To: Dennis Chang <dennis.chang@icann.org> Date: Friday, July 21, 2023 at 8:40 AM To: "irt.regdatapolicy@icann.org" <irt.regdatapolicy@icann.org> Subject: Re: [IRT.RegDataPolicy] RegData IRT Good News. Urgent Request requirement. IRT supported solution found! Dear IRT, If you haven’t heard already, we did it! We found a solution to Urgent Request supported by IRT at our 90 minutes focused working session this week. Thank you so much for not giving up and working as a team to find this solution. It was impressive to see people still listening to one another, appreciating the different views, and truly collaborating to build on ideas to find the compromised solution. A great demonstration of One Team against the problem. What was that solution? * 24 hours. Respond in 24 hours with the info or an explanation for more time needed. * 2 Business Days. No more than 2 Business Days to Respond. How did this happen? First, thanks to Roger and RrSG for the planting the seed with using both 24 hours and 2 business days in the solution. Instead of outright rejecting it, Laureen and others suggested that we build on it. Thomas came in with a key ingredient – the explanation. Initially, we discussed all the options but created this new one listening to the “interest” behind the positions. Business Days was important because of the business realities in various regions around the world. While Calendar Days sets global time consistency, the team agreed that cultural sensitivity to regions was more important. The dread of “silence” with undetermined timeline using “Business Days” was solved with the promise of a response in 24 hours with an explanation. Thanks to Gabriel expressing the “dread” so eloquently. Overall, it was an exciting finale overcoming the toughest challenge for us. As promised, we’ll draft the policy language using the IRT supported requirements and comeback to you, but I wanted to send you this quick note to express my sincere gratitude for wonderfully responding. I thank those guests that joined to support us too. I noted Ashley, RrSG Chair and Becky, ICANN Board and others supporting us behind the scenes. Please convey our sincere appreciation to your team back home too. THANK YOU! Dennis S. Chang GDD Programs Director Phone: +1 213 293 7889 Sykpe: dennisSchang www.icann.org<http://www.icann.org/> One World – One Internet ******************** CAUTION: This email originated from outside the organization. Do not click links unless you can confirm the sender and know the content is safe. ******************** _______________________________________________ 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.
Simply stated, I think that there was a mismatch between the compromise described during the call and the proffered IRT language. I participated in the last call and reviewed the recordings and there was not discussion of a three-business day ceiling. The GAC expressed concerns about lengthy timelines in its public comment in the first place and the proffered IRT language maintains the original ceiling of three business days. However, during our last call we focused on a ceiling of two business days.
No mismatch, it was simply the discussion of what was being considered, and there was no discussion whatsoever of complex requests.
I propose the following text to ensure that we implement the compromise discussed on the call which involved the “without undue delay, generally 24 hours” and the opportunity to request extensions of up to two business days:
10.6. For Urgent Requests for Lawful Disclosure, Registrar and Registry Operator MUST respond, as defined in Section 10.7, without undue delay, generally within 24 hours of receipt.
10.6.1. If Registrar or Registry Operator cannot respond to an Urgent Request for Lawful Disclosure within 24 hours, it MUST notify the requestor within 24 hours of receipt of an Urgent Request for Lawful Disclosure of the need for an extension to respond.
10.6.2 Registrar or Registry Operator’s extension notification to the requestor MUST include (a) confirmation that it has reviewed and considered the Urgent Request for Lawful Disclosure on its merits and determined additional time to respond is needed, (b) rationale for why additional time is needed (including if a request is complex or the Registrar or Registry Operator received a large number of requests), and (c) the time frame it will respond, as required by Section 10.7, which cannot exceed two (2) business days from the time of the initial receipt of the request.
Which is just to say that complex requests take the same time as a simple request. This just tries to deny reality.
For context, here is what ICANN Org offered after it assessed the public comments:
10.6. For Urgent Requests for Lawful Disclosure, Registrar and Registry Operator MUST acknowledge and respond without undue delay, but no more than 24 hours from receipt. If responding to an Urgent Request for Lawful Disclosure is complex, or a large number are received by Registrar or Registry Operator, it MAY extend the time for response up to an additional one (1) business day from the date of receipt of the Urgent Request for Lawful Disclosure, provided it gives notice to the requestor within the initial 24 hour period and explains the need for an extension of time.
That offer had 0 chance of ever making it into policy, as I mentioned several times. So this comparison is just moot. I’m sorry if IPT offered PSWG a pony to later find they couldn’t deliver on it, but it’s possibly something to tackle directly with them, instead of coming back regularly to this language.
This construct shows that original structure comprised an initial period and one additional opportunity for an extension, not two.
I believe the two extensions is an interpretation that I believe was not the intent of the drafters of this language, so I don’t mind clarifying the language for it to clearly show whether is one extension after another, or a possible series of extensions properly justified, as long as the allowed time factors the complexity of the request. At the end of the day, a complex request needs more time to both have its lawfulness assed and when green lit by legal, to be executed by operations. That is the total time that needs to be 3 business days in this case. If I was on the requester side, I would prefer allowing more extensions in order to minimize the average response time, which is more in the Agile philosophy of software product development. But if predictability is a stronger value to requesters, even if it ends up increasing the actual time it takes, then a single extension is what makes sense.
I ask that folks review the recordings and then seriously consider this PSWG revision. We believe it is faithful to the compromise reached during the call.
Answered above both why this was not te case during the call and why this suggestion still deviates from policy. Rubens
Hello IRT Team, I am ready to accept the compromise that was reached at our last meeting which is documented in the version of the Policy that ICANN published on July 24. The relevant text both before and after the public comment period included an initial review period (always without undue delay, but maximum 2 business days pre-public-comment or 24 hours post-public comment) and then a possible extension period if responding is complex or there is a large volume of requests. The meeting discussion focused on the initial review period. I did not take this to mean that we were removing the possible extension period, but rather that it was not relevant to the conversation at hand. I did include that part of the text in the Zoom chat towards the end of the meeting when I shared my understanding of the language being discussed. Responding parties will treat urgent requests with appropriately prompt and serious consideration, but should not be required to rush the process or hire on additional legal staff to process requests within an unreasonably short turnaround time. There are structures in place for exigent circumstances, and otherwise due process must be respected. I hope we can finalize our work with the text presented on July 24, or return to the 2 business days version that had agreement before the public comment period. Thank you, -- Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/they swyld@tucows.com From: Kapin, Laureen via IRT.RegDataPolicy Sent: July 31, 2023 10:22 PM Cc: irt.regdatapolicy@icann.org Subject: Re: [IRT.RegDataPolicy] Concerns that proposed solution does notmatch 7/19 discussion RE: Review RegData complete draft Re: Good News.Urgent Request. IRT supported solution found! Hi Owen, I appreciate your input and agree with you on several points. I believe that there is good intent in the IRT to find a compromise here. I also agree that our goal is to implement the Phase 1 policy, not develop new policy. Simply stated, I think that there was a mismatch between the compromise described during the call and the proffered IRT language. I participated in the last call and reviewed the recordings and there was not discussion of a three-business day ceiling. The GAC expressed concerns about lengthy timelines in its public comment in the first place and the proffered IRT language maintains the original ceiling of three business days. However, during our last call we focused on a ceiling of two business days. I propose the following text to ensure that we implement the compromise discussed on the call which involved the “without undue delay, generally 24 hours” and the opportunity to request extensions of up to two business days: 10.6. For Urgent Requests for Lawful Disclosure, Registrar and Registry Operator MUST respond, as defined in Section 10.7, without undue delay, generally within 24 hours of receipt. 10.6.1. If Registrar or Registry Operator cannot respond to an Urgent Request for Lawful Disclosure within 24 hours, it MUST notify the requestor within 24 hours of receipt of an Urgent Request for Lawful Disclosure of the need for an extension to respond. 10.6.2 Registrar or Registry Operator’s extension notification to the requestor MUST include (a) confirmation that it has reviewed and considered the Urgent Request for Lawful Disclosure on its merits and determined additional time to respond is needed, (b) rationale for why additional time is needed (including if a request is complex or the Registrar or Registry Operator received a large number of requests), and (c) the time frame it will respond, as required by Section 10.7, which cannot exceed two (2) business days from the time of the initial receipt of the request. For context, here is what ICANN Org offered after it assessed the public comments: 10.6. For Urgent Requests for Lawful Disclosure, Registrar and Registry Operator MUST acknowledge and respond without undue delay, but no more than 24 hours from receipt. If responding to an Urgent Request for Lawful Disclosure is complex, or a large number are received by Registrar or Registry Operator, it MAY extend the time for response up to an additional one (1) business day from the date of receipt of the Urgent Request for Lawful Disclosure, provided it gives notice to the requestor within the initial 24 hour period and explains the need for an extension of time. This construct shows that original structure comprised an initial period and one additional opportunity for an extension, not two. I ask that folks review the recordings and then seriously consider this PSWG revision. We believe it is faithful to the compromise reached during the call. Kind regards, Laureen Kapin Assistant Director for International Consumer Protection Office of International Affairs Federal Trade Commission lkapin@ftc.gov From: Owen Smigelski <owen.smigelski@namecheap.com> Sent: Wednesday, July 26, 2023 1:17 PM To: Kapin, Laureen <LKAPIN@ftc.gov> Cc: Dennis Chang <dennis.chang@icann.org>; irt.regdatapolicy@icann.org Subject: Re: [IRT.RegDataPolicy] Concerns that proposed solution does not match 7/19 discussion RE: Review RegData complete draft Re: Good News. Urgent Request. IRT supported solution found! Hi Laureen, Although I did not attend the last IRT meeting, I have been in close consultation with my registrar colleagues. It needs to be made clear that this was a REAL compromise for registrars as it allows taking additional time to respond if necessary. Conducting the balancing test is not as simple as reviewing an abuse complaint (as many have repeatedly explained), and the penalties of improper disclosure are significant. We thus need the flexibility if certain situations require more than 24 hours. Getting rid of the previously agreed upon text of one business day puts us back in a situation where there is no compromise and the registrars will not be able to accept what was agreed to last week. On behalf of the RrSG, I would formally like to raise the concern that it appears that the IRT is being used to develop policy rather than implement recommendations. Others have expressed this concern, and the registrars support efforts to ensure that the final policy aligns with the recommendations. Regards, Owen On Jul 25, 2023, at 11:34, Kapin, Laureen via IRT.RegDataPolicy <irt.regdatapolicy@icann.org> wrote: CAUTION: This email originated from outside the organization. Do not click links unless you can confirm the sender and know the content is safe. Dear Dennis and colleagues, We appreciate the effort the IRT members and staff have taken to get us to this point. I was very grateful for thoughtfulness and flexibility demonstrated during the call. Nevertheless, the Public Safety Working Group colleagues on the 7/19/23 call (myself, Chris, and Gabe) don’t think the current draft has accurately captured the agreement reached during our discussion because it identifies two separate timelines for extensions of time to respond to urgent requests. I understood our discussion as creating a unified timeline for most requests (“without undue delay, generally within 24 hours”) and then a single opportunity to for an up-to-2 business day extension. The circulated version creates two opportunities and timelines for an extension and creates the potential for a longer total timeline to respond (now 3 business days). I reviewed the recording (most relevant part starts at minute 50) and believe it supports my understanding, particularly Thomas’s distillation of the key components of our agreement toward the end of the discussion. I note that part of the misunderstanding seems to have arisen because the current version, for the first time, separates out the timeline for urgent requests into three separate subsections. The public comment version for urgent requests was set forth in its entirety in10.6. Org’s changes to this provision after the public comment period were also set forth in their entirety in 10.6. These were never broken out or considered as stand-alone components of the urgent request timeline. They were only broken out and separated in the version circulated yesterday. Our 7/19 discussion was focused on the entirety of the timeline to respond and setting a ceiling or limit on the response time. The PSWG participants did not view the discussion as just focusing on a partial ceiling that could be extended not one but two times for a total of three business days. Regarding a ceiling for response times, such a result would put us in a worse position than what Dennis had recently proposed (3 calendar days). For clarity, I think 10.6. and 10.6.1 accurately sets forth our discussion: 10.6. For Urgent Requests for Lawful Disclosure, Registrar and Registry Operator MUST respond, as defined in Section 10.7, without undue delay, generally within 24 hours of receipt. 10.6.1. If Registrar or Registry Operator cannot respond to an Urgent Request for Lawful Disclosure within 24 hours, it MUST notify the requestor within 24 hours of receipt of an Urgent Request for Lawful Disclosure of the need for an extension to respond. Registrar or Registry Operator’s extension notification to the requestor MUST include (a) confirmation that it has reviewed and considered the Urgent Request for Lawful Disclosure on its merits and determined additional time to respond is needed, (b) rationale for why additional time is needed, and (c) the time frame it will respond, as required by Section 10.7, which cannot exceed two (2) business days from the time of the initial receipt of the request. However, I don’t recall that we discussed an additional amount of time beyond the two-business day total response time. Indeed, I thought the whole goal of our discussion was to create a single ceiling beyond the “without undue delay,” generally w/in 24 hours, which we ultimately agreed would expire at 2 business days from receipt. So, I was surprised to see 10.6.2: 10.6.2. In addition to the extension provided for in Section 10.6.1, if responding to an Urgent Request for Lawful Disclosure is complex, or a large number of requests are received by Registrar or Registry Operator, it MAY extend the time for response up to an additional one (1) business day provided it notifies the requestor within (2) business days from the time of the initial receipt of the request of the updated time frame to respond explaining the need for an additional extension of time. The reason that I’m concerned is that we’re now back to a scenario where urgent requests could take three business days to respond to which is what the GAC objected to in its public comment as inconsistent with the nature of an “urgent” request. I think this needs further discussion because I don’t think the current draft accurately reflects what we discussed on 7/19. My suggestion would be to either: 1. Delete 10.6.2 or 2. Add the concepts of “complex” and “large number” to 10.6.1 as part of the rationale that may be shared to justify an extension of time to respond to an urgent request. I suggest that we need an additional call unless this can be resolved via email. 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 Dennis Chang via IRT.RegDataPolicy Sent: Monday, July 24, 2023 5:24 PM To: irt.regdatapolicy@icann.org Subject: [IRT.RegDataPolicy] Review RegData complete draft Re: Good News. Urgent Request. IRT supported solution found! Dear IRT, Attached is a completed draft of the Registration Data Policy including the last two outstanding sections. Section 4.0: Policy Effective Date reflecting the 6+12 plan for the 18-month implementation timeline. Section 10.6: Urgent Request reflecting the solution supported at the IRT meeting last week. (see email below) I believe we now have a good policy that is aligned with all 34 recommendations we will work together to implement. EPDP Phase 1 recommendations (29) May 2019 EPDP Phase 2 Priority 2 Recommendations (4) June 2021 Supplemental Recommendation (1) March 2022 As we discussed at our last IRT meeting, we don’t plan on more IRT meetings before we publish our policy in August 2023. We’ll notify you of the publication date after we have coordinated with our publication team. We may have more IRT meetings after we publish to coordinate and collaborate our implementation, but that decision will come later. For now, we will focus on getting this policy published. If you have questions or comments, I request they be submitted in separate emails with Subject line defining the topic. It will help us to collect the information as we address them together. Thank you all once again and I hope you all support the attached policy language for publication and implementation. Gratefully your, Dennis Chang From: "IRT.RegDataPolicy" <irt.regdatapolicy-bounces@icann.org> on behalf of "Dennis Chang via IRT.RegDataPolicy" <irt.regdatapolicy@icann.org> Reply-To: Dennis Chang <dennis.chang@icann.org> Date: Friday, July 21, 2023 at 8:40 AM To: "irt.regdatapolicy@icann.org" <irt.regdatapolicy@icann.org> Subject: Re: [IRT.RegDataPolicy] RegData IRT Good News. Urgent Request requirement. IRT supported solution found! Dear IRT, If you haven’t heard already, we did it! We found a solution to Urgent Request supported by IRT at our 90 minutes focused working session this week. Thank you so much for not giving up and working as a team to find this solution. It was impressive to see people still listening to one another, appreciating the different views, and truly collaborating to build on ideas to find the compromised solution. A great demonstration of One Team against the problem. What was that solution? • 24 hours. Respond in 24 hours with the info or an explanation for more time needed. • 2 Business Days. No more than 2 Business Days to Respond. How did this happen? First, thanks to Roger and RrSG for the planting the seed with using both 24 hours and 2 business days in the solution. Instead of outright rejecting it, Laureen and others suggested that we build on it. Thomas came in with a key ingredient – the explanation. Initially, we discussed all the options but created this new one listening to the “interest” behind the positions. Business Days was important because of the business realities in various regions around the world. While Calendar Days sets global time consistency, the team agreed that cultural sensitivity to regions was more important. The dread of “silence” with undetermined timeline using “Business Days” was solved with the promise of a response in 24 hours with an explanation. Thanks to Gabriel expressing the “dread” so eloquently. Overall, it was an exciting finale overcoming the toughest challenge for us. As promised, we’ll draft the policy language using the IRT supported requirements and comeback to you, but I wanted to send you this quick note to express my sincere gratitude for wonderfully responding. I thank those guests that joined to support us too. I noted Ashley, RrSG Chair and Becky, ICANN Board and others supporting us behind the scenes. Please convey our sincere appreciation to your team back home too. THANK YOU! Dennis S. Chang GDD Programs Director Phone: +1 213 293 7889 Sykpe: dennisSchang www.icann.org One World – One Internet ******************** CAUTION: This email originated from outside the organization. Do not click links unless you can confirm the sender and know the content is safe. ******************** _______________________________________________ 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.
Sarah, With respect, I haven't been able to find the substance behind, "There are structures in place for exigent circumstances." When I asked, the responses from Gabe and Laureen seemed to suggest the opposite, i.e. no actual structure, process, order, etc. Steve On Tue, Aug 1, 2023 at 9:26 AM Sarah Wyld via IRT.RegDataPolicy < irt.regdatapolicy@icann.org> wrote:
Hello IRT Team,
I am ready to accept the compromise that was reached at our last meeting which is documented in the version of the Policy that ICANN published on July 24.
The relevant text both before and after the public comment period included an initial review period (always without undue delay, but maximum 2 business days pre-public-comment or 24 hours post-public comment) and then a possible extension period if responding is complex or there is a large volume of requests.
The meeting discussion focused on the initial review period. I did not take this to mean that we were removing the possible extension period, but rather that it was not relevant to the conversation at hand. I did include that part of the text in the Zoom chat towards the end of the meeting when I shared my understanding of the language being discussed.
Responding parties will treat urgent requests with appropriately prompt and serious consideration, but should not be required to rush the process or hire on additional legal staff to process requests within an unreasonably short turnaround time. There are structures in place for exigent circumstances, and otherwise due process must be respected.
I hope we can finalize our work with the text presented on July 24, or return to the 2 business days version that had agreement before the public comment period.
Thank you,
--
*Sarah Wyld*, CIPP/E
Policy & Privacy Manager
Pronouns: she/they
swyld@tucows.com
*From: *Kapin, Laureen via IRT.RegDataPolicy <irt.regdatapolicy@icann.org> *Sent: *July 31, 2023 10:22 PM *Cc: *irt.regdatapolicy@icann.org *Subject: *Re: [IRT.RegDataPolicy] Concerns that proposed solution does notmatch 7/19 discussion RE: Review RegData complete draft Re: Good News.Urgent Request. IRT supported solution found!
Hi Owen,
I appreciate your input and agree with you on several points. I believe that there is good intent in the IRT to find a compromise here. I also agree that our goal is to implement the Phase 1 policy, not develop new policy.
Simply stated, I think that there was a mismatch between the compromise described during the call and the proffered IRT language. I participated in the last call *and *reviewed the recordings and there was not discussion of a three-business day ceiling. The GAC expressed concerns about lengthy timelines in its public comment in the first place and the proffered IRT language maintains the original ceiling of three business days. However, during our last call we focused on a ceiling of two business days.
I propose the following text to ensure that we implement the compromise discussed on the call which involved the “without undue delay, generally 24 hours” and the opportunity to request extensions of up to two business days:
10.6. For Urgent Requests for Lawful Disclosure, Registrar and Registry Operator
MUST respond, as defined in Section 10.7, without undue delay, generally within
24 hours of receipt.
10.6.1. If Registrar or Registry Operator cannot respond to an Urgent Request for Lawful Disclosure within 24 hours, it MUST notify the requestor within 24 hours of receipt of an Urgent Request for Lawful Disclosure of the need for an extension to respond.
10.6.2 Registrar or Registry Operator’s extension notification to the requestor MUST include (a) confirmation that it has reviewed and considered the Urgent Request for Lawful Disclosure on its merits and determined additional time to respond is needed, (b) rationale for why additional time is needed (including if a request is complex or the Registrar or Registry Operator received a large number of requests), and (c) the time frame it will respond, as required by Section 10.7, which cannot exceed two (2) business days from the time of the initial receipt of the request.
For context, here is what ICANN Org offered after it assessed the public comments:
10.6. For Urgent Requests for Lawful Disclosure, Registrar and Registry Operator
MUST acknowledge and respond without undue delay, but no more than 24
hours from receipt. If responding to an Urgent Request for Lawful Disclosure is
complex, or a large number are received by Registrar or Registry Operator, it
MAY extend the time for response up to an additional one (1) business day from
the date of receipt of the Urgent Request for Lawful Disclosure, provided it gives
notice to the requestor within the initial 24 hour period and explains the need for
an extension of time.
This construct shows that original structure comprised an initial period and one additional opportunity for an extension, not two.
I ask that folks review the recordings and then seriously consider this PSWG revision. We believe it is faithful to the compromise reached during the call.
Kind regards,
Laureen Kapin
Assistant Director for International Consumer Protection
Office of International Affairs
Federal Trade Commission
lkapin@ftc.gov
*From:* Owen Smigelski <owen.smigelski@namecheap.com> *Sent:* Wednesday, July 26, 2023 1:17 PM *To:* Kapin, Laureen <LKAPIN@ftc.gov> *Cc:* Dennis Chang <dennis.chang@icann.org>; irt.regdatapolicy@icann.org *Subject:* Re: [IRT.RegDataPolicy] Concerns that proposed solution does not match 7/19 discussion RE: Review RegData complete draft Re: Good News. Urgent Request. IRT supported solution found!
Hi Laureen,
Although I did not attend the last IRT meeting, I have been in close consultation with my registrar colleagues.
It needs to be made clear that this was a *REAL* compromise for registrars as it allows taking additional time to respond if necessary. Conducting the balancing test is not as simple as reviewing an abuse complaint (as many have repeatedly explained), and the penalties of improper disclosure are significant. We thus need the flexibility if certain situations require more than 24 hours.
Getting rid of the previously agreed upon text of one business day puts us back in a situation where there is no compromise and the registrars will not be able to accept what was agreed to last week.
On behalf of the RrSG, I would formally like to raise the concern that it appears that the IRT is being used to develop policy rather than implement recommendations. Others have expressed this concern, and the registrars support efforts to ensure that the final policy aligns with the recommendations.
Regards,
Owen
On Jul 25, 2023, at 11:34, Kapin, Laureen via IRT.RegDataPolicy < irt.regdatapolicy@icann.org> wrote:
*CAUTION: **This email originated from outside the organization. Do not click links unless you can confirm the sender and know the content is safe.*
Dear Dennis and colleagues,
We appreciate the effort the IRT members and staff have taken to get us to this point. I was very grateful for thoughtfulness and flexibility demonstrated during the call. Nevertheless, the Public Safety Working Group colleagues on the 7/19/23 call (myself, Chris, and Gabe) don’t think the current draft has accurately captured the agreement reached during our discussion because it identifies two separate timelines for extensions of time to respond to urgent requests. I understood our discussion as creating a unified timeline for most requests (“without undue delay, generally within 24 hours”) and then a *single* opportunity to for an up-to-2 business day extension. The circulated version creates *two *opportunities and timelines for an extension and creates the potential for a longer total timeline to respond (now *3 *business days).
I reviewed the recording (most relevant part starts at minute 50) and believe it supports my understanding, particularly Thomas’s distillation of the key components of our agreement toward the end of the discussion.
I note that part of the misunderstanding seems to have arisen because the current version, for the first time, separates out the timeline for urgent requests into three separate subsections. The public comment version for urgent requests was set forth in its entirety in10.6. Org’s changes to this provision after the public comment period were also set forth in their entirety in 10.6. These were never broken out or considered as stand-alone components of the urgent request timeline. They were only broken out and separated in the version circulated yesterday.
Our 7/19 discussion was focused on the entirety of the timeline to respond and setting a ceiling or limit on the response time. The PSWG participants did not view the discussion as just focusing on a partial ceiling that could be extended not one but two times for a total of three business days. Regarding a ceiling for response times, such a result would put us in a worse position than what Dennis had recently proposed (3 calendar days).
For clarity, I think 10.6. and 10.6.1 accurately sets forth our discussion:
10.6. For Urgent Requests for Lawful Disclosure, Registrar and Registry Operator
MUST respond, as defined in Section 10.7, without undue delay, generally within
24 hours of receipt.
10.6.1. If Registrar or Registry Operator cannot respond to an Urgent Request for
Lawful Disclosure within 24 hours, it MUST notify the requestor within 24
hours of receipt of an Urgent Request for Lawful Disclosure of the need
for an extension to respond. Registrar or Registry Operator’s extension
notification to the requestor MUST include (a) confirmation that it has
reviewed and considered the Urgent Request for Lawful Disclosure on its
merits and determined additional time to respond is needed, (b) rationale
for why additional time is needed, and (c) the time frame it will respond,
as required by Section 10.7, which cannot exceed two (2) business days
from the time of the initial receipt of the request.
However, I don’t recall that we discussed an additional amount of time beyond the two-business day total response time. Indeed, I thought the whole goal of our discussion was to create a single ceiling beyond the “without undue delay,” generally w/in 24 hours, which we ultimately agreed would expire at 2 business days from receipt. So, I was surprised to see 10.6.2:
10.6.2. In addition to the extension provided for in Section 10.6.1, if responding to
an Urgent Request for Lawful Disclosure is complex, or a large number of
requests are received by Registrar or Registry Operator, it MAY extend
the time for response up to an additional one (1) business day provided it
notifies the requestor within (2) business days from the time of the initial
receipt of the request of the updated time frame to respond explaining the
need for an additional extension of time.
The reason that I’m concerned is that we’re now back to a scenario where urgent requests could take three business days to respond to which is what the GAC objected to in its public comment as inconsistent with the nature of an “urgent” request.
I think this needs further discussion because I don’t think the current draft accurately reflects what we discussed on 7/19. My suggestion would be to either:
1. Delete 10.6.2 or
2. Add the concepts of “complex” and “large number” to 10.6.1 as part of the rationale that may be shared to justify an extension of time to respond to an urgent request.
I suggest that we need an additional call unless this can be resolved via email.
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 *Dennis Chang via IRT.RegDataPolicy *Sent:* Monday, July 24, 2023 5:24 PM *To:* irt.regdatapolicy@icann.org *Subject:* [IRT.RegDataPolicy] Review RegData complete draft Re: Good News. Urgent Request. IRT supported solution found!
Dear IRT,
Attached is a completed draft of the Registration Data Policy including the last two outstanding sections.
Section 4.0: Policy Effective Date reflecting the 6+12 plan for the 18-month implementation timeline.
Section 10.6: Urgent Request reflecting the solution supported at the IRT meeting last week. (see email below)
I believe we now have a good policy that is aligned with all 34 recommendations we will work together to implement.
EPDP Phase 1 recommendations (29) May 2019
EPDP Phase 2 Priority 2 Recommendations (4) June 2021
Supplemental Recommendation (1) March 2022
As we discussed at our last IRT meeting, we don’t plan on more IRT meetings before we publish our policy in August 2023.
We’ll notify you of the publication date after we have coordinated with our publication team. We may have more IRT meetings after we publish to coordinate and collaborate our implementation, but that decision will come later. For now, we will focus on getting this policy published.
If you have questions or comments, I request they be submitted in separate emails with Subject line defining the topic.
It will help us to collect the information as we address them together.
Thank you all once again and I hope you all support the attached policy language for publication and implementation.
Gratefully your,
Dennis Chang
*From: *"IRT.RegDataPolicy" <irt.regdatapolicy-bounces@icann.org> on behalf of "Dennis Chang via IRT.RegDataPolicy" < irt.regdatapolicy@icann.org> *Reply-To: *Dennis Chang <dennis.chang@icann.org> *Date: *Friday, July 21, 2023 at 8:40 AM *To: *"irt.regdatapolicy@icann.org" <irt.regdatapolicy@icann.org> *Subject: *Re: [IRT.RegDataPolicy] RegData IRT Good News. Urgent Request requirement. IRT supported solution found!
Dear IRT,
If you haven’t heard already, we did it!
We found a solution to Urgent Request supported by IRT at our 90 minutes focused working session this week.
Thank you so much for not giving up and working as a team to find this solution. It was impressive to see people still listening to one another, appreciating the different views, and truly collaborating to build on ideas to find the compromised solution. A great demonstration of One Team against the problem.
What was that solution?
- *24 hours.* Respond in 24 hours with the info or an explanation for more time needed. - *2 Business Days.* No more than 2 Business Days to Respond.
How did this happen?
First, thanks to Roger and RrSG for the planting the seed with using both 24 hours and 2 business days in the solution.
Instead of outright rejecting it, Laureen and others suggested that we build on it.
Thomas came in with a key ingredient – the explanation.
Initially, we discussed all the options but created this new one listening to the “interest” behind the positions.
Business Days was important because of the business realities in various regions around the world.
While Calendar Days sets global time consistency, the team agreed that cultural sensitivity to regions was more important.
The dread of “silence” with undetermined timeline using “Business Days” was solved with the promise of a response in 24 hours with an explanation. Thanks to Gabriel expressing the “dread” so eloquently. Overall, it was an exciting finale overcoming the toughest challenge for us.
As promised, we’ll draft the policy language using the IRT supported requirements and comeback to you, but I wanted to send you this quick note to express my sincere gratitude for wonderfully responding.
I thank those guests that joined to support us too. I noted Ashley, RrSG Chair and Becky, ICANN Board and others supporting us behind the scenes. Please convey our sincere appreciation to your team back home too.
THANK YOU!
Dennis S. Chang
GDD Programs Director
Phone: +1 213 293 7889
Sykpe: dennisSchang
www.icann.org One World – One Internet
******************** CAUTION: This email originated from outside the organization. Do not click links unless you can confirm the sender and know the content is safe. ********************
_______________________________________________ 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.
_______________________________________________ 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.
If the new compromise doesn't reach consensus, the only alternative allowed by the PDP manual is the version that reached consensus and was posted for public comment. I wonder if losing all what was allowed by others is worth pursuing more... Rubens Em 25 de jul. de 2023 15:35, em 15:35, "Kapin, Laureen via IRT.RegDataPolicy" <irt.regdatapolicy@icann.org> escreveu:
Dear Dennis and colleagues,
We appreciate the effort the IRT members and staff have taken to get us to this point. I was very grateful for thoughtfulness and flexibility demonstrated during the call. Nevertheless, the Public Safety Working Group colleagues on the 7/19/23 call (myself, Chris, and Gabe) don’t think the current draft has accurately captured the agreement reached during our discussion because it identifies two separate timelines for extensions of time to respond to urgent requests. I understood our discussion as creating a unified timeline for most requests (“without undue delay, generally within 24 hours”) and then a single opportunity to for an up-to-2 business day extension. The circulated version creates two opportunities and timelines for an extension and creates the potential for a longer total timeline to respond (now 3 business days).
I reviewed the recording (most relevant part starts at minute 50) and believe it supports my understanding, particularly Thomas’s distillation of the key components of our agreement toward the end of the discussion.
I note that part of the misunderstanding seems to have arisen because the current version, for the first time, separates out the timeline for urgent requests into three separate subsections. The public comment version for urgent requests was set forth in its entirety in10.6. Org’s changes to this provision after the public comment period were also set forth in their entirety in 10.6. These were never broken out or considered as stand-alone components of the urgent request timeline. They were only broken out and separated in the version circulated yesterday.
Our 7/19 discussion was focused on the entirety of the timeline to respond and setting a ceiling or limit on the response time. The PSWG participants did not view the discussion as just focusing on a partial ceiling that could be extended not one but two times for a total of three business days. Regarding a ceiling for response times, such a result would put us in a worse position than what Dennis had recently proposed (3 calendar days).
For clarity, I think 10.6. and 10.6.1 accurately sets forth our discussion:
10.6. For Urgent Requests for Lawful Disclosure, Registrar and Registry Operator MUST respond, as defined in Section 10.7, without undue delay, generally within 24 hours of receipt.
10.6.1. If Registrar or Registry Operator cannot respond to an Urgent Request for Lawful Disclosure within 24 hours, it MUST notify the requestor within 24 hours of receipt of an Urgent Request for Lawful Disclosure of the need for an extension to respond. Registrar or Registry Operator’s extension notification to the requestor MUST include (a) confirmation that it has reviewed and considered the Urgent Request for Lawful Disclosure on its merits and determined additional time to respond is needed, (b) rationale for why additional time is needed, and (c) the time frame it will respond, as required by Section 10.7, which cannot exceed two (2) business days from the time of the initial receipt of the request.
However, I don’t recall that we discussed an additional amount of time beyond the two-business day total response time. Indeed, I thought the whole goal of our discussion was to create a single ceiling beyond the “without undue delay,” generally w/in 24 hours, which we ultimately agreed would expire at 2 business days from receipt. So, I was surprised to see 10.6.2:
10.6.2. In addition to the extension provided for in Section 10.6.1, if responding to an Urgent Request for Lawful Disclosure is complex, or a large number of requests are received by Registrar or Registry Operator, it MAY extend the time for response up to an additional one (1) business day provided it notifies the requestor within (2) business days from the time of the initial receipt of the request of the updated time frame to respond explaining the need for an additional extension of time.
The reason that I’m concerned is that we’re now back to a scenario where urgent requests could take three business days to respond to which is what the GAC objected to in its public comment as inconsistent with the nature of an “urgent” request.
I think this needs further discussion because I don’t think the current draft accurately reflects what we discussed on 7/19. My suggestion would be to either:
1. Delete 10.6.2 or 2. Add the concepts of “complex” and “large number” to 10.6.1 as part of the rationale that may be shared to justify an extension of time to respond to an urgent request.
I suggest that we need an additional call unless this can be resolved via email.
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 Dennis Chang via IRT.RegDataPolicy Sent: Monday, July 24, 2023 5:24 PM To: irt.regdatapolicy@icann.org Subject: [IRT.RegDataPolicy] Review RegData complete draft Re: Good News. Urgent Request. IRT supported solution found!
Dear IRT,
Attached is a completed draft of the Registration Data Policy including the last two outstanding sections. Section 4.0: Policy Effective Date reflecting the 6+12 plan for the 18-month implementation timeline. Section 10.6: Urgent Request reflecting the solution supported at the IRT meeting last week. (see email below)
I believe we now have a good policy that is aligned with all 34 recommendations we will work together to implement. EPDP Phase 1 recommendations (29) May 2019 EPDP Phase 2 Priority 2 Recommendations (4) June 2021 Supplemental Recommendation (1) March 2022
As we discussed at our last IRT meeting, we don’t plan on more IRT meetings before we publish our policy in August 2023. We’ll notify you of the publication date after we have coordinated with our publication team. We may have more IRT meetings after we publish to coordinate and collaborate our implementation, but that decision will come later. For now, we will focus on getting this policy published.
If you have questions or comments, I request they be submitted in separate emails with Subject line defining the topic. It will help us to collect the information as we address them together.
Thank you all once again and I hope you all support the attached policy language for publication and implementation.
Gratefully your, Dennis Chang
From: "IRT.RegDataPolicy" <irt.regdatapolicy-bounces@icann.org> on behalf of "Dennis Chang via IRT.RegDataPolicy" <irt.regdatapolicy@icann.org> Reply-To: Dennis Chang <dennis.chang@icann.org> Date: Friday, July 21, 2023 at 8:40 AM To: "irt.regdatapolicy@icann.org" <irt.regdatapolicy@icann.org> Subject: Re: [IRT.RegDataPolicy] RegData IRT Good News. Urgent Request requirement. IRT supported solution found!
Dear IRT,
If you haven’t heard already, we did it!
We found a solution to Urgent Request supported by IRT at our 90 minutes focused working session this week. Thank you so much for not giving up and working as a team to find this solution. It was impressive to see people still listening to one another, appreciating the different views, and truly collaborating to build on ideas to find the compromised solution. A great demonstration of One Team against the problem.
What was that solution?
* 24 hours. Respond in 24 hours with the info or an explanation for more time needed. * 2 Business Days. No more than 2 Business Days to Respond.
How did this happen? First, thanks to Roger and RrSG for the planting the seed with using both 24 hours and 2 business days in the solution. Instead of outright rejecting it, Laureen and others suggested that we build on it. Thomas came in with a key ingredient – the explanation.
Initially, we discussed all the options but created this new one listening to the “interest” behind the positions. Business Days was important because of the business realities in various regions around the world. While Calendar Days sets global time consistency, the team agreed that cultural sensitivity to regions was more important. The dread of “silence” with undetermined timeline using “Business Days” was solved with the promise of a response in 24 hours with an explanation. Thanks to Gabriel expressing the “dread” so eloquently. Overall, it was an exciting finale overcoming the toughest challenge for us.
As promised, we’ll draft the policy language using the IRT supported requirements and comeback to you, but I wanted to send you this quick note to express my sincere gratitude for wonderfully responding.
I thank those guests that joined to support us too. I noted Ashley, RrSG Chair and Becky, ICANN Board and others supporting us behind the scenes. Please convey our sincere appreciation to your team back home too.
THANK YOU!
Dennis S. Chang GDD Programs Director Phone: +1 213 293 7889 Sykpe: dennisSchang www.icann.org<http://www.icann.org> One World – One Internet
------------------------------------------------------------------------
_______________________________________________ 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 (7)
-
Dennis Chang -
Gabriel Andrews -
Kapin, Laureen -
Owen Smigelski -
Rubens Kuhl -
Sarah Wyld -
Steve Crocker