[Gnso-epdp-team] Proposal Regarding Appendix C - Data Processing Requirements

Margie Milam margiemilam at fb.com
Tue Sep 11 01:52:19 UTC 2018


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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20180911/c7bbd6ca/attachment.html>

More information about the Gnso-epdp-team mailing list