[Gnso-epdp-team] Proposal Regarding Appendix C - Data Processing Requirements
kavouss.arasteh at gmail.com
Tue Sep 11 07:15:30 UTC 2018
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
Sent from my iPhone
> On 11 Sep 2018, at 03:52, Margie Milam <margiemilam at fb.com> wrote:
> 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.
> Gnso-epdp-team mailing list
> Gnso-epdp-team at icann.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gnso-epdp-team