[NCSG-PC] Fw: EPDP On the Temporary Specification for gTLD Registration Data - Public Comment Proceeding Input Form

[Ayden Férdeline]

Hi all,

For archival purposes, below is our submission re: Initial Report comment.

I have also exported our Google Doc, where we drafted the comment, to PDF and have attached it to this email.

Best, Ayden

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, 22 December 2018 09:26, Google Forms <forms-receipts-noreply at google.com> wrote:

> [Google Forms]
>
> Thanks for filling out [EPDP On the Temporary Specification for gTLD Registration Data - Public Comment Proceeding Input Form](https://docs.google.com/forms/d/e/1FAIpQLSefRyo0n6_G29cMYZZc1hK-zshjIpEeb7rIZLOo-RKnfXbH0Q/viewform?usp=mail_form_link)
>
> Here's what we got from you:
>
> [Edit response](https://docs.google.com/forms/d/e/1FAIpQLSefRyo0n6_G29cMYZZc1hK-zshjIpEeb7rIZLOo-RKnfXbH0Q/viewform?edit2=2_ABaOnuf44eTtWR4tN4LIunQ7FxCf7j59TCRuL0lVIunCwExUSV446IDe8bTO_Kg)
>
> EPDP On the Temporary Specification for gTLD Registration Data - Public Comment Proceeding Input Form
>
> Email address
>
> *
> icann at ferdeline.com
>
> Important Instructions - PLEASE READ BEFORE PROCEEDING
>
> This Public Comment forum seeks community feedback on the Initial Report published by the Expedited Policy Development Process (EPDP) Team on the Temporary Specification for gTLD Registration Data. This is a new format for collecting public comment. It seeks to: -- Clearly link comments to specific sections of the initial report -- Encourage commenters to provide reasoning or rationale for their opinions -- Enable the sorting of comment so that the EPDP team can more easily read all the comments on any one topic There is no obligation to complete all sections within this form – respond to as many or as few questions as desired. Additionally, there is the opportunity to provide comments on the general content of the Initial Report or on new issues not raised by the Initial Report. To preview all questions in the Google Form, please refer to a Word version of this form here here's the link to the Word doc: [https://gnso.icann.org/en/issues/epdp-gtld-registration-data-specs-public-comment-input-form-21nov18-en.docx](https://www.google.com/url?q=https://gnso.icann.org/en/issues/epdp-gtld-registration-data-specs-public-comment-input-form-21nov18-en.docx&sa=D&ust=1545434796395000&usg=AFQjCNETWEKQbXw7SeHY8qrsfUgbWQeMlg). As you review the "Questions for Community Input" in the Initial Report, you will note that there is not a 1:1 correspondence with the questions asked in the Public Comment format. This is because, in some instances, the "Questions for Community Input" have been divided into multi-part questions so that feedback on these questions would be clear. The Initial Report and Comment Forum have been reviewed to ensure that all the "Questions for Community Input" have been addressed in this Comment Forum. It is important that your comments include rationale (i.e., by answering the “rationale” question in each section). This is not a vote. The EPDP team is interested in your reasoning so that the conclusions reached and the issues discussed by the team can be tested against the reasoning of others. (This is much more helpful than comments that simply “agree” or “disagree”). You can easily navigate from page to page in the form. There is a table of contents below so that you can “fast forward” to the desired section by hitting “next” at the bottom of each page. To preview this entire form in Word format, see the link to the Word doc: [https://gnso.icann.org/en/issues/epdp-gtld-registration-data-specs-public-comment-input-form-21nov18-en.docx](https://www.google.com/url?q=https://gnso.icann.org/en/issues/epdp-gtld-registration-data-specs-public-comment-input-form-21nov18-en.docx&sa=D&ust=1545434796395000&usg=AFQjCNETWEKQbXw7SeHY8qrsfUgbWQeMlg). To stop and save your work for later, you MUST (to avoid losing your work): 1. Provide your email address above in order to receive a copy of your submitted responses; 2. Click "Submit" at the end of the Google Form (the last question on every page allows you to quickly jump to the end of the Google Form to submit); 3. After you click "Submit," you will receive an email to the above-provided email address; within the email, click the "Edit Response" button at top of the email; 4. After you click the "Edit Response" button, you will be directed to the Google Form to return and complete; 5. Repeat the above steps 2-4 every time you wish to quit the form and save your progress. NOTES: -- Please refer to the specific recommendation and relevant section or page number of the Initial Report for additional details and context about each recommendation. Where applicable, you are encouraged to reference sections in the report for ease of the future review by the EPDP Team. --Your comments should take into account scope of the EPDP as described by the Charter and General Data Protection Regulation (GDPR) compliance. --For transparency purposes, all comments submitted to the Public Comment forum will be displayed publicly via an automatically-generated Google Spreadsheet. Email addresses provided by commenters will not be displayed. --To maximize the visibility of your comments to the EPDP Team, please submit your comments via this form only. If you are unable to use this form, alternative arrangements can be made. --Please note you may encounter a character limit in your responses when editing a previous submission. (There are no character limits when making a first-time submission.) In the event you encounter a character limit, you may send an email to policy-staff at icann.org, and the EPDP Support Staff will assist you with your response. --The final date of the public comment proceeding is 23:59 UTC on 21 December 2018. Any comments received after that date will not be reviewed / discussed by the EPDP Team.
>
> Table of Contents
>
> Page 1: Email Address, Important Instructions, Table of Contents Page 2: Consent & Authorization Page 3: Section 3, Part 1: Purposes for Processing Registration Data • Recommendation #1 Page 4: Section 3, Part 1: Purposes for Processing Registration Data (Continued) • Recommendations #2-3 Page 5: Section 3, Part 2: Required Data Processing Activities • Recommendations #4-13 Page 6: Section 3, Part 3: Data Processing Terms, i.e., roles and responsibilities of parties • Recommendation #14 Page 7: Section 3, Part 4: Updates to Other Consensus Policies • Recommendations #15-20 Page 8: Section 3, Other Recommendations • Recommendations #21-22 Page 9: Other Comments & Submission
>
> Consent & Authorization
>
> By submitting my personal data, I agree that my personal data will be processed in accordance with the ICANN Privacy Policy ([https://www.icann.org/privacy/policy](https://www.google.com/url?q=https://www.icann.org/privacy/policy&sa=D&ust=1545434796396000&usg=AFQjCNHruKQyRE9bWk6naJkGMJ1wt6XqpA)), and agree to abide by the website Terms of Service ([https://www.icann.org/privacy/tos](https://www.google.com/url?q=https://www.icann.org/privacy/tos&sa=D&ust=1545434796396000&usg=AFQjCNHXEXDS2O93Q6O5Up1w8L3I-dvMTw)).
>
> Please provide your name:
>
> *
>
> Ayden Férdeline
>
> Please provide your affiliation
>
> *
>
> Non-Commercial Stakeholders Group
>
> Are you providing input on behalf of another group (e.g., organization, company, government)?
>
> *
>
> - Yes
>
> - No
>
> If yes, please explain:
>
> Non-Commercial Stakeholders Group
>
> Save Your Progress
>
> Do you want to save your progress and quit for now? You will be able to return to the form to complete at a later time.
>
> - Yes
>
> - No, I would like to continue to the next section
>
> Section 3, Part 1: Purposes for Processing Registration Data
>
> The EPDP team was tasked with determining whether the ICANN and Contracted Party Purposes for Processing Registration Data listed in the Temporary Specification are appropriate and if additional “Purposes” are required. The Team developed DNS requirements, the data requirements, and mapped data flows in order to identify these purposes.
>
> Recommendation #1: Purposes for Processing Registration Data
>
> The EPDP Team recommends that the following purposes for processing gTLD Registration Data form the basis of the new ICANN policy: Note that for each of the below purposes, the EPDP Team has also identified: (i) the related processing activities; (ii) the corresponding lawful basis for each processing activity; and (iii) the data controllers and processors involved in each processing activity. For more information regarding the above, please refer to the Data Elements Workbooks which can be found in the Annex D of the Initial Report.
>
> PURPOSE 1 FOR PROCESSING REGISTRATION DATA:
>
> AS SUBJECT TO REGISTRY AND REGISTRAR TERMS, CONDITIONS AND POLICIES, AND ICANN CONSENSUS POLICIES: (I) TO ESTABLISH THE RIGHTS OF A REGISTERED NAME HOLDER IN A REGISTERED NAME; (II) TO ENSURE THAT A REGISTERED NAME HOLDER MAY EXERCISE ITS RIGHTS IN THE USE AND DISPOSITION OF THE REGISTERED NAME; AND (III) TO ACTIVATE A REGISTERED NAME AND ALLOCATE IT TO THE REGISTERED NAME HOLDER
>
> Please choose your level of support for Purpose 1:
>
> - Support Purpose as written
>
> - Support Purpose intent with wording change
>
> - Significant change required: changing intent and wording
>
> - Purpose should be deleted
>
> If your response requires an edit or deletion of Purpose #1, please indicate the revised wording here (keep in mind that "Purposes" must be GDPR compliant).
>
> Please provide rationale for your recommendation.
>
> An official record of the Registered Name Holder’s (RNH) data is needed to assign exclusive control of it to the RNH and to enable the domain name registrant to assert its rights over a domain name.
>
> PURPOSE 2 FOR PROCESSING REGISTRATION DATA
>
> MAINTAINING THE SECURITY, STABILITY, AND RESILIENCY OF THE DOMAIN NAME SYSTEM IN ACCORDANCE WITH ICANN'S MISSION THROUGH THE ENABLING OF LAWFUL ACCESS FOR LEGITIMATE THIRD-PARTY INTERESTS TO DATA ELEMENTS COLLECTED FOR THE OTHER PURPOSES IDENTIFIED HEREIN
>
> Choose your level of support of Purpose #2:
>
> - Support Purpose as written
>
> - Support Purpose intent with wording change
>
> - Significant change required: changing intent and wording
>
> - Purpose should be deleted
>
> If your response requires an edit or deletion of Purpose #2, please indicate the revised wording here (keep in mind that "Purposes" must be GDPR compliant).
>
> Please provide rationale for your recommendation.
>
> Purpose 2 is vague and does not specify what is involved in “maintaining the security, stability, and resiliency of the domain name system in accordance with ICANN’s mission”. The NCSG has held the position from the start of the discussion on this purpose that what is interpreted to be within the scope of ICANN’s mission in relation to SSR needs to be identified in order for this purpose to hold any true meaning. When the topic had been raised, there was significant disagreement within the EPDP on what the interpretation of the bylaws relevant to SSR includes, thus leading to disagreement on what the scope of this purpose should include. The current vague wording of this purpose seems to intentionally attempt to bypass this discussion (one on which there is likely to be no consensus), and leave the interpretation of the scope of ICANN’s SSR duties to the implementation of this policy recommendation. The NCSG does not find this to be appropriate. Note that the need to be specific in identifying the scope of ICANN’s mission when defining purposes was clearly communicated to the GNSO Next-Generation gTLD RDS to Replace WHOIS PDP WG by EU data protection experts in May 2017, when they said: “Purpose has to be defined in advance of the data processing. Purposes have to have a legitimate aim and the processing has to be necessary and proportionate to the legitimate aim pursued. Translating this to ICANN means the working group would want to take a look into ICANN role and its mission statement and separate out the legitimate data processing purposes, and determine which data are necessary for which purpose.” [1] [1] https://community.icann.org/download/attachments/64078601/ICANN58-DataProtectionExpert-Responses-7April2017-plus-Intro.pdf
>
> PURPOSE 3 FOR PROCESSING REGISTRATION DATA
>
> ENABLE COMMUNICATION WITH AND/OR NOTIFICATION TO THE REGISTERED NAME HOLDER AND/OR THEIR DELEGATED AGENTS OF TECHNICAL AND/OR ADMINISTRATIVE ISSUES WITH A REGISTERED NAME
>
> Choose your level of support of Purpose #3:
>
> - Support Purpose as written
>
> - Support Purpose intent with wording change
>
> - Significant change required: changing intent and wording
>
> - Purpose should be deleted
>
> If your response requires an edit or deletion of Purpose #3, please indicate the revised wording here (keep in mind that "Purposes" must be GDPR compliant).
>
> Please provide rationale for your recommendation.
>
> This is a legitimate purpose that is consistent with ICANN’s mission. Notification and communication with the Registered Name Holder for purposes of technical and/or administrative issue handling is helpful and necessary for both registrants and registrars.
>
> PURPOSE 4 FOR PROCESSING REGISTRATION DATA
>
> PROVIDE MECHANISMS FOR SAFEGUARDING REGISTERED NAME HOLDERS' REGISTRATION DATA IN THE EVENT OF A BUSINESS OR TECHNICAL FAILURE, OR OTHER UNAVAILABILITY OF A REGISTRAR OR REGISTRY OPERATOR
>
> Choose your level of support of Purpose #4:
>
> - Support Purpose as written
>
> - Support Purpose intent with wording change
>
> - Significant change required: changing intent and wording
>
> - Purpose should be deleted
>
> If your response requires an edit or deletion of Purpose #4, please indicate the revised wording here (keep in mind that "Purposes" must be GDPR compliant).
>
> Please provide rationale for your recommendation.
>
> It is legitimate to collect and process data for this purpose, as it supports the rights and interests of the registrant.
>
> PURPOSE 5 FOR PROCESSING REGISTRATION DATA
>
> HANDLE CONTRACTUAL COMPLIANCE MONITORING REQUESTS, AUDITS, AND COMPLAINTS SUBMITTED BY REGISTRY OPERATORS, REGISTRARS, REGISTERED NAME HOLDERS, AND OTHER INTERNET USERS
>
> Choose your level of support of Purpose #5:
>
> - Support Purpose as written
>
> - Support Purpose intent with wording change
>
> - Significant change required: changing intent and wording
>
> - Purpose should be deleted
>
> If your response requires an edit or deletion of Purpose #5, please indicate the revised wording here (keep in mind that "Purposes" must be GDPR compliant).
>
> Please provide the rationale for your recommendation.
>
> Authoritative data about the registrant, the registration, and its contact details can be required for assessing compliance with ICANN policies and for following up on complaints. In particular, ICANN org itself may need to process this data to monitor compliance with its policies. As long as processing of specific data that is fit-for-purpose is strictly restricted to parties who need it for this defined purpose, the NCSG can support Purpose 5.
>
> PURPOSE 6 FOR PROCESSING REGISTRATION DATA
>
> COORDINATE, OPERATIONALIZE, AND FACILITATE POLICIES FOR RESOLUTION OF DISPUTES REGARDING OR RELATING TO THE REGISTRATION OF DOMAIN NAMES (AS OPPOSED TO THE USE OF SUCH DOMAIN NAMES), NAMELY, THE UDRP, URS, PDDRP, RRDRP, AND FUTURE DEVELOPED DOMAIN NAME REGISTRATION-RELATED DISPUTE PROCEDURES FOR WHICH IT IS ESTABLISHED THAT THE PROCESSING OF PERSONAL DATA IS NECESSARY.
>
> Choose your level of support of Purpose #6:
>
> - Support Purpose as written
>
> - Support Purpose intent with wording change
>
> - Significant change required: changing intent and wording
>
> - Purpose should be deleted
>
> If your response requires an edit or deletion of Purpose #6, please indicate the revised wording here (keep in mind that "Purposes" must be GDPR compliant).
>
> The NCSG requests that the first sentence of Purpose 6 be streamlined by replacing “coordinate, operationalize, and facilitate” with “operationalize”.
>
> Please provide rationale for your recommendation.
>
> Authoritative data about the registrant, the registration, and contact details can be required for executing ICANN’s dispute resolution policies against the registrant itself. As long as disclosure of the private data is restricted to the parties who need it for this defined purpose, the NCSG can support Purpose 6.
>
> PURPOSE 7 FOR PROCESSING REGISTRATION DATA
>
> ENABLING VALIDATION TO CONFIRM THAT REGISTERED NAME HOLDER MEETS OPTIONAL GTLD REGISTRATION POLICY ELIGIBILITY CRITERIA VOLUNTARILY ADOPTED BY THE REGISTRY OPERATOR
>
> Choose your level of support of Purpose #7:
>
> - Support Purpose as written
>
> - Support Purpose intent with wording change
>
> - Significant change required: changing intent and wording
>
> - Purpose should be deleted
>
> If your response requires an edit or deletion of Purpose #7, please indicate the revised wording here (keep in mind that "Purposes" must be GDPR compliant).
>
> The NCSG believes this purpose should be deleted in its entirety. Editing should not be considered.
>
> Please provide rationale for your recommendation.
>
> Data required for validation could include a wide range of sensitive personal data enabling the identification of individuals or protected groups. There is absolutely no need for this kind of data to be in the RDDS. Registry Operators can and currently do collect and validate this data on their own. Since each specialized registry (including brand registries) have different criteria for validation, this purpose risks opening the door to potentially hundreds of new data elements. Further, it is dangerous and inappropriate for this data to be placed in a global directory that can be accessed by third parties. gTLD validation processes should be limited to individual registries only, and the data needed to do that should not be placed in the RDDS.
>
> Enter additional comments to Recommendation #1.
>
> Question #1 for Community Input: Purposes for Processing Registration Data
>
> If you recommend additional purposes for processing registration data, please enumerate and write them here, keeping in mind compliance with GDPR.
>
> No additional purposes are required. The addition of new data elements to the RDDS is beyond the scope of the EPDP Team’s work. The EPDP Team has a narrow charter, and was not chartered to create new features and purposes for processing gTLD Registration Data. The NCSG believes such an issue is best taken up in the GNSO Next-Generation RDS to Replace WHOIS PDP, should this PDP Working Group ever be reconvened, or alternatively to be addressed by any PDP Working Group that replaces it in determining RDS functions that fall outside of the scope of this EPDP.
>
> For each additional purpose identified above, please enumerate and provide rationale for each of them.
>
> Save Your Progress
>
> Do you want to save your progress and quit for now? You will be able to return to the form to complete at a later time.
>
> - Yes
>
> - No, I wish to continue to the next section
>
> Section 3, Part 1: Purposes for Processing Registration Data (Continued)
>
> Recommendation #2: Standardized Access
>
> Per the EPDP Team Charter, the EPDP Team is committed to considering a system for Standardized Access to non-public Registration Data once the gating questions in the charter have been answered. This will include addressing questions such as: • What are the legitimate purposes for third parties to access registration data? • What are the eligibility criteria for access to non-public Registration data? • Do those parties/groups consist of different types of third-party requestors? • What data elements should each user/party have access to? In this context, amongst others, disclosure in the course of intellectual property infringement and DNS abuse cases will be considered.
>
> Choose your level of support of Recommendation #2:
>
> - Support recommendation as written
>
> - Support intent of recommendation with edits
>
> - Intent and wording of this recommendation requires amendment
>
> - Delete recommendation
>
> Do you recommend a change to the wording of Recommendation 2? If so, please indicate proposed edits here.
>
> The NCSG asks that the term “Standardized Access to nonpublic Registration Data” be replaced with the term, “Lawful disclosure of personal and sensitive registration data to third parties with legitimate interests.”
>
> Please include the rationale for your answers here.
>
> In essence, Recommendation 2 is simply a restatement of one aspect of the EPDP’s charter. We note that later on in this report, the wording change we proposed here was accepted.
>
> Enter additional comments for Recommendation #2.
>
> Recommendation #3: Contractual Accuracy Requirements
>
> The EPDP Team recommends that requirements related to the accuracy of registration data under the current ICANN contracts and consensus policies shall not be affected by this policy.
>
> Choose your level of support of Recommendation #3:
>
> - Support recommendation as written
>
> - Support intent of recommendation with edits
>
> - Intent and wording of this recommendation requires amendment
>
> - Delete recommendation
>
> Do you recommend a change to Recommendation 3? If so, please indicate proposed edits here.
>
> Please include the rationale for your answers here.
>
> The NCSG supports this recommendation as it is written. We do not support making changes to existing accuracy requirements, as policies regarding accuracy are not within the remit of the Temporary Specification.
>
> Enter any other additional comments or observations you have on Section 3 Part 1 that are not covered by these questions.
>
> Save Your Progress
>
> Do you want to save your progress and quit for now? You will be able to return to the form to complete at a later time.
>
> - Yes
>
> - No, I wish to continue to the next section
>
> Section 3, Part 2: Required Data Processing Activities
>
> Recommendation #4: Data Elements
>
> The EPDP Team recommends that the data elements defined in the data elements workbooks in Annex D are required to be collected by registrars. In the aggregate, this means that the following data elements are to be collected (or automatically generated): Data Elements (Collected and Generated) Note, Data Elements indicated with ** are generated either by the Registrar or the Registry Domain Name** Registry Domain ID** Registrar Whois Server** Registrar URL** Updated Date** Creation Date** Registry Expiry Date** Registrar Registration Expiration Date** Registrar** Registrar IANA ID** Registrar Abuse Contact Email** Registrar Abuse Contact Phone** Reseller** Domain Status** Registry Registrant ID** Registrant Fields: · Name · Organization (optional) · Street · City · State/province · Postal code · Country · Phone · Phone ext (optional) · Fax (optional) · Fax ext (optional) · Email Tech ID (optional) Tech Fields: • Name (optional) • Phone (optional) • Email (optional) Name Server DNSSEC (optional) Name Server IP Address** Last Update of Whois Database** Additional optional data elements as identified by Registry Operator in its registration policy, such as (i) status as Registry Operator Affiliate or Trademark Licensee [.MICROSOFT]; (ii) membership in community [.ECO]; (iii) licensing, registration or appropriate permits (.PHARMACY, .LAW] place of domicile [.NYC]; (iv) business entity or activity [.BANK, .BOT]
>
> Question #2 for Community Input
>
> Do you agree that all these data elements should be collected / generated to achieve the Purposes identified in the Initial Report?
>
> - Yes
>
> - No
>
> If your answer is ‘no’, please enumerate which data elements should not be collected / generated.
>
> The NCSG opposes the inclusion of “Additional optional data elements as identified by Registry Operator in its registration policy.”
>
> Please provide the rationale for your answer.
>
> As noted in our response to Purpose #7, the NCSG opposes the expansion of registration data elements to include potentially unlimited numbers of new data elements reflecting the individual policies of different registry operators.
>
> If you believe additional data elements should be collected / generated, please enumerate which additional elements should be collected / generated.
>
> Please provide the rationale for your answer.
>
> Recommendation #4 Continued: Optional Data Elements
>
> The EPDP Team recommends that the following data elements are optional for the Registered Name Holder (RNH) to provide: • technical contact name • technical contact email and • technical contact phone number The EPDP Team has discussed two definitions of the term “optional” as used in this recommendation: (1) registrars must offer the data field and registrants can decide whether to fill in the field or leave in blank (in which case the query would return the registered name hold data; OR (2) registrars can offer this field at their option
>
> Should the technical contact fields be optional or mandatory (where mandatory means the registrar must offer the fields AND the RNH must fill in information)?
>
> - Optional
>
> - Mandatory
>
> Please provide the rationale for your answer.
>
> The technical contact field is a legacy element that predates the existence of registrars. Currently, the de facto technical contact for all registered domains is the registrar. The name of the registrar and the contact information for the registrar are already included in the Whois data, so there is no need for an additional technical contact. If the Registered Name Holder really wants a different person or organization listed as a Tech-C it should be optional (where optional means that it is optional for the registrar to seek collection of the data, and optional for the Registered Name Holder to provide it upon a request to have it collected). Furthermore, the principle of data minimization suggests that if a data element is only optional, or not necessary for processing activities or to fulfil a contractual requirement to which the data subject is a party; that it should not be collected or further processed. Ideally, these data elements should not be collected at all.
>
> If your answer is 'optional', should registrars be required to offer these technical contact fields?
>
> - Yes
>
> - No
>
> Please provide the rationale for your answer.
>
> Some registrars feel that compliance with the GDPR and its principle of data minimization requires them to eliminate a data field that is not really used. It is best to allow them to navigate the legal risks based on their own judgment. The registrar market is competitive so if there is real consumer demand for this field then registrars can/will offer it.
>
> The EPDP team recommends that contact information for billing and administrative contacts should not be collected. Do you agree that this information should not be collected?
>
> - Yes
>
> - No
>
> Please provide the rationale for your answer.
>
> These are also legacy fields that predate ICANN. They are not needed. Billing contact is almost always the same as Admin and/or Technical contact.
>
> Enter additional comments for Recommendation #4 here.
>
> Recommendation #5: Transmission of Data from Registrar to Registry
>
> The EPDP Team recommends that the specifically-identified data elements under “[t]ransmission of registration data from Registrar to Registry” within the data elements workbooks must be transferred from Registrar to Registry. In the aggregate, these data elements are the same as those in Recommendation #4 for the reasons stated in the Data Workbooks found in Annex D of the Initial Report.
>
> Do you agree that all these data elements should be transferred from the registrar to the registry?
>
> - Yes
>
> - No
>
> If your answer is ‘no’, please enumerate which data elements should not be transferred from the registrar to the registry.
>
> Please provide the rationale for your answer.
>
> Once registration records have been appropriately redacted, then the transmission of the redacted data elements to the registry may be appropriate and legal under the GDPR. However, we note that the registries of ICANN are expressly not required to be in the member states of the European Union or in territories declared “adequate” by the relevant authorities. We have seen many new gTLD registries incorporated in countries which do not have comprehensive data protection laws (and do have strong laws requiring the sharing of data with law enforcement), including the United States. We note that the use of the data of a domain name registration for the prosecution of content, including for moral, ethnic, religious, and especially gender and sexual orientation speech, is growing. The GDPR does not allow us to collect and transmit data elements that will endanger data subjects in jurisdictions to which their personal data and sensitive data could be weaponized against them. Such power over registrant freedoms cannot be delegated to ICANN or ICANN-accredited registries who are not bound by the GDPR, and cannot (even by contract) waive their local obligations to respond to law enforcement demands. Accordingly, the GDPR prohibits the processing of this registrant data -- and similarly, transmission of this registrant data to registries who cannot possibly comply with the GDPR requirements.
>
> Enter additional comments for Recommendation #5 here.
>
> Recommendation #6: Transmission of Data to Data Escrow Providers
>
> 1. The EPDP Team recommends that ICANN Org enter into legally-compliant data processing agreements with the data escrow providers. 2. The EPDP Team recommends updates to the contractual requirements for registries and registrars to transfer data that they process to the data escrow provider to ensure consistency with the data elements workbooks that analyze the purpose to provide mechanisms for safeguarding Registered Name Holders' Registration Data. 3. The data elements workbook that analyzes the purpose to provide mechanisms for safeguarding Registered Name Holders' Registration Data Registration Data contains the specifically-identified data elements the EPDP Team recommends be transferred by Registries and Registrars to data escrow providers (see Annex D, Workbook 4).
>
> Choose your level of support of Recommendation #6:
>
> - Support recommendation as written
>
> - Support intent of recommendation with edits
>
> - Intent and wording of this recommendation requires amendment
>
> - Delete recommendation
>
> If your response requires an edit or deletion of Recommendation #6, please indicate the revised wording here. Additionally, please enumerate which data elements should not be transferred from the registrar/registry to the data escrow provider.
>
> Please provide the rationale for your answer.
>
> Recommendation 6 is an appropriate measure to ensure that all data processing activities in which ICANN engages are compliant with data protection law. Registrars and registries must be given the opportunity to transfer to data escrow providers in countries covered by or deemed “adequate” under GDPR.
>
> Enter additional comments for Recommendation #6 here.
>
> Recommendation #7: Transmission of Data from Registries/Registrars to ICANN Compliance
>
> 1. The EPDP Team recommends that updates are made to the contractual requirements for registries and registrars to transfer to ICANN Compliance the domain name registration data that they process when required/requested, consistent with the data elements workbook that analyzes the purpose to handle contractual compliance monitoring requests, audits, and complaints submitted by Registry Operators, Registrars, Registered Name Holders, and other Internet users (see Annex D, Workbook 5). 2. The data elements workbook that analyzes the purpose to handle contractual compliance monitoring requests, audits, and complaints submitted by Registry Operators, Registrars, Registered Name Holders, and other Internet users contains the specifically-identified data elements the EPDP Team recommends be transferred from registries and registrars to ICANN Compliance (see Annex D, Workbook 5).
>
> Choose your level of support of Recommendation #7:
>
> - Support recommendation as written
>
> - Support intent of recommendation with edits
>
> - Intent and wording of this recommendation requires amendment
>
> - Delete recommendation
>
> Do you agree that all of these data elements should be transferred from the registrar to ICANN?
>
> - Yes
>
> - No
>
> If your answer is ‘no’, please enumerate which data elements should not be transferred from the registrar to ICANN.
>
> See below
>
> Please provide the rationale for your answer.
>
> We answer ‘No’ here only because the NCSG believes that requests by ICANN Compliance should be limited to those elements required to accommodate issues they will deal with at that time. In principle, this could mean that all data elements are required, but not all elements will be needed for other purposes. We wish to underline the principle that compliance requests should not be open-ended fishing expeditions. We note that ICANN Compliance rules should be more subject to review and understanding by the community, and that there are concerns (and reports) that complaints are being used, in part, as harassment and fishing expeditions against registrants. Accordingly, transfer of data elements even to ICANN Compliance should be subject to special evaluation and review -- not automatically done regardless of purposes, scope and scale.
>
> Enter additional comments for Recommendation #7 here.
>
> Recommendation #8: Data Redaction
>
> The EPDP Team recommends that redaction must be applied as follows to the data elements that are collected. Data elements neither redacted nor anonymized must appear in a freely accessible directory. NOT REDACTED Domain Name Registrar Whois Server Registrar URL Updated Date Creation Date Registry Expiry Date Registrar Registration Expiration Date Registrar Registrar IANA ID Registrar Abuse Contact Email Registrar Abuse Contact Phone Reseller Domain Status Registrant Fields • State/province • Country • Anonymized email / link to web form Tech Fields • Anonymized email / link to web form NameServer(s) DNSSEC No Name Server IP Address Last Update of Whois Database REDACTED Registrant Fields • Name • Street • City • Postal code • Phone • Email Tech Fields • Name • Phone • Email UNDECIDED (REDACTED/ NOT REDACTED) • Organization (opt.) Please reference page 14-15 of the Initial Report for details of the data elements.
>
> Do you agree that all of these data elements should be redacted?
>
> - Yes
>
> - No
>
> If your answer is ‘no’, please enumerate the data elements that should not be redacted.
>
> The NCSG requests the redaction of an additional data element: the State/Province field.
>
> Please provide the rationale for your answer.
>
> In nearly all cases, country level data will be sufficient to determine relevant jurisdiction for disputes resolution. When this is not sufficient, parties with legitimate interest can request disclosure. Including the State/Province in public data, in conjunction with other information, may allow identification of individuals by those without a legitimate interest.
>
> The EPDP Team is of divided opinion as to whether "Organization" should be redacted for reasons stated in the Initial Report. Please see the Initial Report, beginning on p. 42. Should the "Organization" field be redacted?
>
> - Yes
>
> - No
>
> Please provide rationale for your answer above.
>
> Many natural persons operate small organizations or businesses and contact data in their domain registration will be indistinguishable from that of an individual residence. Also, some organizations might be targeted merely because of their legal political, religious, or social affiliations. Legal advice provided to the GNSO Next-Generation RDS to replace WHOIS PDP Working Group explained that any data element that assists in making a natural person (RNH) identifiable, in conjunction with other data elements, should be treated as personal information, even if the data element does not appear to be personal information in itself. Combining the “Organization” field with others such as state or city would certainly make a Registered Name Holder more identifiable.
>
> Enter additional comments for Recommendation #8.
>
> Recommendation #9: Organization Field
>
> The EPDP Team recommends that registrars provide further guidance to a Registered Name Holder concerning the information that is to be provided within the Organization field. (For further information, please refer to the Initial Report discussion, beginning on p. 42).
>
> Choose your level of support of Recommendation #9:
>
> - Support recommendation as written
>
> - Support intent of recommendation with edits
>
> - Intent and wording of this recommendation requires amendment
>
> - Delete recommendation
>
> If your response requires an edit or deletion of Recommendation #9, please indicate the revised wording here.
>
> Please provide the rationale for your answer.
>
> “Guidance” is a poor substitute for redaction. At best, “guidance” from registrars will reduce some of the risk of inadvertent or mistaken data about natural persons being placed in the DNS record; but redacting the field will reduce all of it. Redaction provides a much more certain response to the potential problem.
>
> Additional comments for Recommendation #9.
>
> Recommendation #10: Provision of Email Address/Web Form
>
> In relation to facilitating email communication between third parties and the registrant, the EPDP Team recommends that current requirements in the Temporary Specification that specify that a Registrar MUST provide an email address or a web form to facilitate email communication with the relevant contact, but MUST NOT identify the contact email address or the contact itself, remain in place.
>
> Choose your level of support of Recommendation #10:
>
> - Support recommendation as written
>
> - Support intent of recommendation with edits
>
> - Intent and wording of this recommendation requires amendment
>
> - Delete recommendation
>
> If you believe edits are needed for Recommendation #10, please propose edits here.
>
> Please provide the rationale for your answer.
>
> Additional comments for Recommendation #10.
>
> Publication of the registrant’s email address in a way that can be automatically harvested and used for any purpose is clearly not acceptable and not compliant with the GDPR. Recommendation 10 is a good way to optimize privacy while furthering the goal of contactability articulated by Purpose 3.
>
> Recommendation #11: Data Retention
>
> The EPDP Team recommends that Registrars are required to retain the herein-specified data elements for a period of one year following the life of the registration. This retention period conforms to the specific statute of limitations within the Transfer Dispute Resolution Policy (“TDRP”).
>
> Choose your level of support of Recommendation #11:
>
> - Support recommendation as written
>
> - Support intent of recommendation with edits
>
> - Intent and wording of this recommendation requires amendment
>
> - Delete recommendation
>
> If you do not support Recommendation #11, please provide proposed edits here.
>
> Please provide the rationale for your answer.
>
> Retaining the registration data for a year can help protect the rights of registrants and was seen as a legitimate purpose for data collection by contracted parties.
>
> Additional comments for Recommendation #11.
>
> Question 3 for Community Input: Differentiating Registrants: Legal v. Natural Persons; and Effects of Geographic Location
>
> What other factors should the EPDP team consider about whether Contracted Parties should be permitted or required to differentiate between registrants on a geographic basis? (For more information, please refer to the Initial Report, beginning on p. 47.
>
> A factor not properly aired in the Initial Report is the Internet’s status as a global infrastructure and ICANN’s status as a uniform policy maker for the global Domain Name System. One of the main reasons for creating ICANN was to ensure that the Domain Name System would have a globally consistent set of rules. The NCSG strongly opposes fragmenting the policies regarding domain name registration data on a geographic basis for that reason. ICANN should strive as much as possible to keep its rules and requirements the same for the entire Domain Name System. This helps maintain the global compatibility of the Internet. Recently published EDPB guidelines on territorial scope also indicate that there are more factors that require consideration on the territorial scope of GDPR, including targeting criteria (if the sale of goods and services is targeting EU/EEA residents) as well as whether the data controllers and/or processors have stable establishments located within the EU, irrespective of whether the associated data processing activities take place within the EU, or not.
>
> Please provide the rationale for your above answer.
>
> Are there any other risks associated with differentiation of registrants on a geographic basis? If so, please identify those factors and/or risks and how they would affect possible recommendations, keeping in mind compliance with the GDPR.
>
> What other factors should the EPDP team consider about whether Contracted Parties should be permitted or required to differentiate between natural and legal persons?
>
> The current discussion in the Initial Report covers all of the relevant factors regarding natural vs legal persons. There is a clear choice between staying firmly within the boundaries of data protection law on the one hand, and exposing more data for the sake of data miners and surveillance interests on another hand. The NCSG strongly believes that there is no need to consider additional factors.
>
> Please provide the rationale for your above answer.
>
> The NCSG strongly opposes any attempt to require registrars to separate natural and legal persons at the point of registration. Any attempt to sort out who is an organization and who is a natural person will pose major risks, and impose major cost burdens, on the contracted parties. More importantly, however, Registered Name Holders will be at risk of harm, because many registrants will not understand the distinction and will end up being misclassified as organizations and thus lose their legal entitlement to data protection. Furthermore, the GDPR does not distinguish between the protection of natural and legal persons per se, but rather the protection of personal data of natural persons, which is very likely to be included in gTLD Registration Data of domain names registered by legal persons. The obvious example is the Registered Name Holder email address, which would belong to an employee or representative of the legal person, typically being name at domain.TLD.
>
> Should there be further study as to whether whether procedures would be feasible to accurately distinguish on a global scale whether registrants/contracted parties fall within jurisdiction of the GDPR or other data protection laws? Please provide a rationale.
>
> No. The “E” in EPDP means expedited. The purpose of this exercise is to quickly turn the temporary specification into a consensus policy following ICANN procedures. Pausing to conduct studies about adding new elements into domain registration contracts is not appropriate in this expedited proceeding. Stakeholders who want to explore this further, have the possibility to initiate new PDPs after the tight deadline for this EPDP is met. New policies can always be proposed. The NCSG believes that there is no time for further studies within the timeframe of this EPDP.
>
> Are you aware of existing examples where a legal/natural differentiation is already made and could it apply at a global scale for purposes of registration data? If yes, please provide additional information.
>
> There are no directly applicable examples that would work at a global scale.
>
> Recommendation #12: Reasonable Access
>
> The EPDP Team recommends that the current requirements in the Temporary Specification in relation to reasonable access remain in place until work on a system for Standardized Access to Non-Public Registration Data has been completed, noting that the term should be modified to refer to “parameters for responding to lawful disclosure requests.” Furthermore, the EPDP Team recommends that criteria around the term “reasonable” are further explored as part of the implementation of these policy recommendations addressing: o [Practicable]* timelines criteria for responses to be provided by Contracted Parties; o Format by which requests should be made and responses are provided; o Communication/Instructions around how and where requests should be submitted; o Requirements for what information responses should include (for example, auto-acknowledgement of requests and rationale for rejection of request); o Logging of requests. [*Some concern expressed that timeliness that should not be translated into requirements that are impractical for contracted parties].
>
> Choose your level of support of Recommendation #12:
>
> - Support recommendation as written
>
> - Support intent of recommendation with edits
>
> - Intent and wording of this recommendation requires amendment
>
> - Delete recommendation
>
> If you believe edits are needed for Recommendation #12, please propose them here.
>
> The NCSG strongly supports replacing “Standardized Access to Non-Public Registration Data” with “parameters for requesting lawful disclosure requests,” as that more accurately describes the objective.
>
> Please provide the rationale for your answer.
>
> The NCSG strongly supports replacing “Standardized Access to Non-Public Registration Data” with “parameters for requesting lawful disclosure requests,” as that more accurately describes the objective. We understand that the topic of lawful disclosure is a controversial one and may take some time to resolve fully. In the meantime, the general guideline in the temp specification, subject to the modification proposed in Recommendation 12 and further fleshing out of the parameters in the implementation process as proposed above, is something that all stakeholder groups can support.
>
> Additional comments for Recommendation #12.
>
> It will simply be insufficient to state a mere category of request for data; for instance, “intellectual property allegation” or “law enforcement need.” The requirements of the GDPR dictate that prior to revealing the personal and sensitive data of a data subject, there is a balancing test that must take place.
>
> Recommendation #13: Joint Controller Agreements
>
> Based on the information and the deliberations the EPDP Team had on this topic and pending further input and legal advice, the EPDP Team recommends that ICANN Org negotiates and enters into a Joint Controller Agreement (JCA) with the Contracted Parties. In addition to the legally required components of such agreement, the JCA shall specify the responsibilities of the respective parties for the processing activities as described below. Indemnification clauses shall ensure that the risk for certain data processing is borne by either one or multiple parties that have the primary interest in the processing.
>
> Choose your level of support of Recommendation #13:
>
> - Support recommendation as written
>
> - Support intent of recommendation with edits
>
> - Intent and wording of this recommendation requires amendment
>
> - Delete recommendation
>
> If you believe changes are needed for Recommendation #13, please provide proposed edits here.
>
> Please provide the rationale for your answer.
>
> Understanding and specifying the roles and responsibilities of ICANN and the contracted parties is a critical and unavoidable part of compliance with the GDPR. There can be disagreements about the appropriate definition of roles, indemnification, and so on, but there cannot be any serious disagreement about the need to enter into such an agreement. Based on our understanding of the GDPR, ICANN and the contracted parties are joint controllers with respect to the Whois (or RDDS). We also believe that a joint controller agreement is the best way to achieve clear and simple lines of responsibility when there are multiple participants and complex processing structures. This will protect data subjects by preventing a splitting of responsibilities in ways that allow the controllers and processors to avoid responsibility.
>
> Additional comments for Recommendation #13.
>
> Enter any other additional comments or observations you have on Section 3, Part 2 that are not covered by these questions.
>
> Save Your Progress
>
> Do you want to save your progress and quit for now? You will be able to return to the form to complete at a later time.
>
> - Yes
>
> - No, I wish to continue to the next section
>
> Section 3, Part 3: Data Processing Terms
>
> Recommendation #14: Data Processing Roles & Responsibilities
>
> The EPDP Team recommends that the policy includes the following data processing activities as well as responsible parties. Please reference the Initial Report, beginning on p. 63 for further details.
>
> Choose your level of support of Recommendation #14:
>
> - Support recommendation as written
>
> - Support intent of recommendation with edits
>
> - Intent and wording of this recommendation requires amendment
>
> - Delete recommendation
>
> If you do not agree with the enumerated data processing activities and responsible parties, please provide proposed edits, including specific processing activities that need to be added/deleted here. The EPDP team particularly seeks feedback with the assignment of roles such as: “joint-controller,” “controller,” and “processor.
>
> Please provide your rationale for the proposed addition/deletion.
>
> The NCSG supports the intent of this recommendation, and the identification of the different processing activities and responsible parties (controllers and processors) for each. However, the NCSG maintains that we disagree with the inclusion of Purpose #2 and Purpose #7 as they are currently worded in the initial report, and therefore, cannot support any of the processing activities and responsible parties associated with them at this time.
>
> Additional comments for Recommendation #14.
>
> Save Your Progress
>
> Do you want to save your progress and quit for now? You will be able to return to the form to complete at a later time.
>
> - Yes
>
> - No, I wish to continue to the next section
>
> Section 3, Part 4: Updates to Other Consensus Policies
>
> Enter any general comments or observations you may have on the findings in Section 3, Part 4.
>
> Recommendation #15: Uniform Rapid Suspension/Uniform Domain Name Dispute Resolution Policy Requirements
>
> The EPDP Team recommends that for the new policy on gTLD registration data, the requirements of the Temporary Specification are maintained in relation to URS and UDRP until such time as these are superseded by recommendations from the RPMs PDP WG (if any).
>
> Choose your level of support of Recommendation #15:
>
> - Support recommendation as written
>
> - Support intent of recommendation with edits
>
> - Intent and wording of this recommendation requires amendment
>
> - Delete recommendation
>
> If you do not agree that the current updated requirements in the UDRP and URS, as provided in the Temporary Specification should remain in place, please provide proposed edits to the current requirements.
>
> Please provide the rationale, keeping in mind compliance with GDPR.
>
> The EPDP is supposed to deal primarily with bringing ICANN’s Whois/RDDS into compliance with GDPR. In some cases there are interactions between Whois policy and UDRP and URS procedures. Rather than trying to modify additional policies via the EPDP, we should leave the temporary specification in place and allow the GNSO’s Rights Protection Mechanism PDP to take up the other issues. The extent to which these policies are addressed here should be limited to the extent to which gTLD Registration Data is processed within the context of DRP proceedings.
>
> Additional comments for Recommendation #15.
>
> We note that under the Temporary Specification, UDRP and URS proceedings are continuing, with Providers requesting and Registrars sharing registrant data on showing of a complaint filing. These proceedings are moving forward unabated -- with complaints continuing to processed and registrants continuing to be informed (via Notice). We further note it is our understanding that the RPM PDP WG has been reviewing this matter as part of its URS recommendation (UDRP review will not come until a later Phase 2), and is planning to make draft policy recommendations to facilitate URS processing in its upcoming Initial Report in 2019.
>
> Recommendation #16: Instruction to GNSO and Rights Protection Mechanisms Policy Development Working Group
>
> The EPDP Team also recommends that the GNSO Council instructs the review of all RPMs PDP WG to consider, as part of its deliberations, whether there is a need to update existing requirements to clarify that a complainant must only be required to insert the publicly-available RDDS data for the domain name(s) at issue in its initial complaint. The EPDP Team also recommends the GNSO Council to instruct the RPMs PDP WG to consider whether upon receiving updated RDDS data (if any), the complainant must be given the opportunity to file an amended complaint containing the updated respondent information.
>
> Choose your level of support of Recommendation #16:
>
> - Support recommendation as written
>
> - Support intent of recommendation with edits
>
> - Intent and wording of this recommendation requires amendment
>
> - Delete recommendation
>
> If you do not support Recommendation #16, please provide proposed text/edits.
>
> Please provide the rationale for your answer.
>
> This is a fair way to handle disjunctions between the UDRP and URS – which assumed legacy Whois – and the temporary specification regime, which redacts most personally identifiable information. This recommendation merely brings certain issues to the attention of the RPM PDP, it does not however, tell them how to resolve them.
>
> Provide additional comments for Recommendation #16 here.
>
> We note that it is our understanding that the RPM PDP WG has been reviewing this matter as part of its URS recommendation (UDRP review will not come until a later Phase 2), and is planning to make draft policy recommendations to facilitate URS processing in its upcoming Initial Report in 2019.
>
> Recommendation #17: UDRP/URS
>
> The EPDP Team requests that when the EPDP Team commences its deliberations on a standardized access framework, a representative of the RPMs PDP WG shall provide an update on the current status of deliberations so that the EPDP Team may determine if/how the WG’s recommendations may affect consideration of the URS and UDRP in the context of the standardized access framework deliberations.
>
> Choose your level of support of Recommendation #17:
>
> - Support recommendation as written
>
> - Support intent of recommendation with edits
>
> - Intent and wording of this recommendation requires amendment
>
> - Delete recommendation
>
> If you do not support Recommendation #17, please provide proposed edits or changes.
>
> Given the timeline to which the EPDP Team is working, the EPDP Team may complete its work before the RPM PDP WG enters its Phase 2 discussions involving UDRP disclosures. URS discussions (already taking place) may provide the EPDP Team with insight into the deliberations, discussion and draft policy recommendations on URS (which will, in turn, shed light on UDRP).
>
> Please provide the rationale for your answer.
>
> This recommendation merely facilitates coordination between the EPDP and the RPM PDP.
>
> Provide additional comments for Recommendation #17 here.
>
> Recommendation #18: Data Processing Agreements
>
> The EPDP Team recommends that ICANN Org must enter into data processing agreements with dispute resolution providers in which, amongst other items, the data retention period is specifically addressed, as this will affect the ability to have publicly-available decisions.
>
> Choose your level of support of Recommendation #18:
>
> - Support recommendation as written
>
> - Support intent of recommendation with edits
>
> - Intent and wording of this recommendation requires amendment
>
> - Delete recommendation
>
> If you do not agree to Recommendation #18, please provide proposed edits or changes here.
>
> Please provide the rationale for your answer here.
>
> This change is probably necessary in order to reconcile EPDP recommendations with arrangements with existing UDRP providers.
>
> Provide additional comments for Recommendation #18 here.
>
> ICANN Org may also need to enter into data processing agreements with dispute resolution providers to limit the publication of personal and sensitive information about registrants in UDRP and URS decisions. Such data may include the names and contact information of registrants and their attorneys, and the names and contact data of complainant attorneys. Publication of identity, organization, and other data of the registrant and its attorneys -- including in dispute proceedings where the registrant won -- is a collection activity and publication of personal and sensitive data that may well be in violation of the GDPR. The UDRP and URS decision, and even the transfer of domain names, does not require such public disclosure as a necessary part of technical implementation. We further note that older UDRP and URS cases may need to be redacted for publication of personal and sensitive data of the registrant and his/her/its attorneys, email addresses, and other data.
>
> Question #4 for Community Input
>
> Are there any changes that the EPDP Team should consider in relation to the URS and UDRP that have not already been identified?
>
> If so, please provide the relevant rationale, keeping in mind compliance with the GDPR.
>
> Recommendation #19: Transfer Policy
>
> The EPDP Team recommends that for the new policy on gTLD registration data, the requirements of the Temporary Specification are maintained in relation to the Transfer Policy until such time these are superseded by recommendations that may come out of the Transfer Policy review that is being undertaken by the GNSO Council.
>
> Choose your level of support of Recommendation #19:
>
> - Support recommendation as written
>
> - Support intent of recommendation with edits
>
> - Intent and wording of this recommendation requires amendment
>
> - Delete recommendation
>
> If you do not support Recommendation #19, please provide proposed changes/edits here.
>
> Please provide the rationale for your answer, keeping in mind compliance with GDPR.
>
> This recommendation handles appropriately an interdependence between the Temporary Specification and the Transfer policy appropriately.
>
> Provide additional comments for Recommendation #19 here.
>
> Recommendation #20: Transfer Policy
>
> The EPDP Team recommends that the GNSO Council, as part of its review of the Transfer Policy, specifically requests the review of the implications, as well as adjustments, that may be needed to the Transfer Policy as a result of GDPR.
>
> Choose your level of support of Recommendation #20:
>
> - Support recommendation as written
>
> - Support intent of recommendation with edits
>
> - Intent and wording of this recommendation requires amendment
>
> - Delete recommendation
>
> If you do not support Recommendation #20, please provide proposed edits/changes here.
>
> Please provide the rationale for your answer here.
>
> Provide additional comments for Recommendation #20 here.
>
> Question #5 for Community Input
>
> Are there any changes that the EPDP Team should consider in relation to the Transfer Policy that have not already been identified? If so, please provide the relevant rationale, keeping in mind compliance with the GDPR.
>
> Enter any other additional comments or observations you have on Section 3, Part 3 that are not covered by these questions.
>
> Save Your Progress
>
> Do you want to save your progress and quit for now? You will be able to return to the form to complete at a later time.
>
> - Yes
>
> - No, I wish to continue to the next section
>
> Section 3: Other Recommendations
>
> Enter any general comments or observations you may have on the findings in Section 3, Other Recommendation.
>
> Recommendation #21: Joint Controller and Data Processing Agreements
>
> The EPDP Team recommends that ICANN Org enters into required data protection agreements such as a Data Processing Agreement (GDPR Art. 28) or Joint Controller Agreement (Art. 26), as appropriate, with the non-Contracted Party entities involved in registration data processing such as data escrow providers and EBERO providers. These agreements are expected to set out the relationship obligations and instructions for data processing between the different parties.
>
> Choose your level of support of Recommendation #21:
>
> - Support recommendation as written
>
> - Support intent of recommendation with edits
>
> - Intent and wording of this recommendation requires amendment
>
> - Delete recommendation
>
> If you do not support Recommendation #21, please provide proposed edits/changes here.
>
> Recommendation should add “but not including the domain name registrant” after “EBERO providers”.
>
> Please provide the rationale for your answer here, keeping in mind compliance with GDPR.
>
> The NCSG would like to clarify that we are not recommending that ICANN enter into contracts with registrants, as they are also non-contracted parties, and we would not support ICANN org moving in this direction.
>
> Provide additional comments for Recommendation #21 here.
>
> Recommendation #22: Updates to Existing Consensus Policies
>
> The EPDP Team recommends that as part of the implementation of these policy recommendations, updates are made to the following existing policies / procedures, and any others that may have been omitted, to ensure consistency with these policy recommendations as a number of these refer to administrative and/or technical contact which will no longer be required data elements: • Registry Registration Data Directory Services Consistent Labeling and Display Policy • Thick WHOIS Transition Policy for .COM, .NET, .JOBS • Rules for Uniform Domain Name Dispute Resolution Policy • WHOIS Data Reminder Policy • Transfer Policy • Uniform Rapid Suspension System (URS) Rules Please reference the Initial Report, beginning on p. 71 for further details.
>
> Choose your level of support of Recommendation #22:
>
> - Support recommendation as written
>
> - Support intent of recommendation with edits
>
> - Intent and wording of this recommendation requires amendment
>
> - Delete recommendation
>
> If you do not support Recommendation #22, please provide proposed edits or changes here.
>
> Please provide the rationale for your answer here.
>
> This is an appropriate ‘housekeeping’ recommendation that will help ensure consistency of other policies affected by EPDP recommendations with the new policy.
>
> Provide additional comments on Recommendation #22 here.
>
> It will be neither simple nor easy to update existing consensus policies. As captured in the NCSG’s comments to the UDRP and URS questions above, there are important aspects of the collection and especially publication of Registrant data in UDRP and URS decisions that needs to be carefully evaluated -- as publication of personal and sensitive data in a public decision is absolutely unnecessary to implement a UDRP decision transferring a domain name. We wish to note the underlying danger that UDRP and URS proceedings will be used as a ruse for discovering the identity and location of the registrant, absent any true or provable domain name disputes. Of course, this must not be allowed to happen, and must be pursued and punished by ICANN Compliance, among others. We further note that publication of registrant name and/or contact data, including registrants who win the UDRP and URS proceedings, may be especially dangerous. The GDPR prevents those who receive personal and sensitive information for particularly purposes (e.g., UDRP and URS Complainants) from misusing, selling, distributing, aggregating and otherwise publishing the personal and sensitive data. Accordingly, RDDS data disclosed to a dispute provider pursuant to a UDRP or URS (or other future registrant-related dispute proceeding) must be expressly protected by all reasonable updates to existing consensus policies. Finally, appropriate revisions to existing consensus policies must be written to ensure that commitments made to limits on the use and disclosure of registrant RDDS data in UDRP and URS proceedings are followed. Provisions must be drafted and agreed to by Complainants and their attorneys, and UDRP and URS dispute resolution providers, as part of any revisions to existing consensus policies. Penalties for breach must be clear, sharp, swift, and enforceable by ICANN, registrants and their representatives, and dispute resolution providers.
>
> Enter any other additional comments or observations you have on Section 3: Other Recommendations that are not covered by these questions.
>
> Save Your Progress
>
> Do you want to save your progress and quit for now? You will be able to return to the form to complete at a later time.
>
> - Yes
>
> - No, I wish to continue to the next section
>
> Other Comments & Submission
>
> Are there any other comments or issues you would like to raise pertaining to the Initial Report? If yes, please enter your comments here. If applicable, please specify the section or page number in the Initial Report to which your comments refer.
>
> Save Your Progress
>
> [Create your own Google Form](https://docs.google.com/forms?usp=mail_form_link)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ncsg.is/pipermail/ncsg-pc/attachments/20181221/9ecbd13e/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NCSG EPDP Comment.pdf
Type: application/pdf
Size: 392651 bytes
Desc: not available
URL: <http://lists.ncsg.is/pipermail/ncsg-pc/attachments/20181221/9ecbd13e/attachment.pdf>