SSR2 action item: Review rec 29 markup
Dear SSR2 RT members, As discussed on the call today, please review the proposed markup of rec 29 (see page 59) here: https://docs.google.com/document/d/1WTnaEk2pW0V85FRXk1uUN4O-co7DcDIXb_9_-1MC.... Please share any comments/feedback ahead of the meeting next week. Best, Jennifer -- Jennifer Bryce Associate Project Manager, Review Support and Accountability Internet Corporation for Assigned Names and Numbers (ICANN) Skype: jennifer.bryce.icann Email: jennifer.bryce@icann.org
KC: You seem to be advocating deleting all of the text related to Rec. 29. Is that right? We spent a lot of time talking about ICANN org keeping up with GDPR and similar laws. Where do you think that belongs? Russ
On Sep 23, 2020, at 10:32 AM, Jennifer Bryce <jennifer.bryce@icann.org> wrote:
Dear SSR2 RT members,
As discussed on the call today, please review the proposed markup of rec 29 (see page 59) here: https://docs.google.com/document/d/1WTnaEk2pW0V85FRXk1uUN4O-co7DcDIXb_9_-1MC... <https://docs.google.com/document/d/1WTnaEk2pW0V85FRXk1uUN4O-co7DcDIXb_9_-1MC...>.
Please share any comments/feedback ahead of the meeting next week.
Best, Jennifer
-- Jennifer Bryce Associate Project Manager, Review Support and Accountability Internet Corporation for Assigned Names and Numbers (ICANN)
Skype: jennifer.bryce.icann Email: jennifer.bryce@icann.org <mailto:jennifer.bryce@icann.org>
_______________________________________________ Ssr2-review mailing list Ssr2-review@icann.org <mailto:Ssr2-review@icann.org> https://mm.icann.org/mailman/listinfo/ssr2-review <https://mm.icann.org/mailman/listinfo/ssr2-review>
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy <https://www.icann.org/privacy/policy>) and the website Terms of Service (https://www.icann.org/privacy/tos <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.
Russ Yes, that's correct. We spent a lot of time talking about a lot of things that don't need to be in a report 3 years later. What does SSR2 want ICANN to do beyond what's here? https://www.icann.org/dataprotectionprivacy I think ICANN is "keeping up with GDPR and similar laws", in fact its CPs are arguably overcommitted to privacy (or at least "not sharing data for free") at the expense of security. So I don't think this advocacy is appropriate. We know these laws are up for interpretation, and that "keeping up w the laws" is not an SSR issue, it's how they are interpreted and accommodated that have SSR implications. Moreover, why are we asking ICANN to keep with privacy laws in an SSR review? Why not cybercrime laws? Or breach notification laws? If it's because lack of access to RDAP data is a security challenge, then we should advocate finding a way to overcome that security challenge. k On Mon, Sep 28, 2020 at 01:22:46PM -0400, Russ Housley wrote: KC: You seem to be advocating deleting all of the text related to Rec. 29. Is that right? We spent a lot of time talking about ICANN org keeping up with GDPR and similar laws. Where do you think that belongs? Russ
On Sep 23, 2020, at 10:32 AM, Jennifer Bryce <jennifer.bryce@icann.org> wrote:
Dear SSR2 RT members,
As discussed on the call today, please review the proposed markup of rec 29 (see page 59) here: https://docs.google.com/document/d/1WTnaEk2pW0V85FRXk1uUN4O-co7DcDIXb_9_-1MC... <https://docs.google.com/document/d/1WTnaEk2pW0V85FRXk1uUN4O-co7DcDIXb_9_-1MC...>.
Please share any comments/feedback ahead of the meeting next week.
Best, Jennifer
-- Jennifer Bryce Associate Project Manager, Review Support and Accountability Internet Corporation for Assigned Names and Numbers (ICANN)
Skype: jennifer.bryce.icann Email: jennifer.bryce@icann.org <mailto:jennifer.bryce@icann.org>
_______________________________________________ Ssr2-review mailing list Ssr2-review@icann.org <mailto:Ssr2-review@icann.org> https://mm.icann.org/mailman/listinfo/ssr2-review <https://mm.icann.org/mailman/listinfo/ssr2-review>
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy <https://www.icann.org/privacy/policy>) and the website Terms of Service (https://www.icann.org/privacy/tos <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.
Dear KC Sorry for the late reply.
I wanted to have given the opportunity to the other team members to respond but also wanted to reiterate, that while I agreed the current text and placement of the text needed to be re-written and updated, the issue of privacy and security are still interlinked. The on-going discussion on the issue of WHOIS, GDPR and the Disclosure Procedure, does make this issue no longer a future security challenge as it was three years ago.
In the recent minority statement issued on August 24, 2020 by GAC, they stated and referenced the importance of this issue to security and stability.
The GAC acknowledges that under applicable data protection rules, including the GDPR, contracted Parties will likely remain responsible for the decision whether to disclose domain name registration data, and may face certain liability risks related to that decision. The GAC understands that contracted Parties have therefore sought to maintain control over the decision whether to disclose domain name registration data. The GAC notes, however, that those decentralized decisions whether to disclose data are largely exempt from challenge and enforcement action, notably via ICANN Compliance. 11 Registration data is important for the security and stability of the DNS and there is a real concern that contracted parties may inadvertently or purposely not properly weigh the public interest for the requestor to obtain such data. ICANN’s CEO recently conveyed this very concern to the European Data Protection Board, pointing out that “[d]ue to a lack of legal certainty, registrars, as controllers, are likely to evaluate privacy and data protection in absolute terms, without considering other rights and legitimate interests, to avoid possible regulatory sanctions or a judgment against them.”12 Denials of legitimate requests for access to domain name registration data have real consequences.
A review of some of these pages and other resources would allow the SSR2 team to at least ensure we express an appreciation of the issue and not have it removed from the report, but better placed and maybe stated more succinctly (https://whois.icann.org/en/using-whois; https://gac.icann.org/statement/public/gac-minority-statement-epdp-phase2-24...; https://gnso.icann.org/sites/default/files/file/field-file-attach/epdp-phase...)
I would like to propose as we had agreed on the call that we could develop new text that would still capture the issues and the need for Compliance to have a stronger role in this process, which was the basis of this recommendation.
The idea is not to make it a crime consideration but for security measures to be implemented for the security of data - of which data privacy is a subset.
I won’t be able to join tomorrow because I was asked to deliver a course ( this is a one off situation) but available if there is consensus on the way fwd. Cheers Kerry-Ann
On Sep 29, 2020, at 12:56 AM, k claffy <kc@caida.org> wrote:
Russ
Yes, that's correct.
We spent a lot of time talking about a lot of things that don't need to be in a report 3 years later.
What does SSR2 want ICANN to do beyond what's here? https://www.icann.org/dataprotectionprivacy I think ICANN is "keeping up with GDPR and similar laws", in fact its CPs are arguably overcommitted to privacy (or at least "not sharing data for free") at the expense of security. So I don't think this advocacy is appropriate. We know these laws are up for interpretation, and that "keeping up w the laws" is not an SSR issue, it's how they are interpreted and accommodated that have SSR implications.
Moreover, why are we asking ICANN to keep with privacy laws in an SSR review? Why not cybercrime laws? Or breach notification laws?
If it's because lack of access to RDAP data is a security challenge, then we should advocate finding a way to overcome that security challenge.
k
On Mon, Sep 28, 2020 at 01:22:46PM -0400, Russ Housley wrote: KC:
You seem to be advocating deleting all of the text related to Rec. 29. Is that right?
We spent a lot of time talking about ICANN org keeping up with GDPR and similar laws. Where do you think that belongs?
Russ
On Sep 23, 2020, at 10:32 AM, Jennifer Bryce <jennifer.bryce@icann.org> wrote:
Dear SSR2 RT members,
As discussed on the call today, please review the proposed markup of rec 29 (see page 59) here: https://docs.google.com/document/d/1WTnaEk2pW0V85FRXk1uUN4O-co7DcDIXb_9_-1MC... <https://docs.google.com/document/d/1WTnaEk2pW0V85FRXk1uUN4O-co7DcDIXb_9_-1MC...>.
Please share any comments/feedback ahead of the meeting next week.
Best, Jennifer
-- Jennifer Bryce Associate Project Manager, Review Support and Accountability Internet Corporation for Assigned Names and Numbers (ICANN)
Skype: jennifer.bryce.icann Email: jennifer.bryce@icann.org <mailto:jennifer.bryce@icann.org>
_______________________________________________ Ssr2-review mailing list Ssr2-review@icann.org <mailto:Ssr2-review@icann.org> https://mm.icann.org/mailman/listinfo/ssr2-review <https://mm.icann.org/mailman/listinfo/ssr2-review>
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy <https://www.icann.org/privacy/policy>) and the website Terms of Service (https://www.icann.org/privacy/tos <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.
_______________________________________________ Ssr2-review mailing list Ssr2-review@icann.org https://mm.icann.org/mailman/listinfo/ssr2-review
_______________________________________________ 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.
On the call today, there was agreement to say something about the SSR implications and the desire for ICANN Compliance to be proactive. However, this seems to be part of the Abuse subteam since that already has a lot to say about ICANN Compliance. Since all parties that are active in this conversation are already part of the Abuse subteam, this seems like a very desirable way forward. The expectation is that this will be part of the Abuse subteam report to the whole RT next week. Russ
On Sep 30, 2020, at 11:04 PM, Kerry-Ann Barrett <kerryann.barrett@gmail.com> wrote:
Dear KC Sorry for the late reply.
I wanted to have given the opportunity to the other team members to respond but also wanted to reiterate, that while I agreed the current text and placement of the text needed to be re-written and updated, the issue of privacy and security are still interlinked. The on-going discussion on the issue of WHOIS, GDPR and the Disclosure Procedure, does make this issue no longer a future security challenge as it was three years ago.
In the recent minority statement issued on August 24, 2020 by GAC, they stated and referenced the importance of this issue to security and stability.
The GAC acknowledges that under applicable data protection rules, including the GDPR, contracted Parties will likely remain responsible for the decision whether to disclose domain name registration data, and may face certain liability risks related to that decision. The GAC understands that contracted Parties have therefore sought to maintain control over the decision whether to disclose domain name registration data. The GAC notes, however, that those decentralized decisions whether to disclose data are largely exempt from challenge and enforcement action, notably via ICANN Compliance. 11 Registration data is important for the security and stability of the DNS and there is a real concern that contracted parties may inadvertently or purposely not properly weigh the public interest for the requestor to obtain such data. ICANN’s CEO recently conveyed this very concern to the European Data Protection Board, pointing out that “[d]ue to a lack of legal certainty, registrars, as controllers, are likely to evaluate privacy and data protection in absolute terms, without considering other rights and legitimate interests, to avoid possible regulatory sanctions or a judgment against them.”12 Denials of legitimate requests for access to domain name registration data have real consequences.
A review of some of these pages and other resources would allow the SSR2 team to at least ensure we express an appreciation of the issue and not have it removed from the report, but better placed and maybe stated more succinctly (https://whois.icann.org/en/using-whois <https://whois.icann.org/en/using-whois>; https://gac.icann.org/statement/public/gac-minority-statement-epdp-phase2-24... <https://gac.icann.org/statement/public/gac-minority-statement-epdp-phase2-24...>; https://gnso.icann.org/sites/default/files/file/field-file-attach/epdp-phase... <https://gnso.icann.org/sites/default/files/file/field-file-attach/epdp-phase...>)
I would like to propose as we had agreed on the call that we could develop new text that would still capture the issues and the need for Compliance to have a stronger role in this process, which was the basis of this recommendation.
The idea is not to make it a crime consideration but for security measures to be implemented for the security of data - of which data privacy is a subset.
I won’t be able to join tomorrow because I was asked to deliver a course ( this is a one off situation) but available if there is consensus on the way fwd.
Cheers Kerry-Ann
On Sep 29, 2020, at 12:56 AM, k claffy <kc@caida.org> wrote:
Russ
Yes, that's correct.
We spent a lot of time talking about a lot of things that don't need to be in a report 3 years later.
What does SSR2 want ICANN to do beyond what's here? https://www.icann.org/dataprotectionprivacy I think ICANN is "keeping up with GDPR and similar laws", in fact its CPs are arguably overcommitted to privacy (or at least "not sharing data for free") at the expense of security. So I don't think this advocacy is appropriate. We know these laws are up for interpretation, and that "keeping up w the laws" is not an SSR issue, it's how they are interpreted and accommodated that have SSR implications.
Moreover, why are we asking ICANN to keep with privacy laws in an SSR review? Why not cybercrime laws? Or breach notification laws?
If it's because lack of access to RDAP data is a security challenge, then we should advocate finding a way to overcome that security challenge.
k
On Mon, Sep 28, 2020 at 01:22:46PM -0400, Russ Housley wrote: KC:
You seem to be advocating deleting all of the text related to Rec. 29. Is that right?
We spent a lot of time talking about ICANN org keeping up with GDPR and similar laws. Where do you think that belongs?
Russ
On Sep 23, 2020, at 10:32 AM, Jennifer Bryce <jennifer.bryce@icann.org> wrote:
Dear SSR2 RT members,
As discussed on the call today, please review the proposed markup of rec 29 (see page 59) here: https://docs.google.com/document/d/1WTnaEk2pW0V85FRXk1uUN4O-co7DcDIXb_9_-1MC... <https://docs.google.com/document/d/1WTnaEk2pW0V85FRXk1uUN4O-co7DcDIXb_9_-1MC...>.
Please share any comments/feedback ahead of the meeting next week.
Best, Jennifer
-- Jennifer Bryce Associate Project Manager, Review Support and Accountability Internet Corporation for Assigned Names and Numbers (ICANN)
Skype: jennifer.bryce.icann Email: jennifer.bryce@icann.org <mailto:jennifer.bryce@icann.org>
_______________________________________________ Ssr2-review mailing list Ssr2-review@icann.org <mailto:Ssr2-review@icann.org> https://mm.icann.org/mailman/listinfo/ssr2-review <https://mm.icann.org/mailman/listinfo/ssr2-review>
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy <https://www.icann.org/privacy/policy>) and the website Terms of Service (https://www.icann.org/privacy/tos <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.
_______________________________________________ Ssr2-review mailing list Ssr2-review@icann.org https://mm.icann.org/mailman/listinfo/ssr2-review
_______________________________________________ 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.
Kerry-Ann, Thanks. The text you have below mostly makes sense, but the GAC missed my crucial point, while ICANN obliquely makes it in response. Those holding registration data are not qualified to "properly weigh the public interest" for access to private data. Nor is ICANN able to sufficiently represent the public interest in negotiations with them; the conflict of interest is overwhelming. So framing this recommendation around "ICANN should stay abreast of the laws around the world" makes no sense to me. I believe it is Europe (and any other government who wants mandatory access to this data under specific circumstances) who need their laws to catch up with reality on the ground. This is the primary lesson of the EPDP -- ICANN process will not thread this needle. I think the sentiments below belong in a section on access to registration data. As soon as someone lets me know where i can put text into that section, I'll work on it. It is not a good use of SSR2 time to continue this conversation until that section is done. k On Wed, Sep 30, 2020 at 11:04:28PM -0400, Kerry-Ann Barrett wrote:
Dear KC Sorry for the late reply.
I wanted to have given the opportunity to the other team members to respond but also wanted to reiterate, that while I agreed the current text and placement of the text needed to be re-written and updated, the issue of privacy and security are still interlinked. The on-going discussion on the issue of WHOIS, GDPR and the Disclosure Procedure, does make this issue no longer a future security challenge as it was three years ago.
In the recent minority statement issued on August 24, 2020 by GAC, they stated and referenced the importance of this issue to security and stability.
The GAC acknowledges that under applicable data protection rules, including the GDPR, contracted Parties will likely remain responsible for the decision whether to disclose domain name registration data, and may face certain liability risks related to that decision. The GAC understands that contracted Parties have therefore sought to maintain control over the decision whether to disclose domain name registration data. The GAC notes, however, that those decentralized decisions whether to disclose data are largely exempt from challenge and enforcement action, notably via ICANN Compliance. 11 Registration data is important for the security and stability of the DNS and there is a real concern that contracted parties may inadvertently or purposely not properly weigh the public interest for the requestor to obtain such data. ICANN???s CEO recently conveyed this very concern to the European Data Protection Board, pointing out that ???[d]ue to a lack of legal certainty, registrars, as controllers, are likely to evaluate privacy and data protection in absolute terms, without considering other rights and legitimate interests, to avoid possible regulatory sanctions or a judgment against them.???12 Denials of legitimate requests for access to domain name registration data have real consequences.
A review of some of these pages and other resources would allow the SSR2 team to at least ensure we express an appreciation of the issue and not have it removed from the report, but better placed and maybe stated more succinctly (https://whois.icann.org/en/using-whois; https://gac.icann.org/statement/public/gac-minority-statement-epdp-phase2-24...; https://gnso.icann.org/sites/default/files/file/field-file-attach/epdp-phase...)
I would like to propose as we had agreed on the call that we could develop new text that would still capture the issues and the need for Compliance to have a stronger role in this process, which was the basis of this recommendation.
The idea is not to make it a crime consideration but for security measures to be implemented for the security of data - of which data privacy is a subset.
I won???t be able to join tomorrow because I was asked to deliver a course ( this is a one off situation) but available if there is consensus on the way fwd. Cheers Kerry-Ann
On Sep 29, 2020, at 12:56 AM, k claffy <kc@caida.org> wrote:
??? Russ
Yes, that's correct.
We spent a lot of time talking about a lot of things that don't need to be in a report 3 years later.
What does SSR2 want ICANN to do beyond what's here? https://www.icann.org/dataprotectionprivacy I think ICANN is "keeping up with GDPR and similar laws", in fact its CPs are arguably overcommitted to privacy (or at least "not sharing data for free") at the expense of security. So I don't think this advocacy is appropriate. We know these laws are up for interpretation, and that "keeping up w the laws" is not an SSR issue, it's how they are interpreted and accommodated that have SSR implications.
Moreover, why are we asking ICANN to keep with privacy laws in an SSR review? Why not cybercrime laws? Or breach notification laws?
If it's because lack of access to RDAP data is a security challenge, then we should advocate finding a way to overcome that security challenge.
k
On Mon, Sep 28, 2020 at 01:22:46PM -0400, Russ Housley wrote: KC:
You seem to be advocating deleting all of the text related to Rec. 29. Is that right?
We spent a lot of time talking about ICANN org keeping up with GDPR and similar laws. Where do you think that belongs?
Russ
On Sep 23, 2020, at 10:32 AM, Jennifer Bryce <jennifer.bryce@icann.org> wrote:
Dear SSR2 RT members,
As discussed on the call today, please review the proposed markup of rec 29 (see page 59) here: https://docs.google.com/document/d/1WTnaEk2pW0V85FRXk1uUN4O-co7DcDIXb_9_-1MC... <https://docs.google.com/document/d/1WTnaEk2pW0V85FRXk1uUN4O-co7DcDIXb_9_-1MC...>.
Please share any comments/feedback ahead of the meeting next week.
Best, Jennifer
-- Jennifer Bryce Associate Project Manager, Review Support and Accountability Internet Corporation for Assigned Names and Numbers (ICANN)
Skype: jennifer.bryce.icann Email: jennifer.bryce@icann.org <mailto:jennifer.bryce@icann.org>
_______________________________________________ Ssr2-review mailing list Ssr2-review@icann.org <mailto:Ssr2-review@icann.org> https://mm.icann.org/mailman/listinfo/ssr2-review <https://mm.icann.org/mailman/listinfo/ssr2-review>
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy <https://www.icann.org/privacy/policy>) and the website Terms of Service (https://www.icann.org/privacy/tos <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.
_______________________________________________ Ssr2-review mailing list Ssr2-review@icann.org https://mm.icann.org/mailman/listinfo/ssr2-review
_______________________________________________ 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.
This letter from Goran might be of interest to the team, regarding the GDPR law obligations of the ICANN https://www.icann.org/en/system/files/correspondence/marby-to-viola-et-al-02... Published on the correspondence page: https://www.icann.org/resources/pages/correspondence Best, Danko Jevtović -----Original Message----- From: Ssr2-review <ssr2-review-bounces@icann.org> On Behalf Of k claffy Sent: Sunday, October 4, 2020 11:45 PM To: Kerry-Ann Barrett <kerryann.barrett@gmail.com> Cc: ICANN SSR2 <ssr2-review@icann.org> Subject: Re: [Ssr2-review] SSR2 action item: Review rec 29 markup Kerry-Ann, Thanks. The text you have below mostly makes sense, but the GAC missed my crucial point, while ICANN obliquely makes it in response. Those holding registration data are not qualified to "properly weigh the public interest" for access to private data. Nor is ICANN able to sufficiently represent the public interest in negotiations with them; the conflict of interest is overwhelming. So framing this recommendation around "ICANN should stay abreast of the laws around the world" makes no sense to me. I believe it is Europe (and any other government who wants mandatory access to this data under specific circumstances) who need their laws to catch up with reality on the ground. This is the primary lesson of the EPDP -- ICANN process will not thread this needle. I think the sentiments below belong in a section on access to registration data. As soon as someone lets me know where i can put text into that section, I'll work on it. It is not a good use of SSR2 time to continue this conversation until that section is done. k On Wed, Sep 30, 2020 at 11:04:28PM -0400, Kerry-Ann Barrett wrote:
Dear KC Sorry for the late reply.
I wanted to have given the opportunity to the other team members to respond but also wanted to reiterate, that while I agreed the current text and placement of the text needed to be re-written and updated, the issue of privacy and security are still interlinked. The on-going discussion on the issue of WHOIS, GDPR and the Disclosure Procedure, does make this issue no longer a future security challenge as it was three years ago.
In the recent minority statement issued on August 24, 2020 by GAC, they stated and referenced the importance of this issue to security and stability.
The GAC acknowledges that under applicable data protection rules, including the GDPR, contracted Parties will likely remain responsible for the decision whether to disclose domain name registration data, and may face certain liability risks related to that decision. The GAC understands that contracted Parties have therefore sought to maintain control over the decision whether to disclose domain name registration data. The GAC notes, however, that those decentralized decisions whether to disclose data are largely exempt from challenge and enforcement action, notably via ICANN Compliance. 11 Registration data is important for the security and stability of the DNS and there is a real concern that contracted parties may inadvertently or purposely not properly weigh the public interest for the requestor to obtain such data. ICANN???s CEO recently conveyed this very concern to the European Data Protection Board, pointing out that ???[d]ue to a lack of legal certainty, registrars, as controllers, are likely to evaluate privacy and data protection in absolute terms, without considering other rights and legitimate interests, to avoid possible regulatory sanctions or a judgment against them.???12 Denials of legitimate requests for access to domain name registration data have real consequences.
A review of some of these pages and other resources would allow the SSR2 team to at least ensure we express an appreciation of the issue and not have it removed from the report, but better placed and maybe stated more succinctly (https://whois.icann.org/en/using-whois; https://gac.icann.org/statement/public/gac-minority-statement-epdp-phase2-24...; https://gnso.icann.org/sites/default/files/file/field-file-attach/epdp-phase...)
I would like to propose as we had agreed on the call that we could develop new text that would still capture the issues and the need for Compliance to have a stronger role in this process, which was the basis of this recommendation.
The idea is not to make it a crime consideration but for security measures to be implemented for the security of data - of which data privacy is a subset.
I won???t be able to join tomorrow because I was asked to deliver a course ( this is a one off situation) but available if there is consensus on the way fwd. Cheers Kerry-Ann
On Sep 29, 2020, at 12:56 AM, k claffy <kc@caida.org> wrote:
??? Russ
Yes, that's correct.
We spent a lot of time talking about a lot of things that don't need to be in a report 3 years later.
What does SSR2 want ICANN to do beyond what's here? https://www.icann.org/dataprotectionprivacy I think ICANN is "keeping up with GDPR and similar laws", in fact its CPs are arguably overcommitted to privacy (or at least "not sharing data for free") at the expense of security. So I don't think this advocacy is appropriate. We know these laws are up for interpretation, and that "keeping up w the laws" is not an SSR issue, it's how they are interpreted and accommodated that have SSR implications.
Moreover, why are we asking ICANN to keep with privacy laws in an SSR review? Why not cybercrime laws? Or breach notification laws?
If it's because lack of access to RDAP data is a security challenge, then we should advocate finding a way to overcome that security challenge.
k
On Mon, Sep 28, 2020 at 01:22:46PM -0400, Russ Housley wrote: KC:
You seem to be advocating deleting all of the text related to Rec. 29. Is that right?
We spent a lot of time talking about ICANN org keeping up with GDPR and similar laws. Where do you think that belongs?
Russ
On Sep 23, 2020, at 10:32 AM, Jennifer Bryce <jennifer.bryce@icann.org> wrote:
Dear SSR2 RT members,
As discussed on the call today, please review the proposed markup of rec 29 (see page 59) here: https://docs.google.com/document/d/1WTnaEk2pW0V85FRXk1uUN4O-co7DcDIXb_9_-1MC... <https://docs.google.com/document/d/1WTnaEk2pW0V85FRXk1uUN4O-co7DcDIXb_9_-1MC...>.
Please share any comments/feedback ahead of the meeting next week.
Best, Jennifer
-- Jennifer Bryce Associate Project Manager, Review Support and Accountability Internet Corporation for Assigned Names and Numbers (ICANN)
Skype: jennifer.bryce.icann Email: jennifer.bryce@icann.org <mailto:jennifer.bryce@icann.org>
_______________________________________________ Ssr2-review mailing list Ssr2-review@icann.org <mailto:Ssr2-review@icann.org> https://mm.icann.org/mailman/listinfo/ssr2-review <https://mm.icann.org/mailman/listinfo/ssr2-review>
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy <https://www.icann.org/privacy/policy>) and the website Terms of Service (https://www.icann.org/privacy/tos <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.
_______________________________________________ Ssr2-review mailing list Ssr2-review@icann.org https://mm.icann.org/mailman/listinfo/ssr2-review
_______________________________________________ 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.
Ssr2-review mailing list Ssr2-review@icann.org https://mm.icann.org/mailman/listinfo/ssr2-review _______________________________________________ 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.
Danko, I have a question on one of your comments. I wonder if we can discuss on the call tomorrow: The new Registry Agreement wasnt part of the PDP, but it was part of the implementation discussion on the Application Guidebook. The community reviewed the draft RA several times. I believe that SSR2-RT recommendation would be more impactful if problem statements are more based on the facts. I'm trying to figure out what is the false statement you believe is in the document. This comment doesn't seem inconsistent with the sentence it's pointing to. k
Yes, happy to discuss. I've just added a comment in the doc. "My only point is about readers of the report, if the team writes that negotiations where closed they might not understand the process, and the communities' role in then-new RA." I undestand that RA process was more comlicated that "closed negotiations", and that the comminity had a role. D -----Original Message----- From: k claffy <kc@caida.org> Sent: Thursday, November 5, 2020 12:49 AM To: danko.jevtovic@board.icann.org Cc: 'ICANN SSR2' <ssr2-review@icann.org> Subject: Re: [Ssr2-review] SSR2 action item: Review rec 29 markup Danko, I have a question on one of your comments. I wonder if we can discuss on the call tomorrow: The new Registry Agreement wasnt part of the PDP, but it was part of the implementation discussion on the Application Guidebook. The community reviewed the draft RA several times. I believe that SSR2-RT recommendation would be more impactful if problem statements are more based on the facts. I'm trying to figure out what is the false statement you believe is in the document. This comment doesn't seem inconsistent with the sentence it's pointing to. k
participants (5)
-
danko.jevtovic＠board.icann.org -
Jennifer Bryce -
k claffy -
Kerry-Ann Barrett -
Russ Housley