Call for IRT Action - Resolution of the final policy requirement: Urgent Request
Dear IRT, Thank you for supporting the IRT call yesterday. You should have received Andrea’s email notification for recording by now. I encourage all to listen and support the final push to resolve the one last outstanding policy requirement: Urgent Request. Keep in mind it’s Urgent Request vs IRT. IRT is One Team. We spent most of the call discussing Urgent Request, but it was apparent to me that the IRT needs more time to consider. Some new voices and new ideas came in too. Let’s allocate another two additional weeks for work this out. We can still make our August publication. Please continue the discussion on the urgent request on the list and provide your inputs including the proposed policy language. In addition, we will send out a doodle for interested parties to continue a discussion during a dedicated meeting. Interested IRT members can reply to that message. We will arrange a meeting room for these members. Thus far, there has not been a proposed urgent response solution that is agreeable to the full IRT, and these discussions cannot continue indefinitely. This is why the EPDP Phase 1 team asked us – the implementation team - to make the decision. We therefore encourage you to work together to agree on a solution that everyone can live with – both the urgent requestors and responders. We already heard Request for Reconsideration mentioned and if it must come to that we’ll follow that defined process. However, what I heard from the call is the willingness to reach a compromised solution to avoid such disruption and delay in our implementation. Please use the next two weeks to reach an agreement. If IRT members are unable to come to an agreement that everyone can live with, ICANN will need to keep the Phase 2 language of “1 business day, not to exceed 3 calendar days” as we believe this is the only solution that demonstrated community support by receiving consensus at GNSO. Per Marc A’s suggestion, we may add the additional Phase 2 percentages language to account for concerns with abusive and voluminous requests marked as urgent. percentiles to achieve consistency (see. p. 42 of the EPDP Phase 2 Final Report). We’d like to hear from you on this too. We have reviewed the latest proposal from the RrSG, submitted by Roger on 10 July 2023, and do not believe it would adequately address the concerns raised during public comment from non-contracted party constituencies. Specifically, it reverts the requirement back to the same (two business days), as the addition of "generally means within 24 hours" would not be relevant for contractual enforcement purposes. By reverting to this standard, the same issues remain (e.g. business days vary by jurisdiction and may result in extensive response time where long business shutdowns may occur, both of which are challenging for enforcement purposes). Thanks to Laureen for pointing this out during the IRT call. Thanks to Steve for the caution to watch for holes and referring to DNS Abuse efforts. Perhaps, we need to pivot but can’t see it; I know I am deep in the hole already. How would this align with the recommendation we must implement? Also, I heard “improper implementation of the recommendation.” This is very important and if so, it is the IRT’s role to point this out and if clarity of the recommendation language is in question, we need to consult GNSO. This is the reason we are fortunate to have the best GNSO Liaison in the IRT so that this can be done quickly and efficiently. Thank you all for your dedication and passion for this important work and hang in there. -- Kind Regards, Dennis S. Chang GDD Programs Director Phone: +1 213 293 7889 Sykpe: dennisSchang www.icann.org<http://www.icann.org> One World – One Internet
Hello IRT, I remain of the opinion that we should return to our pre-public-comment agreed language of "acknowledge and respond without undue delay, but no more than two (2) business days from receipt." 1. This corresponds clearly to the recommendation language ("less than X business days"), which is not the case for any implementation that includes calendar days, or fewer than two business days. An implementation of a calendar days requirement negates the inclusion of business days. 2. The true requirement is "without undue delay". The addition of a business days period provides essential time for a registrar to review the request, determine if it does indeed fall under the definition of “urgent”, and conduct the balancing test to make a legal decision about disclosure. 2 business days allows responsive registrars the ability to respond within an appropriate period, while also ensuring that ICANN Compliance can take action against those which do not. 3. Smaller and non-US/EU-based registrars would be significantly and disproportionately disadvantaged by a shorter response timeframe. These registrars often need to work with external counsel to conduct the review and make the decision; preventing them from having the appropriate time to do so is unfair, anti-competitive, and can very easily lead to improper disclosure decisions. Either to disclose the data without proper legal basis to do so or to NOT disclose the data when actually it should be disclosed are both outcomes that should be avoided and instead we are pushing in that direction. We all want to finish this work and move forward with implementation; we all agree that Urgent requests must be responded to without undue delay. We had reached sufficient agreement with the pre-comment language to put it out for comment; in the absence of further agreements, that is what we should return to now. Thank you, -- Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/they swyld@tucows.com From: Andrea Glandon via IRT.RegDataPolicy Sent: July 13, 2023 11:10 AM To: irt.regdatapolicy@icann.org Subject: [IRT.RegDataPolicy] Call for IRT Action - Resolution of the finalpolicy requirement: Urgent Request Dear IRT, Thank you for supporting the IRT call yesterday. You should have received Andrea’s email notification for recording by now. I encourage all to listen and support the final push to resolve the one last outstanding policy requirement: Urgent Request. Keep in mind it’s Urgent Request vs IRT. IRT is One Team. We spent most of the call discussing Urgent Request, but it was apparent to me that the IRT needs more time to consider. Some new voices and new ideas came in too. Let’s allocate another two additional weeks for work this out. We can still make our August publication. Please continue the discussion on the urgent request on the list and provide your inputs including the proposed policy language. In addition, we will send out a doodle for interested parties to continue a discussion during a dedicated meeting. Interested IRT members can reply to that message. We will arrange a meeting room for these members. Thus far, there has not been a proposed urgent response solution that is agreeable to the full IRT, and these discussions cannot continue indefinitely. This is why the EPDP Phase 1 team asked us – the implementation team - to make the decision. We therefore encourage you to work together to agree on a solution that everyone can live with – both the urgent requestors and responders. We already heard Request for Reconsideration mentioned and if it must come to that we’ll follow that defined process. However, what I heard from the call is the willingness to reach a compromised solution to avoid such disruption and delay in our implementation. Please use the next two weeks to reach an agreement. If IRT members are unable to come to an agreement that everyone can live with, ICANN will need to keep the Phase 2 language of “1 business day, not to exceed 3 calendar days” as we believe this is the only solution that demonstrated community support by receiving consensus at GNSO. Per Marc A’s suggestion, we may add the additional Phase 2 percentages language to account for concerns with abusive and voluminous requests marked as urgent. percentiles to achieve consistency (see. p. 42 of the EPDP Phase 2 Final Report). We’d like to hear from you on this too. We have reviewed the latest proposal from the RrSG, submitted by Roger on 10 July 2023, and do not believe it would adequately address the concerns raised during public comment from non-contracted party constituencies. Specifically, it reverts the requirement back to the same (two business days), as the addition of "generally means within 24 hours" would not be relevant for contractual enforcement purposes. By reverting to this standard, the same issues remain (e.g. business days vary by jurisdiction and may result in extensive response time where long business shutdowns may occur, both of which are challenging for enforcement purposes). Thanks to Laureen for pointing this out during the IRT call. Thanks to Steve for the caution to watch for holes and referring to DNS Abuse efforts. Perhaps, we need to pivot but can’t see it; I know I am deep in the hole already. How would this align with the recommendation we must implement? Also, I heard “improper implementation of the recommendation.” This is very important and if so, it is the IRT’s role to point this out and if clarity of the recommendation language is in question, we need to consult GNSO. This is the reason we are fortunate to have the best GNSO Liaison in the IRT so that this can be done quickly and efficiently. Thank you all for your dedication and passion for this important work and hang in there. -- Kind Regards, Dennis S. Chang GDD Programs Director Phone: +1 213 293 7889 Sykpe: dennisSchang www.icann.org One World – One Internet
Sarah, What’s missing from the language you’re referring to is a way to contact the registrar on an urgent basis. Steve On Tue, Jul 18, 2023 at 3:01 PM Sarah Wyld via IRT.RegDataPolicy < irt.regdatapolicy@icann.org> wrote:
Hello IRT,
I remain of the opinion that we should return to our pre-public-comment agreed language of "acknowledge and respond without undue delay, but no more than two (2) business days from receipt."
1. This corresponds clearly to the recommendation language ("less than X business days"), which is not the case for any implementation that includes calendar days, or fewer than two business days. An implementation of a calendar days requirement negates the inclusion of business days.
2. The true requirement is "without undue delay". The addition of a business days period provides essential time for a registrar to review the request, determine if it does indeed fall under the definition of “urgent”, and conduct the balancing test to make a legal decision about disclosure. 2 business days allows responsive registrars the ability to respond within an appropriate period, while also ensuring that ICANN Compliance can take action against those which do not.
3. Smaller and non-US/EU-based registrars would be significantly and disproportionately disadvantaged by a shorter response timeframe. These registrars often need to work with external counsel to conduct the review and make the decision; preventing them from having the appropriate time to do so is unfair, anti-competitive, and can very easily lead to improper disclosure decisions. Either to disclose the data without proper legal basis to do so or to NOT disclose the data when actually it should be disclosed are both outcomes that should be avoided and instead we are pushing in that direction.
We all want to finish this work and move forward with implementation; we all agree that Urgent requests must be responded to without undue delay. We had reached sufficient agreement with the pre-comment language to put it out for comment; in the absence of further agreements, that is what we should return to now.
Thank you,
--
*Sarah Wyld*, CIPP/E
Policy & Privacy Manager
Pronouns: she/they
swyld@tucows.com
*From: *Andrea Glandon via IRT.RegDataPolicy <irt.regdatapolicy@icann.org> *Sent: *July 13, 2023 11:10 AM *To: *irt.regdatapolicy@icann.org *Subject: *[IRT.RegDataPolicy] Call for IRT Action - Resolution of the finalpolicy requirement: Urgent Request
Dear IRT,
Thank you for supporting the IRT call yesterday. You should have received Andrea’s email notification for recording by now. I encourage all to listen and support the final push to resolve the one last outstanding policy requirement: Urgent Request.
Keep in mind it’s Urgent Request vs IRT. IRT is One Team.
We spent most of the call discussing Urgent Request, but it was apparent to me that the IRT needs more time to consider. Some new voices and new ideas came in too. Let’s allocate another two additional weeks for work this out. We can still make our August publication.
Please continue the discussion on the urgent request on the list and provide your inputs including the proposed policy language.
In addition, we will send out a doodle for interested parties to continue a discussion during a dedicated meeting. Interested IRT members can reply to that message. We will arrange a meeting room for these members.
Thus far, there has not been a proposed urgent response solution that is agreeable to the full IRT, and these discussions cannot continue indefinitely. This is why the EPDP Phase 1 team asked us – the implementation team - to make the decision.
We therefore encourage you to work together to agree on a solution that everyone can live with – both the urgent requestors and responders. We already heard Request for Reconsideration mentioned and if it must come to that we’ll follow that defined process. However, what I heard from the call is the willingness to reach a compromised solution to avoid such disruption and delay in our implementation.
Please use the next two weeks to reach an agreement. If IRT members are unable to come to an agreement that everyone can live with, ICANN will need to keep the Phase 2 language of “1 business day, not to exceed 3 calendar days” as we believe this is the only solution that demonstrated community support by receiving consensus at GNSO.
Per Marc A’s suggestion, we may add the additional Phase 2 percentages language to account for concerns with abusive and voluminous requests marked as urgent. percentiles to achieve consistency (see. p. 42 of the EPDP Phase 2 Final Report). We’d like to hear from you on this too.
We have reviewed the latest proposal from the RrSG, submitted by Roger on 10 July 2023, and do not believe it would adequately address the concerns raised during public comment from non-contracted party constituencies. Specifically, it reverts the requirement back to the same (two business days), as the addition of "generally means within 24 hours" would not be relevant for contractual enforcement purposes. By reverting to this standard, the same issues remain (e.g. business days vary by jurisdiction and may result in extensive response time where long business shutdowns may occur, both of which are challenging for enforcement purposes). Thanks to Laureen for pointing this out during the IRT call.
Thanks to Steve for the caution to watch for holes and referring to DNS Abuse efforts. Perhaps, we need to pivot but can’t see it; I know I am deep in the hole already. How would this align with the recommendation we must implement?
Also, I heard “improper implementation of the recommendation.” This is very important and if so, it is the IRT’s role to point this out and if clarity of the recommendation language is in question, we need to consult GNSO. This is the reason we are fortunate to have the best GNSO Liaison in the IRT so that this can be done quickly and efficiently.
Thank you all for your dedication and passion for this important work and hang in there.
--
Kind Regards,
Dennis S. Chang
GDD Programs Director
Phone: +1 213 293 7889
Sykpe: dennisSchang
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.
Em 18 de jul. de 2023, à(s) 16:05, Steve Crocker via IRT.RegDataPolicy <irt.regdatapolicy@icann.org> escreveu:
Sarah,
What’s missing from the language you’re referring to is a way to contact the registrar on an urgent basis.
That’s already baked in 10.1: 10. Disclosure Requests 10.1. Registrar and Registry Operator MUST publish on their homepage a direct link to a page where the mechanism and process for submitting Disclosure Requests is detailed. The mechanism and process MUST specify (a) the required format and content of requests, (b) the Registrar’s or Registry Operator’s means of providing a response to the requestor, and (c) the anticipated timeline for responses So in order to fulfill (c) above for urgent requests, (a) and (b) also need to address how an urgent request differs from the other requests on how to perform one and how one is handled. One sample implementation could be: “For standard disclosure requests, this-and-this-and-that requirements, please click here. For urgent requests, which would need the requirements above plus this other criteria, please call 1-800-REG-DATA” Rubens
Rubens, Thanks. I’ve been told the registrars want to avoid being bedeviled with bulk and/or bogus requests. I’ve also been told that at least some law enforcement personnel don’t believe there is contact information available for all registrars. Steve Sent from my iPhone
On Jul 18, 2023, at 3:50 PM, Rubens Kuhl via IRT.RegDataPolicy <irt.regdatapolicy@icann.org> wrote:
Em 18 de jul. de 2023, à(s) 16:05, Steve Crocker via IRT.RegDataPolicy <irt.regdatapolicy@icann.org> escreveu:
Sarah,
What’s missing from the language you’re referring to is a way to contact the registrar on an urgent basis.
That’s already baked in 10.1:
10. Disclosure Requests 10.1. Registrar and Registry Operator MUST publish on their homepage a direct link to a page where the mechanism and process for submitting Disclosure Requests is detailed. The mechanism and process MUST specify (a) the required format and content of requests, (b) the Registrar’s or Registry Operator’s means of providing a response to the requestor, and (c) the anticipated timeline for responses
So in order to fulfill (c) above for urgent requests, (a) and (b) also need to address how an urgent request differs from the other requests on how to perform one and how one is handled.
One sample implementation could be:
“For standard disclosure requests, this-and-this-and-that requirements, please click here. For urgent requests, which would need the requirements above plus this other criteria, please call 1-800-REG-DATA”
Rubens
_______________________________________________ IRT.RegDataPolicy mailing list IRT.RegDataPolicy@icann.org https://mm.icann.org/mailman/listinfo/irt.regdatapolicy
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Em 18 de jul. de 2023, à(s) 16:56, Steve Crocker <steve@shinkuro.com> escreveu:
Rubens,
Thanks. I’ve been told the registrars want to avoid being bedeviled with bulk and/or bogus requests.
And they can use any available resource to do that. Captchas, LLM AIs, human operators… economics and feasibility of each way will vary among contracted parties. But there is no “one size fits all” obligation to use any specific way, and this prevents another occurrence of fax in the contract, which required an amendment to get rid of outdated technology.
’ve also been told that at least some law enforcement personnel don’t believe there is contact information available for all registrars.
This is likely the reason for having this requirement in the policy language we are discussing… 10.1 addresses that concern. Rubens
Hi Steve, If there is anyone (including law enforcement), who thinks that a registrar does not have proper contact information available, then they should immediately file a complaint with ICANN Contractual Compliance. The RAA has a number of contact obligations for registrars, and speaking from experience, Compliance can and will send breach notices to registrars for not providing the required contact information. Regards, Owen
On Jul 18, 2023, at 12:56, 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. ********************
Rubens,
Thanks. I’ve been told the registrars want to avoid being bedeviled with bulk and/or bogus requests. I’ve also been told that at least some law enforcement personnel don’t believe there is contact information available for all registrars.
Steve
Sent from my iPhone
On Jul 18, 2023, at 3:50 PM, Rubens Kuhl via IRT.RegDataPolicy <irt.regdatapolicy@icann.org> wrote:
Em 18 de jul. de 2023, à(s) 16:05, Steve Crocker via IRT.RegDataPolicy <irt.regdatapolicy@icann.org> escreveu:
Sarah,
What’s missing from the language you’re referring to is a way to contact the registrar on an urgent basis.
That’s already baked in 10.1:
10. Disclosure Requests 10.1. Registrar and Registry Operator MUST publish on their homepage a direct link to a page where the mechanism and process for submitting Disclosure Requests is detailed. The mechanism and process MUST specify (a) the required format and content of requests, (b) the Registrar’s or Registry Operator’s means of providing a response to the requestor, and (c) the anticipated timeline for responses
So in order to fulfill (c) above for urgent requests, (a) and (b) also need to address how an urgent request differs from the other requests on how to perform one and how one is handled.
One sample implementation could be:
“For standard disclosure requests, this-and-this-and-that requirements, please click here. For urgent requests, which would need the requirements above plus this other criteria, please call 1-800-REG-DATA”
Rubens
_______________________________________________ IRT.RegDataPolicy mailing list IRT.RegDataPolicy@icann.org https://mm.icann.org/mailman/listinfo/irt.regdatapolicy
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
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, Thanks. I will pass this along. Steve Sent from my iPhone
On Jul 21, 2023, at 2:54 PM, Owen Smigelski <owen.smigelski@namecheap.com> wrote:
Hi Steve,
If there is anyone (including law enforcement), who thinks that a registrar does not have proper contact information available, then they should immediately file a complaint with ICANN Contractual Compliance. The RAA has a number of contact obligations for registrars, and speaking from experience, Compliance can and will send breach notices to registrars for not providing the required contact information.
Regards,
Owen
On Jul 18, 2023, at 12:56, 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. ********************
Rubens,
Thanks. I’ve been told the registrars want to avoid being bedeviled with bulk and/or bogus requests. I’ve also been told that at least some law enforcement personnel don’t believe there is contact information available for all registrars.
Steve
Sent from my iPhone
On Jul 18, 2023, at 3:50 PM, Rubens Kuhl via IRT.RegDataPolicy <irt.regdatapolicy@icann.org> wrote:
Em 18 de jul. de 2023, à(s) 16:05, Steve Crocker via IRT.RegDataPolicy <irt.regdatapolicy@icann.org> escreveu:
Sarah,
What’s missing from the language you’re referring to is a way to contact the registrar on an urgent basis.
That’s already baked in 10.1:
10. Disclosure Requests 10.1. Registrar and Registry Operator MUST publish on their homepage a direct link to a page where the mechanism and process for submitting Disclosure Requests is detailed. The mechanism and process MUST specify (a) the required format and content of requests, (b) the Registrar’s or Registry Operator’s means of providing a response to the requestor, and (c) the anticipated timeline for responses
So in order to fulfill (c) above for urgent requests, (a) and (b) also need to address how an urgent request differs from the other requests on how to perform one and how one is handled.
One sample implementation could be:
“For standard disclosure requests, this-and-this-and-that requirements, please click here. For urgent requests, which would need the requirements above plus this other criteria, please call 1-800-REG-DATA”
Rubens
_______________________________________________ IRT.RegDataPolicy mailing list IRT.RegDataPolicy@icann.org https://mm.icann.org/mailman/listinfo/irt.regdatapolicy
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
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 (5)
-
Andrea Glandon -
Owen Smigelski -
Rubens Kuhl -
Sarah Wyld -
Steve Crocker