Proposal Regarding Appendix C - Data Processing Requirements
Hi- With regard Appendix C- I was asked to explain why this Appendix should be retained, and identify whether there are sections that could be deleted. We think that some portions should be retained, some sections could be deleted, and, we propose one additional section. Rationale for Retention of Appendix C In general, Appendix C contains a commitment to processing personal data in accordance with the principles laid out in the Appendix that are not included elsewhere in the Temporary Specification. Some of these sections provide the specificity needed to apply GDPR to the different activities identified in the matrix. It’s not sufficient to say that the Appendix is not needed because the controllers/processors will simply comply with GDPR, because there are different interpretations of how GDPR applies to RDDS/WHOIS data. Keeping Appendix C will ensure that there is transparency and accountability for the broader ICANN community, as well as the registrants, regarding what is expected by controllers, processors, and third party accessors with legitimate purposes. Sections to Delete or Rewrite to be More Specific: I agree with James that some sections in Appendix C lack sufficient detail for how GDPR applies to RDDS/WHOIS, and seem to be merely recitals of GDPR. These could be deleted or be rewritten to be more specific. Examples are: Sections 3.1.1-3.1.6, 3.2, 3.3, 3.6, 3.7., 3.10 & 3.11. Sections to Retain: * Section 1 * Section 2 – Replace it with something like – “processing will take place in accordance with the purposes described in Section 4 of the Temp. Spec.” * Section 3 – * 3.1 & 3.9: Replace references to GDPR with “applicable data protection law” * Section 3.4 – ICANN should clarify what types of records should be maintained with regard to RDDS/WHOIS records * Section 3.5 – Replace with a commitment to provide a standard notice to be developed by ICANN that is concise, transparent, plain language, etc. for RDDS/WHOIS. * Section 3.8 – Delete the specific operational details in 3.8.1, but retain the high level principles in the first few sentences, ending the paragraph with “….alteration or disclosure.” In the implementation stage, ICANN should identify specific operational requirements appropriate for the RDDS/WHOIS data, and include them in the applicable contract. Additional Terms for Appendix C: There should be standard terms applicable to the Third parties who access non-public data, similar to requirements in Section 1. Just like RAA Section 3.7.7’s requirements for registration agreements with registrants, standard access agreement terms should be specified in the RAA to apply to the 3rd parties who access the data (specify their legitimate purposes for accessing the data, agree that they won’t use that data in a manner incompatible with those purposes, etc.). Without standard T&Cs, each controller/processer could come up with its own access agreement that is either too lax or too onerous. I’ll be happy to talk about this more tomorrow. Margie
Hi Margie: Very thoughtful. In the spirit of giving people time to dwell on it before discussion, can: You take 5 mins to present this during the meeting You clarifying questions only (no, "I am for it" or "against it") We resume the appendix C discussion at the appropriate time Best regards, Kurt
On Sep 10, 2018, at 6:52 PM, Margie Milam <margiemilam@fb.com> wrote:
Hi-
With regard Appendix C- I was asked to explain why this Appendix should be retained, and identify whether there are sections that could be deleted. We think that some portions should be retained, some sections could be deleted, and, we propose one additional section.
Rationale for Retention of Appendix C
In general, Appendix C contains a commitment to processing personal data in accordance with the principles laid out in the Appendix that are not included elsewhere in the Temporary Specification. Some of these sections provide the specificity needed to apply GDPR to the different activities identified in the matrix. It’s not sufficient to say that the Appendix is not needed because the controllers/processors will simply comply with GDPR, because there are different interpretations of how GDPR applies to RDDS/WHOIS data. Keeping Appendix C will ensure that there is transparency and accountability for the broader ICANN community, as well as the registrants, regarding what is expected by controllers, processors, and third party accessors with legitimate purposes.
Sections to Delete or Rewrite to be More Specific: I agree with James that some sections in Appendix C lack sufficient detail for how GDPR applies to RDDS/WHOIS, and seem to be merely recitals of GDPR. These could be deleted or be rewritten to be more specific. Examples are: Sections 3.1.1-3.1.6, 3.2, 3.3, 3.6, 3.7., 3.10 & 3.11.
Sections to Retain: Section 1 Section 2 – Replace it with something like – “processing will take place in accordance with the purposes described in Section 4 of the Temp. Spec.” Section 3 – 3.1 & 3.9: Replace references to GDPR with “applicable data protection law” Section 3.4 – ICANN should clarify what types of records should be maintained with regard to RDDS/WHOIS records Section 3.5 – Replace with a commitment to provide a standard notice to be developed by ICANN that is concise, transparent, plain language, etc. for RDDS/WHOIS. Section 3.8 – Delete the specific operational details in 3.8.1, but retain the high level principles in the first few sentences, ending the paragraph with “….alteration or disclosure.” In the implementation stage, ICANN should identify specific operational requirements appropriate for the RDDS/WHOIS data, and include them in the applicable contract.
Additional Terms for Appendix C: There should be standard terms applicable to the Third parties who access non-public data, similar to requirements in Section 1. Just like RAA Section 3.7.7’s requirements for registration agreements with registrants, standard access agreement terms should be specified in the RAA to apply to the 3rd parties who access the data (specify their legitimate purposes for accessing the data, agree that they won’t use that data in a manner incompatible with those purposes, etc.). Without standard T&Cs, each controller/processer could come up with its own access agreement that is either too lax or too onerous.
I’ll be happy to talk about this more tomorrow.
Margie
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org <mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team <https://mm.icann.org/mailman/listinfo/gnso-epdp-team>
Dear Margie Thank you very much for your comment on Appendix C and the analysis made on what sections/ paragraphs to be retained with or without amendments and which paragraphs/ sections to be deleted as well as your suggestion to add a new section Having said that I wonder in making the analysis and suggesting a course f action you have also reviewed detailed analysis made by registry in Which they suggests to totally delete Appendix C arguing that many elements in that Appendix were taken or paraphrased parts of Articles 5 and 6 of GPDR with some anticipation of application of Article 28 While I fully agree with your argument that simple reference to Articles of GPDR is not sufficient as you have correctly given sound reasons ,I think we need to consider all proposals and reflect the most appropriate course of actions . Perhaps Kurt may which to include few other persons collaborating with you to suggest a draft modification of that Appendix taking into account all received inputs including but not limited those from registry and registrar Regards Kavouss Sent from my iPhone
On 11 Sep 2018, at 03:52, Margie Milam <margiemilam@fb.com> wrote:
Hi-
With regard Appendix C- I was asked to explain why this Appendix should be retained, and identify whether there are sections that could be deleted. We think that some portions should be retained, some sections could be deleted, and, we propose one additional section.
Rationale for Retention of Appendix C
In general, Appendix C contains a commitment to processing personal data in accordance with the principles laid out in the Appendix that are not included elsewhere in the Temporary Specification. Some of these sections provide the specificity needed to apply GDPR to the different activities identified in the matrix. It’s not sufficient to say that the Appendix is not needed because the controllers/processors will simply comply with GDPR, because there are different interpretations of how GDPR applies to RDDS/WHOIS data. Keeping Appendix C will ensure that there is transparency and accountability for the broader ICANN community, as well as the registrants, regarding what is expected by controllers, processors, and third party accessors with legitimate purposes.
Sections to Delete or Rewrite to be More Specific: I agree with James that some sections in Appendix C lack sufficient detail for how GDPR applies to RDDS/WHOIS, and seem to be merely recitals of GDPR. These could be deleted or be rewritten to be more specific. Examples are: Sections 3.1.1-3.1.6, 3.2, 3.3, 3.6, 3.7., 3.10 & 3.11.
Sections to Retain: Section 1 Section 2 – Replace it with something like – “processing will take place in accordance with the purposes described in Section 4 of the Temp. Spec.” Section 3 – 3.1 & 3.9: Replace references to GDPR with “applicable data protection law” Section 3.4 – ICANN should clarify what types of records should be maintained with regard to RDDS/WHOIS records Section 3.5 – Replace with a commitment to provide a standard notice to be developed by ICANN that is concise, transparent, plain language, etc. for RDDS/WHOIS. Section 3.8 – Delete the specific operational details in 3.8.1, but retain the high level principles in the first few sentences, ending the paragraph with “….alteration or disclosure.” In the implementation stage, ICANN should identify specific operational requirements appropriate for the RDDS/WHOIS data, and include them in the applicable contract.
Additional Terms for Appendix C: There should be standard terms applicable to the Third parties who access non-public data, similar to requirements in Section 1. Just like RAA Section 3.7.7’s requirements for registration agreements with registrants, standard access agreement terms should be specified in the RAA to apply to the 3rd parties who access the data (specify their legitimate purposes for accessing the data, agree that they won’t use that data in a manner incompatible with those purposes, etc.). Without standard T&Cs, each controller/processer could come up with its own access agreement that is either too lax or too onerous.
I’ll be happy to talk about this more tomorrow.
Margie
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team
participants (3)
-
Arasteh -
Kurt Pritz -
Margie Milam