EPDP On the Temporary Specification for gTLD Registration Data - Public Comment Proceeding Input Form (Responses)

	A	C	D	E	F	G	H	I	J	K	L	M	N	O	P	Q	R	S	T	U	V	W	X	Y	Z	AA	AB	AC	AD	AE	AF	AG	AH	AI	AJ	AK	AL	AM	AN	AO	AP	AQ	AR	AS	AT	AU	AV	AW	AX	AY	AZ	BA	BB	BC	BD	BE	BF	BG	BH	BI	BJ	BK	BL	BM	BN	BO	BP	BQ	BR	BS	BT	BU	BV	BW	BX	BY	BZ	CA	CB	CC	CD	CE	CF	CG	CH	CI	CJ	CK	CL	CM	CN	CO	CP	CQ	CR	CS	CT	CU	CV	CW
1	Timestamp	Please provide your name:	Please provide your affiliation	Are you providing input on behalf of another group (e.g., organization, company, government)?	If yes, please explain:	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.	Please choose your level of support for Purpose 1:	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.	Choose your level of support of Purpose #2:	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.	Choose your level of support of Purpose #3:	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.	Choose your level of support of Purpose #4:	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.	Choose your level of support of Purpose #5:	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.	Choose your level of support of Purpose #6:	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).	Please provide rationale for your recommendation.	Choose your level of support of Purpose #7:	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).	Please provide rationale for your recommendation.	Enter additional comments to Recommendation #1.	If you recommend additional purposes for processing registration data, please enumerate and write them here, keeping in mind compliance with GDPR.	For each additional purpose identified above, please enumerate and provide rationale for each of them.	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.	Choose your level of support of Recommendation #2:	Do you recommend a change to the wording of Recommendation 2? If so, please indicate proposed edits here.	Please include the rationale for your answers here.	Enter additional comments for Recommendation #2.	Choose your level of support of Recommendation #3:	Do you recommend a change to Recommendation 3? If so, please indicate proposed edits here.	Please include the rationale for your answers here.	Enter any other additional comments or observations you have on Section 3 Part 1 that are not covered by these questions.	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.	Do you agree that all these data elements should be collected / generated to achieve the Purposes identified in the Initial Report?	If your answer is ‘no’, please enumerate which data elements should not be collected / generated.	Please provide the rationale for your answer.	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.	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)?	Please provide the rationale for your answer.	If your answer is 'optional', should registrars be required to offer these technical contact fields?	Please provide the rationale for your answer.	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?	Please provide the rationale for your answer.	Enter additional comments for Recommendation #4 here.	Do you agree that all these data elements should be transferred from the registrar to the registry?	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.	Enter additional comments for Recommendation #5 here.	Choose your level of support of Recommendation #6:	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.	Enter additional comments for Recommendation #6 here.	Choose your level of support of Recommendation #7:	Do you agree that all of these data elements should be transferred from the registrar to ICANN?	If your answer is ‘no’, please enumerate which data elements should not be transferred from the registrar to ICANN.	Please provide the rationale for your answer.	Enter additional comments for Recommendation #7 here.	Do you agree that all of these data elements should be redacted?	If your answer is ‘no’, please enumerate the data elements that should not be redacted.	Please provide the rationale for your answer.	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?	Please provide rationale for your answer above.	Enter additional comments for Recommendation #8.	Choose your level of support of Recommendation #9:	If your response requires an edit or deletion of Recommendation #9, please indicate the revised wording here.	Please provide the rationale for your answer.	Additional comments for Recommendation #9.	Choose your level of support of Recommendation #10:	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.	Choose your level of support of Recommendation #11:	If you do not support Recommendation #11, please provide proposed edits here.	Please provide the rationale for your answer.	Additional comments for Recommendation #11.	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.	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?	Please provide the rationale for your above answer.	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.	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.	Choose your level of support of Recommendation #12:	If you believe edits are needed for Recommendation #12, please propose them here.	Please provide the rationale for your answer.	Additional comments for Recommendation #12.	Choose your level of support of Recommendation #13:	If you believe changes are needed for Recommendation #13, please provide proposed edits here.	Please provide the rationale for your answer.	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.	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.

2	11/27/2018 8:57:15	David Martel	None	No		No, I would like to continue to the next section	Support Purpose as written			Support Purpose as written			Support Purpose as written			Support Purpose as written			Support Purpose as written			Support Purpose as written			Support Purpose as written						No, I wish to continue to the next section	Support recommendation as written				Support recommendation as written				No, I wish to continue to the next section	Yes					Optional		Yes	There may be a difference in person responsable	Yes			Yes				Support recommendation as written				Support recommendation as written	No	Personal contact details should not be passed to icann			Yes		It is essential to protect the privacy of the customer	No	It is not personal data		Support recommendation as written				Support recommendation as written		It is essential to protect the users email address from slammers and stalkers etc		Support recommendation as written											Support recommendation as written				Support recommendation as written					No, I wish to continue to the next section
3	11/28/2018 0:58:47	pearl lee s. marmarin	i don't know what precisely this question is asking me.	Yes	ceo/founder of CRS Enterprises Inc.	Yes
4	11/28/2018 5:54:23	Etienne Laurin	N/A	No		No, I would like to continue to the next section	Support Purpose as written			Support Purpose as written			Support Purpose as written			Support Purpose as written			Support Purpose as written			Support Purpose as written			Support Purpose as written						No, I wish to continue to the next section	Support recommendation as written				Support recommendation as written				No, I wish to continue to the next section	Yes					Optional		Yes		Yes			Yes				Support recommendation as written				Support recommendation as written					Yes			No			Support recommendation as written				Support recommendation as written				Support recommendation as written											Support recommendation as written				Support recommendation as written					No, I wish to continue to the next section
5	11/29/2018 9:05:55	Steve Gobin	Corporate domain name management	Yes	VKGP SA dba VANKSEN	No, I would like to continue to the next section																										Intent and wording of this recommendation requires amendment	Registrars or registry operators should put in place a data disclosure process, which allows any third party that can evidence a legitimate right to a domain name to obtain the complete whois data of a domain name.	The temporary Specifications currently only require Registrar and Registry Operator to provide reasonable access to Personal Data in Registration Data to third parties on the basis of a legitimate interests pursued by the third party. The definition of "reasonable access" is vague and may be subject to interpretation.	A lot of ccTLD registry operators such as EURid have already put in place procedures where a third party that wants to obtain the complete whois data of a domain name have to submit a form duly completed, signed and stamped together with evidences of its legitimate right to the concerned domain name (e.g. trademark certificate, BRC...) to the registry operators. Such procedures are compliant with the GDPR.					No, I wish to continue to the next section	Yes			If the domain name is registered via a registrar's reseller, the whois records should also display the reseller's name and contact details.	A lot of domain names are registered via resellers. These resellers are responsible for the day-to-day management of the domain names that are registered through them and the resellers are the ones that are in direct contact with the registrants of such domain names.	Optional		Yes	A lot of registrant are not familiar with domain names, while the technical contact is generally an IP specialist, a DNS technician or a webhosting company that is more familiar with domain names. If there is any issue with a domain name, it is much easier to solve it with someone who knows how domain names work.	Yes	The registry operator always bills the registrar and the registrar always bills the reseller (if any) or the registrant. The registrant or reseller always designates billing contact to its registrar. It is not relevant to include these data in the whois data. As for the administrative contact, it shouldn't be mandatory to provide one but the registrant should have the opportunity to provide one, for example, if a third person that is no technician manages the domain name.		Yes																No	Organisations are not covered by the GDPR																			Yes	Yes, some ccTLD registries such as EURid automatically hide the registrant's data if the registrant is an individual (if the organisation field is left empty) and don't hide it when it is an organisation.	Support recommendation as written									No, I wish to continue to the next section
8	12/21/2018 16:59:58	Michele Neylon	Blacknight Internet Solutions Ltd	No		No, I would like to continue to the next section	Support Purpose as written			Purpose should be deleted		3rd party access to registration data is not part of ICANN's mission.	Support Purpose intent with wording change	simplify to "issues"		Support Purpose intent with wording change	Delete the bit about "other unavailability"	The suggested wording is too broad. Escrow is meant to be for failure. Suggested wording would encompass too much.	Purpose should be deleted			Support Purpose intent with wording change	Current wording is very broad and unclear. Should be simplified so that it only refers to domain disputes		Purpose should be deleted		If a specific registry has registration requirements then those are covered by the contract between the registry and registrar and by the registrar with the registrant. This is out of scope for the EPDP / ICANN				No, I wish to continue to the next section	Delete recommendation		Disclosure of registration data to 3rd parties is not a "purpose" for its collection.		Support recommendation as written				No, I wish to continue to the next section	No	Tech-c contact should be removed	It is not necessary and under GDPR data minimisation is key			Optional	Tech c is not a requirement for a domain registration to function	No	Tech c is not required for a registration to function	Yes	Billing is completely outside the "whois" system and should have been removed years ago. The admin C is a relic		No	None of the registrant data is required by the registry. The only exception being registries with very specific policies around who can register in their TLD	The .com registry (and others) work just fine without having any of the registrant data. All they need is the nameservers, registrar and other fundamental technical data. ICANN is meant to co-ordinate technical identifiers, not act as some goldmine for data collection and mining.		Intent and wording of this recommendation requires amendment	The current wording does not reference the registry or registrar having a contractual relationship or data processing agreement with the escrow provider(s)	It's illogical that there not be a relationship between the data processors		Delete recommendation	No		Any request for data from ICANN to a registrar should be narrow and specific. Each request should include a clear rationale for the requested data as well as clearly demarcated details on how ICANN handles that data. At present ICANN does not have DPAs with registrars and is also claiming that it somehow is exempt from meeting the thresholds that companies we deal with for far less sensitive data have to meet.	Registrars collect and process data from their clients in good faith and in line with the law. ICANN cannot expect us to ignore that and simply handover data without any clear rationale nor do they have any right to mine our clients' data or retain it or process it without appropriate safeguards.	Yes			Yes	Registration of domain names is carried out using many different systems, business models etc., there is a very high risk that personal information is in the org field, as there has never been any real validation of what was being put in it.		Delete recommendation				Support intent of recommendation with edits	The overall intent is fine, but registrars might find other methods of facilitating communication outside of this. Also the publication of an email address is a potential issue depending on how it is implemented, so using a web form is preferable			Delete recommendation	Language needs to be added to cater for data retention waivers				Please see the response filed by the RrSG.				No. The only people who benefit from "studies" are the consultants paid to do them	Several ccTLDs do this, but comparisons between them and gTLDs tend to fail for a number of reasons. First off gTLDs have worked for more than 20 years without this distinction and to attempt to make it now is unworkable. Secondly the ccTLDs often retain a tripartite relationship whereby there is a contractual link between the registrant and the registry. This is not the norm in the gTLD space	Intent and wording of this recommendation requires amendment	see RrSG response			Support recommendation as written					No, I wish to continue to the next section
10	12/15/2018 1:51:32	John Poole	Domain Name Registrant	Yes	Editor of DomainMondo.com	No, I would like to continue to the next section	Significant change required: changing intent and wording	AS SUBJECT TO REGISTRY AND REGISTRAR TERMS, CONDITIONS AND POLICIES, AND ICANN CONSENSUS POLICIES: TO RECORD AND MAINTAIN RECORDS OF THE NAMES AND CONTACT INFORMATION OF DOMAIN NAME REGISTRANTS.	A registrant's relatively simple act of registering a domain name automatically sets in motion registrar and registry processes which activate the domain name and generate "data elements" required to populate "data fields" in the WHOIS (RDS) directory, however it is solely that data related to the "name" and "contact information" of the "registrant," to which GDPR and other privacy laws apply. The only "primary purpose" of processing this limited data (and any consequent "Registry ID") is as stated above. What James Bladel (GoDaddy, RrSG) told the EPDP working group more than once, including Aug 7, 2018 (transcript), is VERY IMPORTANT: "We’re talking about collection of data for the purposes of publication in an RDS system or an online directory and that is, again, not something that we [registrars] need in order to serve our customer, our registrant customers ... we have our own internal communications with those customers" [e.g., additional contact information, banking and credit card info, etc.] This is the time to cleanup the WHOIS registrant data fields, simplify, clarify, and minimize, in compliance with GDPR and other data privacy laws. Therefore, this EPDP should recommend that the Admin and Tech contact categories, the Organization field, and the Fax fields, in the presently collected data elements, be deleted in their entirety, as same are redundant, confusing, unnecessary data elements which violate GDPR data minimization requirements. See EPAG case and https://www.dataguise.com/gdpr-compliance-data-minimization-use-purpose/. I discuss this further in my responses below. EXAMPLE re: https://www.whois.com/whois/facebook.com -- For your reference I have prepared a graphic of my proposed GDPR compliant "New" WHOIS data compared to the "Old" WHOIS data elements: goo.gl/CdqE81 (go to link)	Purpose should be deleted	DELETE	First, this is not needed, as legitimate and lawful access is not prohibited by GDPR and other privacy laws, nor ICANN policies, etc. Second, the EDPB already warned ICANN against conflating third-party interests with its own, see https://www.icann.org/en/system/files/correspondence/jelinek-to-marby-05jul18-en.pdf, and that is exactly what this Purpose #2 does--read this quote: "In effect, Purpose 2 says that ICANN is ordering registries and registrars to collect data from domain name registrants in order to disclose that data to third parties. That is just wrong. The whole principle of collecting and processing data for the sake of unspecified third parties and unspecified uses contravenes basic privacy and data protection norms ... Coming up with terms and conditions of access is step 2 in the EPDP process. We ... need to resist the notion that providing third party access is one of the purposes of Whois, as that points us backwards to the pre-GDPR system of open public Whois."--source: https://www.internetgovernance.org/2018/11/25/whois-privacy-reform-hits-its-first-milestone/	Purpose should be deleted	DELETE	This is not needed--see my response to Purpose 1 above, the primary purpose is "AS SUBJECT TO REGISTRY AND REGISTRAR TERMS, CONDITIONS AND POLICIES, AND ICANN CONSENSUS POLICIES: TO RECORD AND MAINTAIN RECORDS OF THE NAMES AND CONTACT INFORMATION OF DOMAIN NAME REGISTRANTS" which encompasses communication and notification.	Purpose should be deleted	DELETE	This is not needed--see my response to Purpose 1 above, the primary purpose is "AS SUBJECT TO REGISTRY AND REGISTRAR TERMS, CONDITIONS AND POLICIES, AND ICANN CONSENSUS POLICIES: TO RECORD AND MAINTAIN RECORDS OF THE NAMES AND CONTACT INFORMATION OF DOMAIN NAME REGISTRANTS" which encompasses "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."	Purpose should be deleted	DELETE	This is not needed--see my response to Purpose 1 above, the primary purpose is "AS SUBJECT TO REGISTRY AND REGISTRAR TERMS, CONDITIONS AND POLICIES, AND ICANN CONSENSUS POLICIES: TO RECORD AND MAINTAIN RECORDS OF THE NAMES AND CONTACT INFORMATION OF DOMAIN NAME REGISTRANTS" which encompasses "HANDLE CONTRACTUAL COMPLIANCE MONITORING REQUESTS, AUDITS, AND COMPLAINTS SUBMITTED BY REGISTRY OPERATORS, REGISTRARS, REGISTERED NAME HOLDERS, AND OTHER INTERNET USERS."	Purpose should be deleted	DELETE	This is not needed--see my response to Purpose 1 above, the primary purpose is "AS SUBJECT TO REGISTRY AND REGISTRAR TERMS, CONDITIONS AND POLICIES, AND ICANN CONSENSUS POLICIES: TO RECORD AND MAINTAIN RECORDS OF THE NAMES AND CONTACT INFORMATION OF DOMAIN NAME REGISTRANTS" which encompasses "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."	Purpose should be deleted	DELETE	Quote: "... Purpose 7, an unexpected and potentially very dangerous late addition to the list of Whois purposes. Purpose 7 states that one of the purposes of Whois data collection is to “Enabl[e] validation to confirm that Registered Name Holder meets optional gTLD registration policy eligibility criteria voluntarily adopted by Registry Operator” ... Since the eligibility validation for registered name holders in specialized gTLDs is already done outside of the Whois, this additional processing of data does not comply with GDPR article 5.1(c) and the data minimization principle. Data processing should be “adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed”. This purpose is in no way necessary for all of ICANN. Only a few gTLD registries find it desirable. Unfortunately, they are not thinking about the wider consequences and potential abuses that could result."-- source: https://www.internetgovernance.org/2018/11/25/whois-privacy-reform-hits-its-first-milestone/	Your Google Form prevents me from entering additional comments, this is the message I get: "Your response is too large. Try shortening some answers."			No, I wish to continue to the next section	Delete recommendation	DELETE	1) There is no "recommendation" provided, just a statement that 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." 2) Read EPDP Charter p.9: "Work on recommendations for a System for Accredited Access to Non-Public Registration Data should NOT commence until all gating questions have been answered. Similarly, delivery of the Final Report on the EPDP Team’s recommendations on issues relating to the Temporary Specification for gTLD Registration Data to the GNSO Council and subsequently the ICANN Board (before 25 May 2019) should NOT be held up by work that may still be ongoing in relation to the EPDP Team’s recommendations for a System for Accredited Access to Non-Public Registration Data."	The EPDP working group needs to answer the gating questions before addressing and making any "recommendations" about "access" to non-public Registration Data."	Delete recommendation	This recommendation is premature since changes in the WHOIS registration data (deletion of Admin contact info, etc.) could "affect" one or more of ICANN's "requirements related to the accuracy of registration data."	The EPDP working group needs to do its work, then review ALL of ICANN's "requirements related to the accuracy of registration data" before making a such a broad and vague recommendation.		No, I wish to continue to the next section	No	Organization, Fax, Fax ext, Tech ID, Tech Fields: Name, Phone, Email	These fields are unnecessary, redundant, antiquated, obsolete, and/or violate GDPR data minimization principles. The optional "Organization" field should be deleted as redundant, unnecessary, confusing, and duplicative. The correct and accurate "NAME" of the "Registrant" of facebook.com is Facebook, Inc., NOT "Domain Admin" or some other "anonymized" fictional name of an otherwise unknown or imaginary person or entity. See https://www.whois.com/whois/facebook.com. Look at the Registrant, Admin, and Tech fields in that facebook.com WHOIS--all the same. (When needed, it is easy to set up an email address that forwards to 2 or more separate recipients in any organization.) This is the way the "New" WHOIS should look like compared to the "Old" WHOIS: goo.gl/CdqE81 (go to link). Note also: "The Tech-C field Is obsolete ... For all practical purposes, the technical contact for any registrant is the registrar, and registrar contact info is already automatically included in the public Whois." -- https://www.internetgovernance.org/2018/11/25/whois-privacy-reform-hits-its-first-milestone/ Collecting WHOIS "Tech contact" information will also often result in processing personal data of a third-party "natural person" without consent as required by GDPR. The Fax fields are antiquated, obsolete, and constitute a grave "security risk" -- https://blog.checkpoint.com/2018/08/12/faxploit-hp-printer-fax-exploit/ -- and also have been abused by WHOIS accuracy complainants, as noted in http://www.circleid.com/posts/20180521_gdpr_icann_and_registrar_whois/ "... [Noss] also said that the ICANN WHOIS compliance rules are arbitrary and widely abused. His registrar gets lots of complaints about missing fax numbers which are in obvious bad faith, often domain speculators hoping that the domain will be canceled and they can snipe it and resell it ..." The only "Registrant data elements" necessary and appropriate for the WHOIS directory are: Name of Registrant; Registrant's Address, Phone number, Email address; and the consequent Registry Registrant ID. Simplify, streamline, clarify, and minimize should be goals of this EPDP.			Optional	The technical contact fields should be deleted as I discussed in my previous answer above. If NOT deleted, then Optional.	No	The technical contact fields should be deleted as I discussed in my previous answer above. See also ICANN vs. EPAG case for additional rationale.	Yes	This information is unnecessary and inappropriate for the WHOIS directory.	See my previous responses above.	No	None, except where the transfer is necessary and reasonable--see rationale below.	Rationale: "Personal Data Transfer to a Registry - ICANN’s continuing requirement that registrars transmit all data collected to the relevant registry is counter to the GDPR’s principle of use of data only when a legitimate legal basis applies .... " read more at https://www.epag.de/en/tucows-statement-on-icann-legal-action/		Delete recommendation	I have no objection to registrars having data escrow providers, however not enough information has been provided.	I have no objection to registrars having data escrow providers, however not enough information has been provided above or in Annex D, Workbook 4, to support Recommendation #6 or provide any revised wording here.		Delete recommendation	No	None of the data elements should be transferred from the registrar to ICANN.	Same as the rationale I gave in answer to Recommendation #5 above: Rationale: "Personal Data Transfer to a Registry - ICANN’s continuing requirement that registrars transmit all data collected to the relevant registry is counter to the GDPR’s principle of use of data only when a legitimate legal basis applies .... " read more at https://www.epag.de/en/tucows-statement-on-icann-legal-action/ The registrar could just give ICANN access to the data when lawful and appropriate. Of all the parties mentioned (registrars, registries, ICANN), I trust my registrar the most to responsibly keep and process my registrant data, the monopoly registry operator less so, and least of all ICANN.		Yes			Yes	The "Organization" field should not only be redacted but DELETED as I have already addressed previously above. The "Organization" field should be deleted as redundant, unnecessary, confusing, and duplicative. The correct and accurate "name" of the "registrant" of facebook.com is Facebook, Inc. NOT "Domain Admin" or some other "anonymized" fictional title of an otherwise nameless person or entity. When the registrant is an organization, the name of the organization should go in the data field "Registrant Name."		Delete recommendation	DELETE Recommendation #9	The Organization field should be deleted as unnecessary, confusing, duplicative, -- see Rationale in previous answers above. Therefore the "Organization" field should not only be redacted but DELETED as I have already addressed previously above.	Please remove all references to "Registered Name Holder" and "RNH." The correct (longstanding) term is "Registrant"--see WHOIS data elements, etc. Duplicative terminology is confusing and serves no useful purpose. ICANN should strive for clarity and simplicity, not complexity for its own sake, which is often a sign of incompetent "lawyering." The 2013 Registrar Accreditation Agreement uses the term "Registrant" 57 times, and "Registered Name Holder" 77 times, to refer to the same person or entity.	Support recommendation as written		This is VERY IMPORTANT for GDPR compliance AND the SECURITY of registrants and their domain names at registrars. Domain names are often stolen by hacking email addresses, and SIM swap fraud (phone) is also a known security risk.		Support recommendation as written				Contracted Parties should NOT be required to differentiate between registrants on a geographic basis, and may not be able to do so consistent with their own respective legal counsel's advice. Requiring a Contracted Party to act contrary to legal counsel's advice is inappropriate.	See ICANN v. EPAG Domainservices, GmbH https://www.icann.org/resources/pages/litigation-icann-v-epag-2018-05-25-en	The potential liability for violating GDPR via mistakes made in "differentiating registrants on a geographic basis."	ICANN has NEVER limited registration of domain names to just "natural persons" and "legal entities." See 2013 RAA 3.7.7.1 “… Registered Name Holder that is an organization, association, or corporation …” Many unincorporated organizations and associations are not "legal entities" -- see https://content.next.westlaw.com/Document/I25017386e8db11e398db8b09b4f043e0/View/FullText.html In addition, many businesses are licensed or registered by state authorities as simply a DBA — also known as a trade name, fictitious name, or assumed name -- see https://www.sba.gov/business-guide/launch-your-business/choose-your-business-name.	Rationale included in answer above.	No. The EPDP should not be rendering legal advice. See ICANN v. EPAG Domainservices, GmbH.	No.	Support intent of recommendation with edits	"The EPDP Team recommends that the current requirements in the Temporary Specification in relation to reasonable access remain in place until work on access has been completed which will not begin until after the gating questions have been answered."	Premature to be discussing "Access recommendations" until the gating questions have been answered. Read the EPDP Charter.		Delete recommendation	DELETE Recommendation	"pending further input and legal advice, the EPDP Team recommends" -- Go get the "further input and legal advice" and then come back with your recommendation. See additional comment below.	"Last but not least, we have the fundamental issue of who is the data controller, and whether ICANN and the contracted parties are joint controllers. The EPDP Recommendation #13 is [see above] .... ICANN’s legal department seemed surprisingly unprepared to deal with these questions, and ICANN Org’s liaisons to the EPDP seemed to be missing in action through discussions of this issue until the very end. Because this issue touches on complex legalities and on the distribution of liability between ICANN org and the contracted parties, it is a sleeper issue that could blow up the whole process." https://www.internetgovernance.org/2018/11/25/whois-privacy-reform-hits-its-first-milestone/	Again YOUR FORM prevented me--"Your response is too large ..."	No, I wish to continue to the next section
11	12/10/2018 8:57:48	Bob	The Builder	No		No, I would like to continue to the next section
12	12/11/2018 12:44:20	Ivett Paulovics	MFSD Srl URS Provider	No		No, I would like to continue to the next section
13	12/19/2018 18:08:11	Monica Sanders	i2Coalition	Yes	I am submitting these comments in my capacity as Policy Director of the i2Coalition. These comments represent the collective perspective of the organization, and are not my personal views.	No, I would like to continue to the next section	Support Purpose intent with wording change		If reviewed closely, one can see that the workbook for purpose 1 does not actually note the transfer of data from the Registrar to the Registry. This could be an oversight, or a difficult level of specificity to achieve in terms of gaining consensus on a policy. That said, the i2C believes it bears exploration. We also note that language referencing a contact for “administrative issues” is defined too narrowly for some of the envisaged applications (AUP/T&C).	Purpose should be deleted		We are sympathetic to the needs of law enforcement, and understand that WHOIS is an important (but far from the only available) tool to investigate wrongdoing. However, we wish to be clear that third party access to registration data is not part of ICANN’s mission. Moreover, this overbroad application of what ‘security, stability, and resiliency’ means, as stated in this purpose - a slippery slope that could lead to the inclusion of just about anything being considered in-scope. Further, we draw attention to Article 6(1)(f) where release of data for legitimate interests is more rightly considered a legal obligation for data controllers. This view is consistent with that of the Internet infrastructure community on this issues and many others which consider the clear and blurred lines around the control and release of data.	Support Purpose as written			Support Purpose intent with wording change	“Or other unavailability” is unclear and should be removed.	We cannot allow this purpose to be overbroadly applied because it appears to encompass things it should not.	Support Purpose intent with wording change	HANDLE CONTRACTUAL COMPLIANCE MONITORING REQUESTS, AUDITS, AND COMPLAINTS SUBMITTED BY REGISTRY OPERATORS, REGISTRARS, AND REGISTERED NAME HOLDERS.	The current wording has an overbroad application. From a practical standpoint, it will be difficult for companies to execute as worded. From a legal and political perspective, stakeholders and ICANN should remain vigilant not to frame policies in a way that could further implicate the surrounding issues with GDPR compliance, other international activities and potential conflicts.	Support Purpose intent with wording change	COORDINATE, OPERATIONALIZE, AND FACILITATE 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.	The prior language is ambiguous and overly broad. Please also see our rationale under Purpose #5 about the importance of clear, specific language and intent.	Support Purpose as written						No, I wish to continue to the next section	Delete recommendation		Third party access to registration data is not part of ICANN’s mission.		Support recommendation as written				No, I wish to continue to the next section	Yes					Optional		No		Yes			Yes				Support recommendation as written				Support recommendation as written					Yes			No	Further guidance should be south from rNH.		Support recommendation as written				Support recommendation as written				Support recommendation as written							Yes, scalability and diverse impacts must be studied.	i2Coalition notes that small business, which still make up the majority of Internet infrastructure companies, would be significantly adversely affected if required to add the layers of complex systems that are currently understood to be needed to differentiate registrants, both in terms of geography and with respect to legal versus natural registrants. Policies and procedures must not be so complex that only large incumbents have the resources to manage them.	Yes, and there should be a study about the EPDP's scope and jurisdiction on this matter. It is important to maintain a sense of scope with respect to the EPDP. It an expedited policy regime, confirming the wording of a temporary specification is appropriate where there is consensus. In this instance, the questions is whether the temporary specification is sufficient to allow for GPDR compliance without further policy development. This is a more complex initiative that will require gaining further input and consensus. This may not be within the scope of EPDP.		Support recommendation as written				Support recommendation as written					No, I wish to continue to the next section
14	12/20/2018 0:23:04	Dean S. Marks	Coalition for Online Accountability	Yes	The Coalition for Online Accountability ("COA") consists of eight leading copyright industry companies, trade associations and member organizations of copyright owners, all of them deeply engaged in the use of the internet to disseminate creative works protected by copyright law. The COA members are Broadcast Music, Inc. (“BMI”); the Entertainment Software Association (“ESA”); the Motion Picture Association of America (“MPAA”); the Recording Industry Association of America (“RIAA”); NBCUniversal; The Walt Disney Company; Twenty-First Century Fox; and WarnerMedia. The Coalition’s main goal since its founding nearly two decades ago (as the Copyright Coalition on Domain Names) has been to preserve and enhance online transparency and accountability, particularly in the domain name system.	No, I would like to continue to the next section	Support Purpose intent with wording change	(I) TO ESTABLISH THE RIGHTS AND OBLIGATIONS OF A REGISTERED NAME HOLDER IN A REGISTERED NAME; (II) TO ENSURE THAT A REGISTERED NAME HOLDER MAY EXERCISE ITS RIGHTS AND FULFILL ITS OBLIGATIONS IN THE USE AND DISPOSITION OF THE REGISTERED NAME; AND	The collection of data from the domain name registrant serves not only the purpose of establishing rights of the registrant in a registered name, but also for establishing obligations. These include the obligation to pay the registrar the appropriate periodic fee for the registered name and the obligation for the registrant to comply with the various terms and conditions established in the contract between the registrar and the registrant. Rights and obligations go hand-in-hand, and therefore the purpose of obtaining the data from the registrant to establish the rights in the name cannot be separated from the purpose of obtaining the data to fulfill the obligations that go along with domain name ownership. Article 6(1)(b) of the GDPR establishes the legality of collecting and processing personal data "for the performance of a contract to which the data subject is party . . . ." The performance of any contract involves OBLIGATIONS in addition to rights. Therefore, adding the language suggested concerning obligations makes this proposed purpose more compliant with the GDPR.	Support Purpose intent with wording change	ENSURING THE SECURITY, STABILITY AND RESILIENCY OF THE DOMAIN NAME SYSTEM IN ACCORDANCE WITH ICANN'S MISSION, COMMITMENTS AND CORE VALUES THROUGH ENABLING LAWFUL ACCESS FOR LEGITIMATE THIRD PARTY INTEREST OF LAW ENFORCEMENT, CYBERSECURITY, COMBATTING DOMAIN NAME ABUSE, CONSUMER PROTECTION AND INTELLECTUAL RIGHTS PROPERTY PROTECTION TO DATA ELEMENTS COLLECTED FOR THE OTHER PURPOSES IDENTIFIED HEREIN	ICANN's stated mission is to ensure the stable and secure operation of the Internet's unique identifier systems; therefore Purpose #2 should embody the "ensure" language and imperative. Article 13(1) of the GDPR states: “Where personal data relating to a data subject are collected from the data subject, the controller shall, at the time when personal data are obtained, provide the data subject with all of the following information: . . . (d) where the processing is based on point (f) of Article 6(1), the legitimate interests pursued by the controller or by a third party;” (emphasis added)" In order to comply with Article 13(1)(d), it is key that the legitimate interests pursued by the controller or by a third party be spelled out clearly in the Purpose statement and communicated to the data subject AT THE TIME WHEN PERSONAL DATA ARE OBTAINED. As a joint controller, ICANN’s purposes with respect to WHOIS data and registry directory services include, according to ICANN’S Bylaws “whether its implementation meets the legitimate needs of law enforcement, promoting consumer trust, security, stability and resiliency, malicious abuse issues, sovereignty concerns and rights protection.” (ICANN Bylaws Section 4.6). Purpose #2 from the Initial Report only addresses “security, stability and resiliency” and does not address the other ICANN purposes and concerns as articulated in Section 4.6 of the Bylaws. The above suggested edits to Purpose #2 address this deficiency. In addition, the above suggested edits to Purpose #2 seek to ensure compliance with Article 13(1)(d) of the GDPR by: (i) enumerating more specific purposes, and (ii) identifying with greater specificity the legitimate interests of ICANN (as a joint controller) and the legitimate interests pursued by third parties that may seek access to the personal data for processing. Therefore, we believe it is important to spell out explicitly, as we have done in our suggested edits, the legitimate interests of law enforcement, cybersecurity, combatting domain name abuse, consumer protection and intellectual property rights protection. Intellectual property rights protection covers the universally and legally recognized rights of trademark, copyright and patent. In its letter of 11 April 2018, to Goran Marby, the Article 29 Data Protection Working Party stated that “purposes specified by the controller must be detailed enough to determine what kind of processing is and is not included . . . .” The letter also stated that the WP29 “stresses the importance of explicitly defining legitimate purposes in a way which comports with the requirements of the GDPR.” Our proposed edits to Purpose #2 seek to incorporate and comply with this legal guidance that ICANN has received.	Support Purpose intent with wording change	ENABLE COMMUNICATION WITH AND/OR NOTIFICATION TO AND/OR INVESTIGATION OF THE REGISTERED NAME HOLDER AND/OR THEIR DELEGATED AGENTS OF TECHNICAL AND/OR ADMINISTRATIVE AND/OR LEGAL ISSUES WITH A REGISTERED NAME (BOTH WITH RESPECT TO THE REGISTERED NAME ITSELF AND/OR THE USE OF THE REGISTERED NAME).	Adding the words "legal issues" bring greater clarity and specificity to the purpose and understanding by the registered name holder that the personal data collected may be used to contact or notify the registered name holder of legal issues with respect to the registered name. The same holds true for adding the word "investigation," as the personal data collected from the domain name registrant may be used in connection with investigations of technical issues (e.g., domain name "hijacking") as well as legal issues, including those pursued by law enforcement. The parenthetical language "(both with respect to the registered name itself and/or the use of the registered name)" provides clarity and information to the registered name holder that their personal data may be processed for the purpose of resolving claims that the registered name is being used to facilitate unlawful conduct, including by giving the registered name holder appropriate notice of such claims. All of the suggested edits to Purpose #3 seek to bring it into greater compliance with the GDPR, particularly Article 13 and its information requirements.	Support Purpose as written			Support Purpose as written			Significant change required: changing intent and wording	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 BUT INCLUDING WHERE SUCH POLICIES TAKE INTO ACCOUNT USE OF THE 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. THIS PURPOSE SHOULD NOT BE READ TO LIMIT ANY OTHER PURPOSE WHERE PROCESSING OF DATA HAS BEEN RECOGNIZED AS LEGITIMATE IN CONNECTION WITH FACILITATING INVESTIGATION AND ACTION CONCERNING ANY OTHER LEGAL ISSUES INVOLVING A DOMAIN NAME, INCLUDING HOW A DOMAIN NAME IS USED.	As set forth in the Initial Report, Purpose #6 does not adequately capture that domain name disputes do, in fact, normally involve the use of the domain name. For example, the UDRP sets forth that the complainant must prove that the disputed domain name "has been registered and is being used in bad faith." The suggested edits seek to correct this deficiency and to comply more closely with the GDPR's requirements set forth in Article 6 and Article 13 concerning the lawfulness of processing and the information to be provided where personal data are collected from the data subject.	Support Purpose as written				COA recommends additional purposes for processing registration data concerning: (i) research, both research conducted by ICANN org and by third parties, and (ii) implementation of consensus policies by ICANN org and the undertaking of validation, facilitation and compliance activities consistent with its mission. Potential wording to capture such additional purposes: A. Enable research undertaken by ICANN and third parties concerning the operational stability, reliability, security, global interoperability, resilience, and openness of the DNS and threats to these criteria and values, and on the accuracy of WHOIS data. B. Enable the operations of ICANN consistent with its mission of furthering the operational stability, reliability, global interoperability, resilience and openness of the DNS via implementation of consensus policies, validation and compliance with policies and contracts, and facilitation activities.	Article 5(1)(b) and (e) of the GDPR recognize research as legitimate and not "incompatible with the initial purposes." Given how important research-- undertaken both by ICANN org itself and by third parties, such as cybersecurity researchers--is to the core mission of ICANN of ensuring and furthering the stability, reliability and resiliency of the domain name system, this research purpose should be set forth explicitly. In addition, adding this explicit purpose furthers compliance with Article 5(1)(a) of the GDPR that personal data is processed "fairly and in a transparent manner in relation to the data subject" because setting forth this purpose clearly and explicitly enhances transparency. Finally, adding a specific reference to the accuracy of WHOIS data fulfills the accuracy requirement of the GDPR as set forth in Article 5(1)(d). This is the rationale that supports new Purpose A suggested above. In order to implement, fulfill and enforce both consensus policies and contractual obligations, as well as pursue operations critical to ICANN's core mission, ICANN will need access to and be able to process personal data of registered name holders in its role as a controller or joint controller. Setting forth this purpose explicitly furthers the accountability principle set forth in Article 5(2) of the GDPR. In addition, it adds greater clarity to the lawful processing activities of ICANN as set forth in Article 6 of the GDPR. Among other functions, this purpose permits ICANN to continue to operate its Accuracy Reporting System ("ARS") concerning WHOIS data. This is the rationale that supports new Purpose B suggested above.	No, I wish to continue to the next section	Support intent of recommendation with edits	Per the EPDP Team Charter, the EPDP Team is committed to answering the additional gating questions in the Charter and developing and recommending a system for Standardized Access to non-public Registration Data no later than the submission of its Final Report. 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, the EPDP Team will develop a proposal that sets forth the method and process for disclosing non-public Registration data to third parties that have established legitimate interest in accessing non-public Registration data, including intellectual property rights holders, cybersecurity firms, organizations that mitigate DNS abuse, consumer protection organizations and law enforcement agencies.	In order to fulfill its Charter, the EPDP Team must develop and deliver a proposal to address standardized access to non-public registrant data. The edits to Recommendation #2 submitted here recognize this as a requirement of the Charter that must be fulfilled by the EPDP Team no later than the submission of its Final Report. Moreover, specific guidance from the European Data Protection Board has been received by ICANN in the Board's May 27 communication wherein it stated that it expects ICANN "to develop and implement a WHOIS model which will enable legitimate uses by relevant stakeholders, such as law enforcement, of personal data concerning registrants in compliance with the GDPR . . . " The suggested edits offered above further clarify "relevant stakeholders" by specifically calling out intellectual property rights holders, cybersecurity firms, organizations that mitigate DNS abuse, consumer protection organizations and law enforcement agencies		Intent and wording of this recommendation requires amendment	The EPDP Team recommends that no consensus policy adopted to address registration data interfere with accuracy requirements under current ICANN contracts and consensus policies nor interfere with ICANN’s ability to enforce accuracy requirements, including by being able to access full registration data (including any data elements that are redacted from publication in any registration directory) in order to assess data accuracy and enforce accuracy contractual requirements. This includes full access to registration data to enable the operation of the ICANN WHOIS Accuracy Reporting System (“ARS”) and all validation functions under the ARS. In addition, because of the data accuracy requirements imposed by the GDPR, the EPDP Team recommends that requirements be developed to increase the accuracy of registration data	According to Article 5.1(d) of the GDPR, personal data shall be "accurate and, where necessary, kept up to date; every reasonable step must be taken to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay." The ico. (Information Commissioner’s Office in the UK) points out in its writings on “Principle (d): Accuracy” that one of the new features of GDPR as compared to the principles under its predecessor is that there is now a “clearer proactive obligation to take reasonable steps to delete or correct inaccurate personal data.” In addition, the European Commission’s technical input on ICANN's proposed GDPR-compliant WHOIS models underscored the GDPR's "Accuracy" principle and made clear that “reasonable steps should be taken to ensure the accuracy of any personal data obtained” for WHOIS databases and that ICANN should be sure to incorporate this requirement in whatever model it adopts. Accuracy of domain name ownership is paramount to collection of WHOIS/Registered Name Holder data in the first instance. In addition, since this data will be used by third parties who demonstrate a legitimate interest, ensuring that it is accurate for them and their legitimate interests is also relevant. Moreover, as demonstrated by the .dk ccTLD, when accuracy and validation of registration data is taken seriously, it leads to dramatic decreases in abuse and illegal activity on the top level domain. See: https://ccnso.icann.org/sites/default/files/field-attached/presentation-difo-increase-trust-25jun18-en.pdf Prior to the adoption of the Temporary Specification, accuracy of WHOIS data was problematic. When the ARS was running, we know that almost 40% of randomly sampled registrations had a problem that warranted opening a compliance ticket on them. Therefore, even prior to ICANN seeking to modify its policies to comply with GDPR, a serious problem with accuracy existed. Now with the adoption of the Temporary Specification, the ARS is not even operational. With the accuracy requirements that the GDPR imposes, accuracy is an issue fully within scope of the EPDP so that ICANN and contracted parties proactively address how they will ensure and validate the accuracy of data in the first place, not just how they rectify inaccurate data brought to their attention after collection.		No, I wish to continue to the next section	Yes			Registrars should be required to provide an option for registered name holders to indicate that they are either a Legal or Natural Person. Registrars should be required to generate a data element of the date on which registered name holder contact data was last verified/validated in accordance with the RAA and the method used to do so.	The GDPR does not apply to the data of Legal Persons. Recital 14 of the GDPR makes clear that "[t]his Regulation does not cover the processing of personal data which concerns legal persons and in particular undertakings established as legal persons, including the name and the form of the legal person and the contact details of the legal person." Therefore, in order to fulfill the stated purpose of the GDPR to protect only the data of natural persons and to further ICANN's mission, registrars should be required to give registered name holders the ability to designate themselves as legal or natural persons at the time they enter into a contract with the registrar to acquire a domain name. The generation of an additional data element by the registrar concerning when the registrant contact data was last verified/validated is consistent with and furthers compliance the GDPR's data accuracy requirements as well as the obligations set forth in the RAA concerning data quality.	Optional	COA asserts that Registrars should be required to provide registrants with the “OPTION” to provide Technical Contact information, although provision of this alternative contact information by registrants should not be mandatory. Many registrants may wish to provide secondary contact information, including large corporate registrants who need to route the appropriate communications within their organization, and technically-novice registrants who need to enlist the help of an organization with greater technical expertise to manage their web presence. Requiring that registrars give registrants the option to supply such technical contact information serves ICANN's core mission of ensuring and furthering the stability, security and resiliency of the domain name system because it allows contact to be made with the appropriate technical person or organization (in cases where such a person or organization exists separate from the registrant) to address technical issues more quickly and efficiently.	Yes	See Rationale above. Domain name registrants may well want to supply appropriate technical contact information to resolve more quickly and effectively any technical issue that may arise with respect to their domain names. This serves the interest of both the registrant and the overall mission of ICANN and therefore this should be required of registrars.	No	While COA agrees that administrative contact information should not be required to be collected, we think requiring registrars to give registants the OPTION to supply this additional data should be the appropriate path forward. This gives registrants the flexibility of supplying suitable points of contact if they so choose. Moreover, the SSAC has noted that maintaining administrative and technical contracts plays a role in reducing single points of failure or attack. See: SAC044: A Registrant's Guide to Protecting Domain name Registration Accounts.		Yes	All data should be transferred to the registry in compliance with ICANN consensus policy on transitioning data from thin to thick for the remaining thin registries, including for the .com and .net. top level domains. The GDPR should not impact the remaining transition from thin to thick and transferring data from the registrar to the registry can be readily completed in a manner that is compliant with the GDPR.			Support recommendation as written																																											Yes
15	12/21/2018 13:14:08	Lori Schulman	International Trademark Association (INTA)	No	INTA is a global association of brand owners, legal professionals, academics, civil society and trademark and domain industry service providers and others dedicated to defending trademarks and related intellectual property (IP) rights to foster consumer protection, economic growth and innovation. With more than 7,200 members in over 192 countries, one of INTA’s goals is the promotion and protection of trademarks as a primary means for consumers to make informed choices regarding the products and services they purchase. INTA members frequently rely on and use ownership information in the global WHOIS database to locate and contact the registrant behind web sites that infringe the intellectual property rights of others, steal personal information, sell counterfeit goods, distribute malicious software and perpetuate fraud. During the last two decades, INTA has been the leading voice of trademark owners within the Internet community, serving as a founding member of the Intellectual Property Constituency (IPC). INTA’s Internet Committee is a group of over 175 trademark owners and professionals from around the world charged with evaluating treaties, laws, regulations and procedures relating to domain name assignment, use of trademarks on the Internet, and unfair competition on the Internet, whose mission is to advance the balanced protection of trademarks on the Internet.	No, I would like to continue to the next section	Support Purpose intent with wording change	Revise (I) to include the wording, "and obligations" after "rights" as follows: (I) TO ESTABLISH THE RIGHTS AND OBLIGATIONS OF A REGISTERED NAME HOLDER IN A REGISTERED NAME; All other text remains the same.	The Purpose should be more accurately defined to refer to both the rights “and obligations” of the registered name holder, which reflects the practical and legal context in which a name is registered. For example, a registered name holder provides their contact details not only to establish their claim to a specific domain but also to put third parties on notice of that claim. The name holder also agrees to certain obligations in connection with their registration, and the provision of registration data is integral to establishing the identity of the name holder so that the registrar, registry operators and (potentially) third parties are able to identify the party which has undertaken such obligations. This goes beyond Purpose 3 (described below) which deals with communication.	Support Purpose intent with wording change	ENSURING THE SECURITY, STABILITY, AND RESILIENCY OF THE DOMAIN NAME SYSTEM IN ACCORDANCE WITH ICANN'S MISSION, AS SET FORTH IN ICANN’S BYLAWS, TOGETHER WITH ICANN’S COMMITMENTS AND CORE VALUES, THROUGH THE ENABLING OF LAWFUL ACCESS FOR LEGITIMATE THIRD PARTY INTERESTS, SUCH AS LAW ENFORCEMENT, INTELLECTUAL PROPERTY RIGHTS HOLDERS AND CYBERSECURITY PROFESSIONALS, TO DATA ELEMENTS COLLECTED FOR THE OTHER PURPOSES IDENTIFIED HEREIN.	As described in the Bylaws, ICANN’s mission is to “ensure” the security, stability and resiliency of the DNS, not merely “maintain” it. This underscores that ICANN’s policies in this regard are proactive. The scope of ICANN’s Mission was carefully clarified and described in its Bylaws, and this is what should guide the interpretation of this purpose. For clarity sake, reference to the definition in the Bylaws is important. Furthermore, in order to ensure that there are examples of what may constitute legitimate third party interests, INTA believes strongly that those of law enforcement, intellectual property owners and cybersecurity professionals are recognized as stakeholders in this area. This has been historically true at ICANN and should remain so, and is consistent with ICANN’s obligation to uphold the broader public interest, in furtherance of fulfilling ICANN’s Mission, under its Bylaws.	Support Purpose intent with wording change	Addition of the word "legal" to decriptors for issues. ENABLE COMMUNICATION WITH AND/OR NOTIFICATION TO THE REGISTERED NAME HOLDER AND/OR THEIR DELEGATED AGENTS OF TECHNICAL, LEGAL, AND/OR ADMINISTRATIVE ISSUES WITH A REGISTERED NAME	The existing wording is unduly narrow and fails to acknowledge that the relationship between the registrant and the registrar is a legal one, which includes obligations not only in relation to the act of registering and technically maintaining the domain name, but other obligations pertaining to the terms of use which are included as part of the framework of agreements and obligations between ICANN, Registry Operators, Registrars and Registrants. These obligations are in accordance with ICANN’s Mission, as set forth in its Bylaws. Communication with the registrant when such terms are breached is a logical and proportionate purpose for data processing.	Support Purpose as written			Support Purpose as written			Significant change required: changing intent and wording	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, BUT INCLUDING WHERE SUCH POLICIES TAKE INTO ACCOUNT USE OF THE DOMAIN NAMES), NAMELY, THE UDRP, URS, PDDRP, RRDRP, AND ANY FUTURE DEVELOPED DOMAIN NAME REGISTRATION-RELATED DISPUTE PROCEDURES FOR WHICH IT IS ESTABLISHED THAT THE PROCESSING OF PERSONAL DATA IS NECESSARY. THIS PURPOSE SHOULD NOT BE READ TO LIMIT ANY OTHER PURPOSE WHERE PROCESSING OF DATA HAS BEEN RECOGNIZED AS LEGITIMATE IN CONNECTION WITH FACILITATING INVESTIGATION AND ACTION CONCERNING ANY OTHER LEGAL ISSUES INVOLVING A DOMAIN NAME, INCLUDING HOW A DOMAIN NAME IS USED.	INTA is concerned with the narrow and selective reference to the exclusion of processing for this purpose where it relates “use of domain names”, which ignores long standing ICANN policies applicable to domain name disputes. ICANN’s Bylaws specifically reference policies taking into account the use of domain names as part of ICANN’s mission, and in policy as well as practice, UDRP actions depend on a showing of bad faith relating to the use of a particular domain. The approach of the proposed language in the Initial Report may be seen as an attempt to undermine or alter the implementation of ICANN consensus policy in this area. It is therefore essential that this gross oversight be corrected through the inclusion of the language from the Bylaws. As a point of reference, INTA’s first proposed addition to the purpose statement quotes verbatim the language from the Bylaws.	Support Purpose as written				Purposes should reference the need for processing for law enforcement, DNS abuse, IP infringement and consumer protection purposes. INTA also supports clarification of purposes to include research of DNS abuse since this falls squarely within ICANN’s mission and is one of the primary bases for the obligation of registrars to collect registrant data insofar as ICANN is concerned. If these purposes cannot be clarified within the framework of the existing purposes enumerated above, then it may be necessary to include additional purposes.	The list of purposes set forth above are integral to accomplishing ICANN’s mission, and ensuring the health and welfare of the DNS system, for the benefit of individual registrants, as well as the many stakeholders who have an interest in the DNS system.	No, I wish to continue to the next section	Support intent of recommendation with edits	In this context, among others, the ePDP Team will develop a policy that prescribes the method for disclosing non-public registrant data to third parties that have established legitimate interest in viewing registrant data including; law enforcement agencies, intellectual property rights holders, cybersecurity firms, and organizations that mitigate DNS abuse among others.	INTA strongly supports the recommendation for the EPDP Team to develop a standardized, or “unified,” system for access to non-public registration data after the gating questions have been answered. INTA proposes edits to this recommendation to ensure that the protection of intellectual property rights is expressly recognized as a legitimate interest under GDPR and therefore understood to be within scope of the final policy. The term “legitimate” implies that the interest is bolstered by recognition of a legal right, which in the case of intellectual property is the reason for its very existence. Intellectual property rights are regarded as third generation human rights and are duly recognized as human rights under Article 27 (2) of the Universal Declaration of Human Rights. The Article provides that ‘Everyone has the right to the protection of the moral and material interests resulting from any scientific, literary or artistic production of which he is the author.’ In the Article 29 Working Party’s (A29WP) letter to ICANN dated April 11, 2018, the A29WP “welcome[d] the decision of ICANN to propose an interim model which involves layered access, as well as an “accreditation program” for access to non-public WHOIS data.” This communication signaled A29WP’s support for a standardized access program. This support is further echoed, in a May 27 communication to ICANN, in which the EPDB reiterated that it expects ICANN “to develop and implement a WHOIS model which will enable legitimate uses by relevant stakeholders, such as law enforcement, of personal data concerning registrants in compliance with the GDPR, without leading to an unlimited publication of those data.” With respect to the reference to “relevant stakeholders,” ICANN has identified “intellectual property rights holders as being such stakeholders with a legitimate interest in having access to registrant data.		Intent and wording of this recommendation requires amendment	The accuracy requirements under the ICANN contracts and consensus policies should be reflected in the EPDP recommendations, particularly because accuracy is itself a fundamental component of the GDPR. Greater accuracy will enhance the objectives of compliance with GDPR while maintaining the WHOIS framework to the greatest extent possible, since accuracy is a common element of both sides of that equation. Therefore, INTA proposes that the EPDP consider requirements to include in its policy recommendations that will support maintaining and enhancing accuracy in the DNS, such as: ● Additional validation - currently only one field is validated as operational under the RAA (email or telephone number). The EPDP should consider how to expand the validation requirements to include other fields. ● Enhanced compliance tools - ICANN should be given broader powers to investigate the steps taken by a registrar in respons to a complaint of inaccuracy, and to require registrars with unacceptably low accuracy rates to submit remediation plans. ● Cross-field address validation - ICANN should implement this requirement under the 2013 RAA. ● Rectification- ICANN should ensure that there is a standard, robust process for data subjects to have their data corrected. ● Accuracy Reporting System -- ICANN should continue publishing its periodic Accuracy Reports, and the policy should allow ICANN the ability to access the full WHOIS records necessary to conduct this analysis.	GDPR Article 5 states that personal data shall be "accurate and, where necessary, kept up to date; every reasonable step must be taken to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay." The Information Commissioner’s Office in the UK (ICO) points out in its “Principle (d): Accuracy” that one of the new features of GDPR as compared to the principles under its predecessor is that there is now a “clearer proactive obligation to take reasonable steps to delete or correct inaccurate personal data.” The ICO notes that “[i]n order to ensure that your records are not inaccurate or misleading in [the case of personal data someone else provides], you must: ● take reasonable steps in the circumstances to ensure the accuracy of the information; and ● carefully consider any challenges to the accuracy of the information.” The ICO goes on to say that “The more important it is that the personal data is accurate, the greater the effort you should put into ensuring its accuracy. So if you are using the data to make decisions that may significantly affect the individual concerned or others, you need to put more effort into ensuring accuracy. This may mean you have to get independent confirmation that the data is accurate.” The accuracy of WHOIS significantly affects not just the registrant but those third parties that access WHOIS for legitimate purposes such as intellectual property infringement of all types. The EPDP has been chartered to ensure that the new WHOIS policy complies with all of the principles of the GDPR. As a result, its work is not complete until it conducts a careful analysis of GDPR’s accuracy principles, and updates the WHOIS policy to address the unacceptably low levels of accuracy that exists today.		No, I wish to continue to the next section	Yes		Separately submitted			Optional	The collection of technical information should not be mandatory. However, the OPTION for registrants to provide technical information should be required as some may wish to provide this information in order to route the appropriate communications within their organization. Therefore, INTA supports the position that Registrars should be required to provide registrants with the “OPTION” to provide Technical Contact information, although provision of this information by registrants should not be mandatory.	Yes	INTA's rationale is the same as described above: Collection of techinical data should not mandatory. However, the OPTION for registrants to provide technical information should be required as some may wish to provide this information in order to route the appropriate communications within their organization. Therefore, INTA supports the position that Registrars should be required to provide registrants with the “OPTION” to provide Technical Contact information, although provision of this information by registrants should not be mandatory.	No	Collection of Billing and Administrative Contact information should not be mandatory. However, the OPTION for registrants to provide this information should be required as some may wish to provide this information in order to route the appropriate communications within their organization. Therefore, INTA believes that Registrars should be required to provide registrants with the OPTION to provide Billing and Administrative Contact information, although provision of this information should not be mandatory.										Support recommendation as written	Yes				No	INTA supports publication of Registrant Email, Organization, and Registrant City. None of these data elements should be redacted.	Submitted separately	No	The Organization field is critical for being able to determine additional non-private information about a particular Registrant. If a Registrant is associated with a rights holder or their partner, the rights holder will be able to identify that perhaps only if the Organization field is not redacted. Being able to see this information can offer rights holders an opportunity to identify and work with registrants outside of the UDRP or other dispute resolution system and make more educated decisions about whether or not a given domain name is malicious or not. As explained more thoroughly below, appropriate instructions can be given so as to avoid the Organization field containing personal identifying information.		Support recommendation as written			Separately submitted	Delete recommendation		Separately submitted	Separately submitted					Separately submitted.	Separately submitted.	The question assumes the conclusion: that there are some risks associated with differentiation. It does not ask the converse question: whether there are any risks associated with not requiring (but merely permitting) differentiation such as the substantial risk of fragmentation that will result if each Contracted Party is permitted to make its own determination on the basis of its own unique risk tolerance.	Considering the risk of fragmentation from a permissive regime and existing examples where a legal/natural differentiation is already made, INTA is of the view that this distinction is necessary and practicably achievable. The solution that the Contracted Parties/NCSG have proposed (namely, that differentiation between natural and legal persons should be permitted, but not required) appears to suit the conveniences of those parties, but is an incongruous means of addressing the purported risk of possible inadvertent disclosure of personal data relating to natural persons who work for or represent a legal person – such as natural persons who manage administrative or technical issues on behalf of a legal person registrant. The EPDP should not ignore that if policy makers and legislators had intended the GDPR to cover a broader group of data subjects, they would have specifically said so. While implementation may be a challenge, ICANN should not through its policies effectively extend the reach of the GDPR to an entirely separate class of data subject.	Separately submitted.	INTA welcomes further study on procedures that could improve the means to distinguish between different Registrants for the purposes of more accurately and precisely applying the GDPR. As noted, the Guidelines on the territorial scope of the GDPR recently issued by the EDPB shed a great deal more light on what factors need to be taken into account and should be considered along with additional data about how the Registries and Registrars that are already making these types of differentiations (namely, geographic differentiations; or legal person vs. natural person differentiations) have already been able to do so.	Yes, the registry that operates the .TEL gTLD makes this differentiation as does the .eu ccTLD. See https://www.do.tel/wp-content/uploads/2017/05/Whois_Policy.pdf , “With respect to the amount and type of domain name registrant data provided in response to queries of the WHOIS service by the general public, the WHOIS service will distinguish between domain name registrants that are companies, businesses, partnerships, non-profit entities, associations, or other types of legal constructs (‘Legal Persons’), and domain name registrants that are human beings, perceptible through the senses and subject to physical laws (‘Natural Persons’). Domain name registrants will be required to specify whether they qualify as Legal Persons or Natural Persons by clicking the appropriate box during the registration process.” See also https://eurid.eu/d/205797/whois_policy_en.pdf.	Support intent of recommendation with edits	INTA recommends the clause: “Furthermore, the EPDP Team recommends that criteria around the term “reasonable” are further explored as part of the implementation of these policy recommendations addressing:” be amended to read: “Furthermore, the EPDP Team recommends that definitions, criteria and processes around the term “reasonable access” will be determined as part of the final policy including how to address:”	Separately submitted							No, I wish to continue to the next section
16	12/20/2018 13:21:58	George Kirikos	Leap of Faith Financial Services Inc.	No		No, I would like to continue to the next section	Support Purpose intent with wording change	Change (II) to "To ensure that a registered name holder may exercise its rights in the use, disposition, transfer and recovery of the registered name; and"	While the original language is a good starting point, "disposition" is somewhat ambiguous. I believe it's important to explicitly add "transfer and recovery" within the text. Facilitating and recording domain name ownership transfers (assigning the rights to a subsequent registrant) are important purposes of the processing of registration data, and should be explicitly documented in the language. Furthermore, recovery of domain names (e.g. when domain names are stolen, or fraudulently transferred) is of critical importance to registrants, and a further purpose for the processing of the registration data. Establishing the provenance of a domain name via the historical WHOIS records is of critical importance to the current registrant (otherwise the domain name's ownership would always be in dispute, thereby devaluing it not only for the current registrant, but future registrants). In other words, trust is established when one can document the ownership history, and that's a legitimate purpose of processing the data. This is somewhat hinted at in (I), i.e. "to establish the rights of a registered name holder", but again that language is somewhat ambiguous, because some folks might interpret the current language in the narrowest possible manner (i.e. contemporaneously only, for the current registrant), without contemplating past/future registrant changes via domain transfers to new registrants. I believe it's important to be explicit, so that there is clarity for everyone on these issues. As an alternative, those two additional terms (transfer and recovery) could be added as a 4th bullet point, instead of changing the 2nd bullet point (i.e. the 3rd bullet point is related to domain creation, and so a 4th bullet point could be laser-focused on transfer and recovery of a domain name). [While the above might be hinted at in purpose #2 (i.e. "maintaining the security, stability, and resiliency"), I don't think it's sufficiently explicit. It needs to be explicit, in order to avoid future disputes about the "meaning" of the language.] To be clear, domain recovery doesn't only take place via the TDRP, but can also be done via the courts (thus the proposed limitations on retention of data in the report to only the time limits of the TDRP are unrealistically short).	Support Purpose as written		Domain names are valuable assets (worth hundreds of thousands or even millions of dollars) with a lengthy lifetime (i.e. not short-term disposable services like contracts for Netflix or electricity which are fungible and where no historical record is needed). Thus, it's essential that security and stability be maintained, including the provenance of domain name ownership (see my earlier comments for Purpose 1). Legitimate 3rd party interests should include the court system.	Support Purpose intent with wording change	add "and/or legal issues"	"Administrative issues" is ambiguous. Adding "legal issues" explicitly ensures that registrants will receive communications relating to those disputes. Given that purpose 6 (below) currently limits things to ICANN-related policies, as opposed to broader disputes outside of ICANN's remit (e.g. disputes in the courts), I think it's important to add the language into Purpose #3.	Support Purpose intent with wording change	PROVIDE MECHANISMS FOR SAFEGUARDING PAST AND PRESENT REGISTERED NAME HOLDERS' PAST AND PRESENT REGISTRATION DATA IN THE EVENT OF A BUSINESS OR TECHNICAL FAILURE, OR OTHER UNAVAILABILITY OF A REGISTRAR OR REGISTRY OPERATOR	Adding "past and present" before "registered name holders'" and also before "registration data" is important, to ensure that it's not just a current snapshot of current data that is being retained, but an entire history of both current and past registrants' data, in escrow. If only a current snapshot is maintained, critical data would be lost in the event of a business or technical failure, etc.	Support Purpose intent with wording change	There should be a comma added after the word "complaints", otherwise there's ambiguity! (i.e. the whole Oxford/serial comma debate --- probably want to double-check the document for other instances of this) Even better, perhaps delete " SUBMITTED BY REGISTRY OPERATORS, REGISTRARS, REGISTERED NAME HOLDERS, AND OTHER INTERNET USERS" -- since literally everyone of significance is an "internet user" these days, that essentially makes all that text unnecessary!	I'd like to highlight the importance of "audits", as that requires maintenance of a historical record (i.e. audit trail)	Significant change required: changing intent and wording	Delete the words "namely, the UDRP, URS, PDDRP, RRDRP, and future-developed domain name registration-related dispute procedures" and keep all the rest.	I'm concerned that the current language is too limiting, as noted earlier in discussion of purpose 3, as there can be disputes directly in the courts, outside the UDRP, URS, and other ICANN-developed policies. Thus, either purpose 3 should be adjusted, or purpose 6 should be adjusted accordingly. By deleting the named policies, this would have the effect of broadening things to resolution of non-ICANN policy disputes.	Support Purpose as written		Seems reasonable as is without changes.		As discussed earlier, establishing the provenance and ownership history of a domain name is critical. Thus, "transfer" and "recovery" should be explicitly added within the aforementioned text (need not be a separate purpose, but can be appended to existing points). Research and Journalism should also be explicitly permitted uses.	Domain names are valuable assets (worth hundreds of thousands or even millions of dollars) with a lengthy lifetime (i.e. not short-term disposable services like contracts for Netflix or electricity which are fungible and where no historical record is needed). If an overly-restrictive interpretation of GDRP and privacy interests is made, that erasure of historical ownership records will have a severe impact on the ability of a registrant to demonstrate to others that they were a past registrant (for domain recovery purposes), and also to demonstrate to others that they're a legitimate current registrant (as opposed to a domain name thief who happens to have their data in the current WHOIS). It is imperative that these historical records be maintained, for the benefit of the current registrant, past registrants (through domain recovery), and future registrants (who can demonstrate proper ownership, by referencing an audit-trail of the historical ownership). Furthermore, research and journalism are important in a free society, to help uncover matters of public interest. ICANN should not "accredit" journalists, either, because citizen journalism is a part of journalism too.	No, I wish to continue to the next section	Delete recommendation		All WHOIS should essentially be public, and not gated. My company wants to always opt-in to public WHOIS for our own data, and mechanisms should be in place to require registrars to permit this opt-in (some have not yet done so, despite the temporary spec!) But, I do respect that some seek privacy (opting in to that). I don't think ICANN should be developing that system, but instead there is an alternative, namely putting it in the hands of the courts, using a mechanism like we have in Canada for "Norwich Orders", see: https://www.lerners.ca/lernx/norwich-orders/ or https://en.wikipedia.org/wiki/Norwich_Pharmacal_order or search Google "Norwich Orders" to find more. I believe an ICANN-developed system will be ripe for abuse (i.e. overreach by trademark interests, for example), and would have limited penalties, whereas abusers of a Norwich-type order could be penalized by the courts. Furthermore, courts recognize that intermediaries (e.g. registrars/registries) would be entitled to reasonable cost recovery, as per the recent judgment in the recent Supreme Court of Canada involving Rogers and Voltage Pictures, see: https://scc-csc.lexum.com/scc-csc/scc-csc/en/item/17254/index.do Again, I emphasize that I want the WHOIS to be public, but if folks are going to insist on privacy for some of that data, the courts (of a competent jurisdiction) are the right place, not ICANN. To be clear, a competent jurisdiction should be the jurisdiction of the entity holding the data (e.g. location of registrar or registry, as the case may be, depending on whether it's a thin or thick WHOIS system in place). As an aside, returning to thin WHOIS might be best, to allow those who are concerned about privacy to choose a registrar in an appropriate jurisdiction that suits their own needs.	ICANN has long been subject to gaming, and taking this out of ICANN's hands seems best. Otherwise, various camps will do their best to create a policy that includes themselves, to gain an advantage, and to exclude others. Once a policy is adopted, it would be nearly impossible to change it (as seen by past policy mistakes by ICANN), as a party used to gaining an advantage eventually considers it an entitlement.	Support recommendation as written		Seems reasonable as written, no change required.		No, I wish to continue to the next section	Yes		These are needed to help document ownership of a domain name to the public, and to also allow the public to communicate with a registrant.	1. There needs to be an additional field to provide clarity regarding whether the registrant is the "Name" or whether it is the "Organization", as the current data collected makes it ambiguous! This has been a known problem for a long, long time. For example, if the "Name" is "John Smith" and the "Organization" is "Acme Inc.", then is the true registrant the corporation, and John Smith is the employee at the corporation who receives the correspondence? Or, is the true registrant "John Smith" (an individual), who currently happens to work for "Acme, Inc."?? That ambiguity can cause immense legal problems, tax issues, disputes over ownership, etc. It's time to fix that, now. 2. Tech Field: should include all the fields (optionally for the registrant, but mandatory for the registrar to offer to collect them) as the registrant field, i.e. address, postal code, phone, fax, etc. Simply a name, phone number and email are insufficient. 3. Admin Fields: these should be restored, as per the current WHOIS! (i.e. all fields like the registrant). The admin within an organization is separate from the registrant. Make it optional if need be. 3. "Name Server" should be plural, i.e. all name servers (not just 1). 4. There should be an optional "Legal Contact" (with all the same field types as the registrant, i.e. address, phone, fax, etc.), akin to a "Registered Agent for Service" in many jurisdictions for corporations.	Some folks consider the "Tech Fields" or "Admin Fields" as something that can be eliminated, in the name of data minimization, as it's often the same as the registrant. But, the "Admin Fields" and "Tech Fields" are often used to direct communications of certain types expeditiously to the appropriate contact, and as a secondary/backup contact (e.g. for UDRP/URS, where notice must be sent to everyone in the WHOIS), see Section 2(a)(i) of the UDRP policy at: https://www.icann.org/resources/pages/udrp-rules-2015-03-11-en Thus, there's important redundancy achieved by having these multiple contacts in the WHOIS. That redundancy is also important for recovery of stolen domains (i.e. often some fields in the WHOIS go bad, or are hacked, and it's through contact with secondary/backup contacts like the tech contact that one can get in touch with the true owners). There are important benefits to redundancy, and they should not be underestimated. The Legal Contact matches the proposal I made in the RPM PDP working group, and is another important source of redundancy, especially when a timely response is needed (e.g. to respond to a lawsuit or other dispute). A registrant might be on vacation, and having their lawyer's contact info available in the WHOIS protects the registrant, if the rules require that the Legal Contact be notified of complaints too (i.e. the registrant would still get contacted). The URS Proposal in the RPM PDP can be found at: https://community.icann.org/download/attachments/93126760/URS-Proposal-7.pdf?version=1&modificationDate=1537972994000&api=v2 Just as there are multiple forms of communications in the WHOIS for redundancy (i.e. phone/fax/physical address), and multiple nameservers for redundancy for DNS requests, it is important that there be allowed multiple separate contacts (different people), at the discretion of the registrant, as an additional form of redundancy. There should not be single points of failure, as that increases risk for registrants! [If it's decided that these additional contacts for redundancy are not permitted, I'd strongly recommend that additional (optional) fields be allowed for the "Registrant" field, e.g. secondary and tertiary email addresses, secondary and tertiary phone, secondary and tertiary fax, instead of just a single one. That way, a registrant can use multiple email providers (as a method of redundancy), multiple phone numbers and fax numbers, to direct communications to multiple people.]	Optional	Registrants who don't care about redundancy can opt-out.	Yes	It is imperative that those registrants who prize redundancy (i.e. to ensure that there are ways to be reached, if one method fails) have the ability to add these secondary contacts, as discussed above.	No	Disagree. These provide important redundancy benefits, and should continue to be collected (optionally for registrant). If they are not collected, then, as per above, optional secondary and tertiary contacts should be permitted.	For the "updated date" field, it's unclear whether that's a registry or a registrar provided date. It should be made explicit (e.g. for a thin registry like .com, a change at the registrar of some fields would not change the registry WHOIS). So, it should be labelled appropriately in the WHOIS output (or maintain 2 different updated dates, i.e. last updated at registry, last updated at registrar).	No	Domain Name, Updated Date, Creation Date, Registry Expiry Date, Registrar, Name Servers (plural for nameservers!)	To accommodate privacy concerns in a multinational contact, I'd be supportive of returning to the "Thin WHOIS" model, just like .com, so most of these fields are not necessary (just the obvious ones like nameservers, registrar are needed, as per the current output of Internic.net for WHOIS of .com domains).	By returning to the "Thin WHOIS" model, this would permit registrars to comply with their national obligations, and reduce compliance issues for registries. A European registrant can pick a European registrar, for example. Registrars with clients from multiple countries can get a separate registrar accreditation located in Europe, to serve European customers, and not have to impose GDPR on North Americans (many of whom don't want it!). Registries don't really need this data, in most cases (as the success of .com has illustrated!). A subset might be needed by registries in a few special cases (e.g. for .bank, proof that one is a financial institution, etc.).	Support intent of recommendation with edits	As new fields are collected by registrars (as per responses to Recommendation #4 already provided), they too should be put into escrow, to protect the registrant's data in case of registrar failure, etc. (i.e. witness the Registerfly fiasco, in case folks have forgotten). ALL data should be escrowed, including historical data, for an audit trail (to ensure recovery from domain thefts, too).	One word: Registerfly!		Support intent of recommendation with edits	Yes		Ensure that as new fields are added (as Rec #4 fields are changed, due to public input), that these additional (sometimes option) fields are added into Rec #7.		No	ALL elements should not be redacted.	Under the proposed recommendation, registrants would be unable to easily demonstrate via the WHOIS that they are the owners of their own assets! This would greatly degrade the value of domain name assets, and expose domain names to issues like identity theft (where others can pretend, with impunity, that they are the owners of a domain name, when in fact they are not). If you're going to permit redaction, please ensure that registrants can OPT OUT of redaction, and OPT-IN to full publication of their own WHOIS data. The purported reason for the GDPR is to give owners of data control over it, but the current recommendation doesn't allow me, as a registrant, to make it public! (it appears, reading the text as is, that the registrar has no choice and must redact!). Here's another possible solution (that others might not have considered), namely allow registrants to run their own WHOIS service for their own domain names. In the case of .com (a thin WHOIS registry), we essentially have the main WHOIS info become the responsibility of the registrar to publish. Thus, the registry essentially redirects those seeking full WHOIS to the registrar. Why not add one new level of redirection to this? We can make the registrar also be a "thin WHOIS" provider, who would redirect requests for full WHOIS output to the registrant. Thus, the registrant can have control over publication of their data. Using digital signatures, the published WHOIS output from the registrant's WHOIS server would publish both the data and a signature. Since the registrar has all the data too (but doesn't publish it), all the registrar needs to do is publish a cryptographic signature (without the data). If the cryptographic signature from the registrar matches the signed data published by the registrant, then one can be assured that the WHOIS contact data is valid (and matches what the registrar isn't itself publishing). In other words, by delegating the task of publishing the WHOIS to the registrant themselves, many of the legal liability issues generated by GDPR of registrars and registries disappear.	No	A registrant who wants to prove they are the owner of their own domains wants to have these fields published.	This is a truly horrible recommendation, and would not allow registrants to publish their own data in the WHOIS, to demonstrate to others definitively that they are the owners of their own domains. Redaction should be optional, and not be forced upon those who want their data to be public. Adoption of this recommendation would diminish trust in the DNS. Imagine if you couldn't look up your own property records for real estate at the land registry, and allow others to see them publicly, for example, to prove to others that you're the owner of your own house? There are a lot of shady registrars, who would be able to seize the assets of a registrant, because the registrar could no longer prove that they are the owners of their own domain names! The public WHOIS provides an important verification benefit, to prevent this and other types of abuse. I simply fail to see how the other constituencies (outside the IPC and BC, who also oppose this recommendation) can justify mandatory redaction, even when the registrant themselves doesn't want the data redacted. If it's due to liability concerns (for registrars and registries), see the comments 2 fields above on this form, where I proposed allow registrants to run their own WHOIS servers to show their own contact details (which can be verified using digital signatures, and registries/registrars need only publish the signatures or a cryptographic hash, instead of the underlying data).	Support intent of recommendation with edits	One needs to provide better guidance as to which entity is actually the legal registrant, i.e. the "Organization" or the "Name" (see below).	As discussed previously, there is much ambiguity over the Organization Field. If John Smith of Acme Inc. is in the WHOIS, is "John Smith" the registrant, who happens to currently work at Acme Inc., or is Acme Inc. the registrant (the corporation), and John Smith is just a representative of the corporation. This ambiguity is long-standing, and needs to be fixed, as it can cause legal, tax and other issues if the true ownership is in dispute or unclear. I'd recommend adding additional fields, to unequivocally identify the registrant itself and their organizational type (e.g. see the CIRA model for .ca as guidance).		Intent and wording of this recommendation requires amendment	Make this a "MUST" if and only if a registrant hasn't opted to display their own info in the WHOIS!	Registrants need to be able to opt-out of this, and be able to show their own identity and email address instead in the public WHOIS, unfiltered by a registrar. A registrar's systems may be less reliable than that of a registrant, and a registrant shouldn't be forced to have their inbound communications be intercepted by the registrar's systems.	See earlier comments opposing mandatory redaction.	Intent and wording of this recommendation requires amendment	Make the minimum retention at least 6 years, consistent with various statute of limitations in the real world for crimes (property theft, etc.).	The TDRP is not the only mechanism that exists for domain disputes. Courts can also be used (and for some crimes, there might not be any statute of limitation, and certainly longer than 1 year for property crimes). When domain name thefts/disputes occur, it's important to have a full audit trail of past WHOIS records, and the proposed policy would thwart that, because it would destroy data after 1 year of a registrar change (registrars often change when domains are stolen). Registrants should at a minimum be able to opt-in to a longer period, but the minimum period should be at least 6 years.		The desires of the registrants themselves are often not being considered (see below). These need to be at the forefront of the analysis.	I agree with the BC that the GDPR should not be overapplied, and that registrants should not be thwarted from having their own data published in the WHOIS. I'm in Canada, and my company's WHOIS data is currently being redacted, against my desires, which is a major detriment. Open and public WHOIS has major benefits which are not being recognized by some quarters of the EPDP team, even when the registrant WANTS their own data to be fully public (to be able to fully document ownership of their own assets). Security through obscurity is a fallacy. Registrants who know this, and want security through public exposure of their contact info, should be allowed to have it published.						Intent and wording of this recommendation requires amendment	Timelines should also be made for allowing opt-in by registrants to public WHOIS.	It has been 7 months since GDPR went into effect, and some registrars still haven't implemented a method for registrants to opt-in to public WHOIS. "Commercially reasonable" hasn't been defined, but surely it shouldn't take this long to be able to show one's own WHOIS, if one wants to opt-in to do so.							No, I wish to continue to the next section
17	12/20/2018 13:41:48	Greg Aaron	iThreat Cyber Group	Yes	iThreat Cyber Group	No, I would like to continue to the next section	Support Purpose intent with wording change	RE: "(III) TO ACTIVATE A REGISTERED NAME AND ALLOCATE IT TO THE REGISTERED NAME HOLDER"... what does "activated" mean -- resolve? It is an undefined term not used in the industry. Registered domain names do not ever need to resolve or be "activated" -- they need to be "registered to a name holder". Also, Purpose 1 assumes that "To ensure that a Registered Name Holder may exercise its rights in the use and disposition of the Registered Name" is synonymous with the registrants right to manage their domain. However, the report does not explain why this equivalence is true or guaranteed.		Support Purpose as written			Support Purpose as written			Support Purpose as written			Support Purpose intent with wording change	Add "ICANN" to the list of parties who may submit compliance monitoring requests.		Purpose should be deleted			Support Purpose as written						No, I wish to continue to the next section	Support intent of recommendation with edits	The EPDP WG needs to state clearly in the report that it will not have the time to really consider this charter subject before it completes its final report. Between now and the final report due date, the EPDP WG has to consider public comments, measure consensus levels, and more, and likely will not break new ground.			Intent and wording of this recommendation requires amendment	"The GDPR has requirements for data accuracy, but there has been no adequate evaluation of whether ICANN's existing accuracy procedures comply with the GDPR."			No, I wish to continue to the next section	Yes			A) The 2013 RAA's WHOIS Accurary Program Specification requires that registrars collect "Account Holder" identity. "Account Holder" is a legally defined term in the RAA, and this party may be different from the "Registered Domain Holder" or Registrant. The report must make clear that the "Account Holder" MUST be collected by the registrar and the data and data field MUST NOT be provisioned to the registry or displayed in RDDS. Account Holders have contractual obligations described in the RAA -- such as in the RAA's WHOIS Accuracy Program Specification. B) The RAA's Data Retention Specification section 1.2 requires that registrars collect a number of additional fields not in these tables. While these fields and data should not be displayed in RDDS, and should not be provisioned to a registry, any Recommendations and a revised Temp Spec should make clear that registrars are still required to collect those fields, and they may be requested by ICANN for compliance purposes. c) At present, the Initial Report could be interpreted to mean that the RAA requirements mentioned in A and B above will be done away with, because the collection of this data is not listed. The final report needs to make clear that the requirements above will remain in place. The EPDP WG really needs to be crystal clear about the entire set of data that data MUST be collected.		Optional		Yes	Contactability and the resolution of technical problems on the Intenet.							A full "Tech Contact" (object) should be offered to registrants to take advantage of, not the half-way "Tech Fields" concept.	Support recommendation as written				Intent and wording of this recommendation requires amendment	Yes		The 2013 RAA's WHOIS Accuracy Program Specification also requires that registrars collect "Account Holder" identity. The RAA's Data Retention Specification section 1.2 also requires that registrars collect a number of additional fields not in the tables. Any Recommendations and a revised Temp Spec should make clear that registrars are still required to COLLECT (but not display) those fields, and they may be requested by ICANN for compliance purposes.		No	All registrant fields MAY be displayed. Registrant City. Technical Contact Name, Technical Contact Phone, Technical Contact Email	1) The report seems to make a HUGE change to the current Temp Spec. The current Temp Spec says that Registry Operator and Registrar MUST redact ONLY WHERE the data subject or processing activity is covered under GDPR. They MAY publish registrant data such as name and address where the data subject or processing activity is NOT covered under GDPR. That protects parties under GDPR and is fine. But Rec #8 now says that registrant fields such as name and address MUST ALWAYS be redacted. That is a huge expansion of blocking. The current Temp Spec's qualifications and guidelines for redaction are missing, and without them the recommendation is an immense change. This many not have been the intent of WG, but it's what the plain language of Rec 8 says. Rec 8 needs to at least go back to the the Temp Spec's qualifications. 2) It would be preferable if contact fields such as name and address are redacted ONLY IF protected by GDPR or another applicable privacy law. Along with that needs to be a program to provide some surety. But so far we don't think the data protection authorities are going to penalize any registrar or registry operator if a registrant mi-identifies its country of residence, natural-versus-legal status, etc. The risk is on the registrant there, and legitimate interests balance it. It is not ICANN's role to create a blanket base privacy regime of the world; it is ICANN's role to facilitate compliance but not to force parties to go beyond it. 2) The entire point of collecting a Tech Contact is to DISPLAY it, so tit can be seem by the public. So there needs to be better discussion of why the Tech fields would be redacted from publication. If the data is provided, then there can be a mechanism for the registrant to attest that the data has been provided with the data subject's permission. The GDPR was not designed to make such things impossible. 3) It is strained to claim that Registrant City is personally identifiable.	No	The GDPR does not protect the data of legal persons. The existing data in teh field should not be displayed yet but there should be a requirement put in place to get registrants to tell them that ht field is for legal person info, and review what is in this field going forward.	The EPDP is mainly about evaluating and revising the Temp Spec. But the Initial Report makes it very hard for readers to figure out what a resulting Temp Spec might look like based on the recommendations. The EPDP must include a red-lined version of the Temp Spec in its next report, so the community can understand and comment on it. Right how the potential results and implications are pretty opaque. See comment #1 on Rec 8 above for an example.	Intent and wording of this recommendation requires amendment		There should be a requirement put in place to tell registrants that the field is for legal person info, and information placed in it will (eventually) be published.		Intent and wording of this recommendation requires amendment	No one knows if the messages are getting sent on to the registrants. So while there's a requirements no one knows if its working or if its enforceable (or if compliance work is being executed). As a result contactability (for UDRP, abuse, etc.) is possibly crippled.			Support recommendation as written				The current Temp Spec allows RDDS operators complete freedom to choose when to redact domain contact data from publication, whether or not a domain contact is protected by GDPR or by any other local privacy law. The result has been blanket redactions, hiding more data than is legally called for. A more balanced and justified approach is needed. Redact data for data subjects covered under GDPR, but don't redact for those not covered by the law.			The Initial Report does not discuss or weig the risks of over-redaction, such as how it inhibits contactability, anti-abuse and law enforcement efforts, and accuracy complaints. The act of balancing has not been performed adequately.		Yes, there should. See above.	Yes. See RIPE-NCC's relevant policies and practices. Nominet procedures for indicating and validating legal versus natural versus "commercial use".	Intent and wording of this recommendation requires amendment	The current "requirements" are so vague as to be unworkable and unenforceable. there do need to be more specific, measureable, enforceable requirements of the kinds contemplated in Rec 12. At minimum, the following are easy to implement immediately: 1) Links and instructions for data requests must be placed on registrar and registry operator web sites 9just like they are required to have abuse links and contacts on home pages per the ICANN contracts.) 2) Contracted party must provide written acknowledgement of receipt of the request, and 3) must return a written response with either the data or the reason for the rejection, within three days.								No, I wish to continue to the next section
18	12/21/2018 12:29:08	Sara Bockey	GoDaddy - ICANN accredited Registrar	Yes	Provided input to Registrar Stakeholder Group response and provide individual response on behalf of GoDaddy.	No, I would like to continue to the next section	Support Purpose as written		We maintain our stated concerns with the use of the term ”rights’, in the context of a commercial service contract. Any modification or deletion of the qualifying introduction (”As subject to...”) will negate our support for this purpose. Stated another way, our support for this language is contingent on the inclusion (”As subject to...”).	Purpose should be deleted		GoDaddy concurs with the RrSG position that ICANN's mission does not explicitly include enabling third party access to registration data. Third party access may be found to be a legitimate secondary purpose. GoDaddy reminds ICANN that it received guidance from the EDPB on this topic in a letter dated 5 JUL 2018, which cautioned against conflating ”its own purposes with the interests of third parties.” https://edpb.europa.eu/sites/edpb/files/files/news/icann_letter_en.pdf	Support Purpose intent with wording change	Enable the provisioning of domain name registrations, including, to the extent necessary, communication with the RNH, or their designated agent, of any technical or administrative issues that would impact such registration.	Recommendation is poorly written and contains excess wording to no benefit.	Support Purpose intent with wording change	PROVIDE MECHANISMS FOR SAFEGUARDING REGISTERED NAME HOLDERS' REGISTRATION DATA IN THE EVENT NECESSITATED BY A BUSINESS OR TECHNICAL FAILURE OF A REGISTRY OPERATOR OR REGISTRAR.		Support Purpose intent with wording change		Have ICANN established the necessity to process personal data for contractual compliance matters? Can Contractual Compliance not accomplish what they require without access to personal data itself? To the extend ICANN establishes the necessity to process personal data for contractual compliance matters as intended, then we would agree it is acceptable only upon the adoption of appropriate limitations and provisions governing the processing of such data for this purpose by ICANN as a controller. While GoDaddy supports the purpose, namely the ability of ICANN to enforce compliance of its agreements (RAA, RA) with Contracted Parties, where applicable, it is acceptable only upon adoption of appropriate limitations and provisions governing the processing of such data for this purposed by ICANN as a controller. Programs that monitor or audit registration data must also be clearly defined before they can be included as a component of this purpose. Execution of a JCA (or other appropriate data processing addendum) between the responsible parties will be a necessary prerequisite to implementation of any obligations resulting from this ePDP.	Support Purpose intent with wording change	ESTABLISH, 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 DISPUTE PROCEDURES FOR WHICH IT IS ESTABLISHED THAT THE PROCESSING OF PERSONAL DATA IS NECESSARY		Support Purpose intent with wording change	Replace “CRITERIA VOLUNTARILY ADOPTED BY THE REGISTRY OPERATOR” with “WHERE APPLICABLE AND AS VOLUNTARILY ADOPTED BY THE REGISTRY OPERATOR AND SUPPOSED BY REGISTRARS OFFERING THAT GTLD.”	“Criteria” may not be applicable to GDPR or other data protection laws, and Registrars offering the gTLD must also voluntarily support this purpose as a precondition to offering the gTLD.				No, I wish to continue to the next section	Delete recommendation		This is a statement of something already in the charter. It is not a recommendation. As such, it should be removed. We welcome the opportunity to explore this topic further after the EPDP has concluded.		Support recommendation as written				No, I wish to continue to the next section	No	Due to optional fields (ie tech contact)				Optional		No	This should be a business decision.	Yes			No	All contact records that are currently redacted under the Temp Spec.	Registries have not demonstrated that they need full WHOIS data for the DNS to function. Furthermore, they have not provided the legal justification for their potential use of this data that is not already covered by other purposes. If and when these conditions are satisfied, we are not opposed to sharing this data with registries.		Intent and wording of this recommendation requires amendment		We support the concept of data escrow as a safeguard against registrar, technical or business failure. However, we must insure that the data submitted under this program is legally and technically (encryption) protected, and otherwise aligns to the limitations and considerations adopted for the legal and proper processing and protection of data.		Support intent of recommendation with edits	No	Not all purposes proposed in Annex D are purposes for processing data and request for disclosure should be specific and proportionate to the issue being addressed.	GoDaddy supports the purpose, namely the ability of ICANN to enforce compliance of its agreements (RAA, RA) with Contracted Parties, where applicable. However, this purpose is contingent on the resolution of ICANN’s status as a data controller or joint controller. Programs that monitor or audit registration data must also be clearly defined before they can be included as a component of this purpose.		Yes			Yes	In a perfect environment registrant org would not be redacted. However, because there is 20+ years of legacy WHOIS data in circulation that was obtained (often in violation of WHOIS terms of use), resold, and archived, the registrant org field is being used as an “index” to match redacted records to unredacted archives. Because of this ability to indirectly identify subjects, many of whom may be nature persons, we believe the existence of these archives means we must treat registrant org as personal data.		Delete recommendation		Because of the challenges associated with the standardized use of the registrant org field, and the fact that it is used in conjunction with WHOIS archives to indirectly identify data subjects, it is not clear what guidance registrars should be providing to registrants on the use of this field. We are open to further research in this area.		Support intent of recommendation with edits	Delete: “… an email address…”	GoDaddy strongly encourages registrars to implement web contact forms rather than “relay” email addresses, as the later will become compromised rapidly following their publication.		Support intent of recommendation with edits		While we support the intent of this recommendation it is important to ensure that any retention period is lawful. This recommendation should be edited to allow for registrars to choose to retain data for longer than one year if applicable law or other guidance suggests longer than a one year data retention period.		Contract Parties should be permitted to differentiate, if they choose, but it should not be required.	GoDaddy’s position on this topic has been previously noted here, https://mm.icann.org/pipermail/gnso-epdp-team/2018-November/000749.html	The distinction between registrants based on geographic regions does not currently exist in the Domain Name System. Therefore, any recommendation mandating this change is outside the scope of the ePDP, and possibly the “picket fence” of Registrar and Registry contracts.	GoDaddy’s position on this topic has been previously noted here, https://mm.icann.org/pipermail/gnso-epdp-team/2018-November/000749.html	Our high-level concerns are reiterated here: Legal: As other laws are less clear regarding the distinction between legal and natural, future regulations may run contrary to GDPR. Technical: a technical basis to reliably and confidently distinguish between legal and natural persons do not exist, and self-identification would be fraught with error creating unacceptable levels of risk. Commercial: There are practical challenges as well as significant cost, presuming a technology can be developed. Risk v. Benefit: Asymmetrical burden and risk placed on contracted parties for the exclusive benefit of unburdened third-parties. Scope: The distinction between Legal and Natural persons, or geographic regions, does not currently exist in the Domain Name System. Therefore, any recommendation mandating this change is outside the scope of the ePDP, and possibly the “picket fence” of Registrar and Registry contracts.			Intent and wording of this recommendation requires amendment	This recommendation should be rewritten to make the distinguish between law enforcement requests, private party disclosure requests, and pseudonymized access for research purposes.	The legal bases for these three use cases are different. Also, this approach will also be driving by whether ICANN or contracted parties will be required to fulfill disclosure requests.	Additionally, it is important to note and emphasize that “reasonableness” does not refer to the ease of access, but rather must take into consideration whether such access is lawful, because nothing is reasonable if it creates legal liability for the Contracted Parties.	Support recommendation as written		While we support the recommendation, it is with the caveat that the JCA will not equally allocate responsibility among the parties. Instead, it will identify which party is controller/processor for each set of processing in our rather complex ecosystem.			No, I wish to continue to the next section
19	12/20/2018 22:04:58	Jeremy Dallman, David Ladd – Microsoft Threat Intelligence Center; Amy Hogan-Burney, Richard Boscovich -– Digital Crimes Unit; Makalika Naholowaa, Teresa Rodewald, Cam Gatta -– Trademark; Mark Svancarek, Ben Wallace, Paul Mitchell –Internet Technology & Governance Policy; Cole Quinn – Domains and Registry	Microsoft Corporation	No		Yes
20	12/21/2018 2:37:56	Theo Geurts	RrSG	Yes	Personal observations	No, I would like to continue to the next section
21	12/21/2018 3:55:29	DR. JAIDEEP KUMAR MISHRA	DIRECTOR MINISTRY OF ELECTRONICS AND INFORMATION TECHNOLOGY, GOVERNMENT OF INDIA	Yes	MINISTRY OF ELECTRONICS AND INFORMATION TECHNOLOGY IS THE NODAL AGENCY OF THE GOVERNMENT OF INDIA TO DEAL WITH MATTERS RELATED TO INTERNET GOVERNANCE. THE APPLICANT IS JOINT SECRETARY INCHARGE OF INTERNET GOVERNANCE IN THE MINISTRY OF ELECTRONICS AND INFORMATION TECHNOLOGY AND ALSO REPRESENT AT THE GOVERNMENT OF INDIA AT THE GAC.	No, I would like to continue to the next section	Support Purpose as written	N/A	N/A	Support Purpose intent with wording change	THE EVENTUAL GOAL OF MAINTAINING THE SECURITY,STABILITY,AND RESILIENCY OF THE INTERNET DOMAIN NAME SYSTEM IN ACCORDANCE WITH ICANN'S MISSION AS SPECIFIED IN ITS BYLAWS, BY FACILITATING LAWFUL ACCESS FOR LEGITIMATE THIRDPARTY REQUESTS TO ACCESS DATA ELEMENTS COLLECTED FOR THE OTHER PURPOSES IDENTIFIED HEREIN.	Minor language tweaks for sake of clarity and being more explicit.	Support Purpose intent with wording change	ENABLE COMMUNICATION WITH AND/OR NOTIFICATION TO THE REGISTERED NAME HOLDER AND/OR THEIR DELEGATED AGENTS OF BILLING, TECHNICAL AND/OR ADMINISTRATIVE ISSUES WITH A REGISTERED NAME	Minor language tweaks for sake of clarity and being more explicit.	Support Purpose as written	N/A	N/A	Support Purpose intent with wording change	HANDLING CONTRACTUAL COMPLIANCE ENFORCEMENT ACTIVITIES AND AUDITS BY ICANN CONTRACTUAL COMPLIANCE DEPARTMENT, AS WELL AS ICANN’S ACTION ON REQUESTS AND COMPLAINTS SUBMITTED BYREGISTRY OPERATORS, REGISTRARS, REGISTERED NAME HOLDERS, AND OTHER INTERNET USERS	Minor language tweaks for sake of clarity and being more explicit.	Support Purpose intent with wording change	COORDINATE, OPERATIONALIZE, AND FACILITATE POLICIES AND ASSOCIATED RULES FOR RESOLUTION OF DISPUTES REGARDING OR RELATING TO THE REGISTRATION OF DOMAIN NAMES (AS OPPOSED TO THE USE OF SUCH DOMAIN NAMES), SUCH AS, THE UDRP, URS, PDDRP, RRDRP, AND FUTURE DEVELOPED DOMAIN NAME REGISTRATIONRELATED DISPUTE PROCEDURES FOR WHICH IT IS ESTABLISHED THAT THE PROCESSING OF PERSONAL DATA IS NECESSARY.	Minor language tweaks for sake of clarity and being more explicit. For domain name disputes resolution, there are policies as well as associated rules e.g. UDRP policy and UDRP rules.	Support Purpose as written	N/A	N/A	N/A	N/A	N/A	No, I wish to continue to the next section	Support intent of recommendation with edits	Per the EPDP Team Charter, the EPDP Team is committed to considering a system for Standardized, predictable, consistent and lawful Access to nonpublic Registration Data once the gating questions in the charter have been answered.	Minor language tweaks for sake of clarity and being more explicit.	N/A	Support intent of recommendation with edits	Wording of this recommendation should also clearly bring out both Verification and Validation aspects of WHOIS Accuracy, for example as Mentioned in 2013 RAA “WHOIS ACCURACY PROGRAM SPECIFICATION”	See #37	N/A	No, I wish to continue to the next section	Yes	N/A	N/A	N/A	N/A	Mandatory	Registrars should definitely offer the Technical name/contact fields (name, email, and phone) to Registrant. If Registrant fills these fields, filled values should be used. If left blank by Registrant, Registrant should be provided options to 1) either use Registrant details OR 2) Provide the details as specified of Technical Contact that they wish to name on their behalf such as Hosting Service Provider OR 3) use Registrar name, email and phone,( since Registrar is by default the technical point of contact for Registrant).		N/A	Yes	Billing and administrative contacts are redundant and seldom used for contact purpose. Accordingly, as per Data minimization concept in GDPR, contact information for billing and administrative contacts should not be collected.	N/A	Yes	N/A	N/A	A Thick Registry is the ultimate authority and repository for storing Registrant data. So all WHOIS data fields mentioned here should be transferred from Registrar to Registry.	Support intent of recommendation with edits	1 The EPDP Team recommends that ICANN Org enter into legallyenforceable data processing agreements with the data escrow providers, keeping in mind GDPR and other privacy regulations and regimes. 3 The data elements workbook that analyzes the purpose to provide mechanisms for safeguarding Registered Name Holders' Registration Data contains the specificallyidentified data elements the EPDP Team recommends be transferred by Registries and Registrars to data escrow providers (see Annex D, Workbook4).	Minor language tweaks for sake of clarity and removing typo errors.	N/A	Support recommendation as written	Yes	N/A	N/A	N/A	Yes	N/A	N/A	No	GDPR clearly states that it is not applicable to Legal persons. So clearly, Organization field signifying a legal entity should not be redacted. However, it should be clearly mentioned/ advised to Registrant by Registrar at the time of Registration to avoid putting name of an individual (natural person) in Organization field.	In this area, concerns about compliance with GDPR must guide the policy. Based on legal advice it received last year, ICANN org redacted most of the data fields regarding the registrant’s contact information in its Temporary Specification. The EPDP recommended the same set of redactions as the Temp Spec. Disagreements are at the margins. Privacy advocates would like to see the State/Province field redacted. The Intellectual Property interests would like to see both the State/Province and the City fields published. The EPDP has agreed that the Administrative and Technical Contacts will no longer be required data elements to be collected. These ancient data fields go back to the origins of Whois before ICANN existed, and serve little purpose, yet for some reason they were required elements in registrar contracts. In a very large portion of domain name registrations, the Admin-C and Tech-C are the same as the registrant. Based on the principle of data redaction, Admin-C will no longer be required, and it will be optional for a registrant to provide a technical contact. The EPDP is still considering whether registrars should be required to offer a Technical Contact field. It should be noted that for all practical purposes, the default technical contact for any registrant is the registrar, and registrar contact info is already automatically included in the public Whois. However, another question to be considered is whether ‘optional’ also means ‘optional’ for the registrar to offer the ability to the Registered Name Holder to provide these data elements or whether the Registrants should continue to be required to offer this ability. In either case, if the Registrar optionally provides this option or is required to provide this option, Registrars are to advise the Registered Name Holder at the time of registration that the Registered Name Holder is free to (1) designate the same person (such as the registrant themselves or its representative) as the technical contact; or (2) provide contact information which does not directly identify the technical contact person concerned.	Support recommendation as written	N/A	N/A	For natural persons, Organization field should be left blank by Registrant. For legal person (organization), it should be clearly mentioned/advised to Registrant by Registrar during time of Registration to avoid putting name of an individual (natural person) in Organization field e.g. name of an employee working in that organization.	Support recommendation as written	N/A	N/A	Until an official Accreditation and Access (i.e. Unified Access) model by ICANN is in place to facilitate legitimate and lawful access to gTLD registration data by third parties, there must be a provision for all internet users to contact domain name registrants, and anonymized email/web form seems to be the best way to do so.	Support recommendation as written	N/A	N/A	Although difficult to quantify, 1 year of data retention period seems to be a reasonable period that it neither too less nor too high.	We don’t support differentiating registrants on a geographic basis.	This requirement (differentiating registrants on a geographic basis) while costly from an implementation perspective by the contracted parties also implicitly assumes 100% WHOIS accuracy which is far from reality. However that having been said, there is no denying that “a one size fits all” kind of an approach prompted by and designed to comply with the GDPR might end up running foul with some of the national Privacy & Data Protection legislations of other jurisdictions.	See #85	GDPR clearly states that it is not applicable to Legal persons. So clearly ICANN and Contracted Parties should avoid violation of GDPR, and differentiate between natural and legal persons, as far as collection, storage and display of WHOIS data is concerned.	See #87	As per our answer in response to an earlier question we support that there needs to be further study. However, we also wish to emphaisize over here that there needs to be more done than merely study and there should in fact be a concerted effort on part of ICANN to get the contracted parties to agree to implement a solution that can be applied in such a way that it should be accurately possible to distinguish between registrants on a geographical basis.	NO	Support recommendation as written	N/A	N/A	The recommendation text seems fine. However, the availability of latest iteration of ICANN’s “Framework Elements for Unified Access Model for Continued Access to Full WHOIS Data” should be mentioned since a system for Standardized Access to NonPublic Registration Data is being referred. Further, incorporating the solutions and best practices as proposed in other community Accreditation and Access models (like IPC/BC, Philly Special and APWG WhASHmodels) should also be explored.	Support recommendation as written	N/A	N/A	N/A	N/A	No, I wish to continue to the next section
22	12/21/2018 9:22:26	Volker Greimann	Key-Systems GmbH	Yes	Key-Systems GmbH		Support Purpose as written			Purpose should be deleted		Lawful access for legitimate, GDPR -compliant third party interests has nothing to do with maintaining the SECURITY, STABILITY, AND RESILIENCY OF THE DOMAIN NAME SYSTEM. This is essentially an attempt to fit third party purposes into an alleged ICANN purpose which does not exist in this form. ICANNs interests and the interests of third parties should be kept separate.	Support Purpose intent with wording change	Change to: Enable Communications with and/or notification to the RNH, or their designated agent, for issues regarding a Registered Name	Recommendation is poorly written and contains excess wording to no benefit.	Support Purpose intent with wording change	Delete "OR OTHER UNAVAILABILITY OF A REGISTRAR OR REGISTRY OPERATOR"	Additional language is to broad and not necessary to frame the purpose.	Support Purpose intent with wording change	ENABLE ICANN CONTRACTUAL COMPLIANCE THROUGH ACCESS TO INDIVIDUAL DATA SETS IF REQUIRED FOR SPECIFIC INVESTIGATIONS INTO CONTRACTED PARTY COMPLIANCE REGARDING ALLEGED VIOLATIONS OF THEIR CONTRACTUAL OR POLICY OBLIGATIONS INVOLVING DOMAIN NAME REGISTRATIONS INVOLVING SAID DATA SETS	While there is purpose in ICANN being able to enforce compliance of its agreements with Contracted Parties, this purpose is contingent on the resolution of ICANN's status as a data controller or joint controller. Clearer definitions are needed re monitoring and auditing registration data before they can be included as components for this purpose. The use cases listed in the purpose are ill-defined and open to interpretation.	Support Purpose intent with wording change	see RrSG comment	Proposed recommendation is awkward and overly specific without gain.	Support Purpose intent with wording change	see RrSG comment	see RrSG comment	see RrSG comment	none		No, I wish to continue to the next section	Delete recommendation		see RrSG comment		Support recommendation as written				No, I wish to continue to the next section	No	Eliminate from 'Registrant Fields': Phone ext, Fax & Fax ext. Also eliminate: Tech ID, all Tech Fields (Name, Phone, Email).	see RrSG comment Also, in a majority of cases, the tech fields replicate the data used in the owner field. Therefore, publication of the very same data in this field would render the redaction in other fields moot.	see RrSG comment	see RrSG comment	Optional	see RrSG comment	No	If the collection is optional, the stated purpose for collection and retention becomes moot under the GDPR.	Yes	see RrSG comment		No	Only those elements where a valid purpose of Ry exists and a valid data controller-processor agreement is in place. For such transfers, Ry is sole controller, Rr is processor of transferred data.	Data transfers should only occur for valid purposes, not on general principle. Any transfer must meet the requirements for international transfer of personal data applicable to either party.		Intent and wording of this recommendation requires amendment	See RrSG comment	See RrSG comment		Delete recommendation	No	In the event ICANN require personal data, they must provide a legal justification and purpose, it must be proportionate and it will be done on a case by case basis.	While ICANN compliance may require to check with registries or registrars in respect of a compliance issue for a domain name, there is no clarity on why ICANN require the personal data of a Registered Name Holder.		Yes			Yes	ORGANIZATION: The publication of the ORGANIZATION field would be possible only if it did not contain personal data relating to private individuals. Regretfully, this is usually not the case as registrants have put that field to various non-intended uses, not the least of which is the repetition of the first and last name fields. Further, certain organizational structures of legal entities contain personal information in the name of the entity and while such data would not be protected under the GDPR as the entity name, the personal data contained therein would be protected. As the possibility of unintended publication of personal data could not be prevented in case of publication of the ORGANIZATION field, contracted parties need to be able to determine on their own whether they need to redact this field. Additionally, because there is 20+ years of legacy WHOIS data in circulation that was obtained (often in violation of WHOIS terms of use), resold, and archived, the registrant org field is being used as an “index” to match redacted records to unredacted archives, leading to the ability to indirectly identify data subjects, many of whom may be natural persons. We therefore propose that the redaction of this field be optio	CITY: Non-redaction of the city field in connection with other available data such as the domain name itself may allow the identification of the registrant, especially for smaller cities or towns with only a few hundred inhabitants. We therefore propose that as a default the CITY field remain redacted. EMAIL: We support the EPDP recommendation. TECH: As the main concern of the TECH fields is to provide the ability to contact a knowledgeable party, it should be sufficient to provide only the necessary contact details to enable such contact. For such purposes, the identity of these contacts is not required. Furthermore, in legacy registrations many registrants filled this contact with their own details. Therefore, removal of redaction would expose their personal information. We therefore propose that the name and phone number remain redacted and the email contact be handled in accordance with the EPDP team recommendation.	Delete recommendation			If the Final Report recommends that the Organization field not be redacted, then the language of Recommendation #9 should be replaced with the following: “The EPDP team recommends that registrars provide information to Registered Name Holders about how to complete the Organization field.”	Support intent of recommendation with edits		We support the intent of this recommendation but believe it should be up to the registrar to determine if this is an option they want to make available for domains under their management. Registrars may choose to allow for other methods of contactability not specified in the Temporary Specification and we believe it should be left up to each individual registrar on how they want to make that option available to registered name holders. Furthermore, we would encourage registrars to implement a web-based contact form as opposed to relay e-mail addresses as the latter have the potential to be compromised and lead to unforeseen issues down the road.		Support intent of recommendation with edits	see RrSG comment	see RrSG comment		See RrSG comment	See RrSG comment	See RrSG comment	See RrSG comment		No. Any study would not change the basis for the above rationale, so there would be no point on spending time and resources on it.	While several European ccTLD registries make such a distinction, introducing such efforts at this late stage for all gTLDs across the board would be unfeasible, presenting a significant technical and logistical burden which disproportionately affects smaller registrars. Additionally, the existence of such programs in other contexts does not alleviate the concerns raised in #84 above, which remain valid and pose significant risks.	Intent and wording of this recommendation requires amendment	Change to: “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, and only after resolution of the gating questions"	Each registry and registrar should be able to evaluate to whom they may disclose personal data. There are local laws to take into consideration, as well as any data privacy legislation. It would be impossible to have a blanket order to disclose personal data as it would depend on the requestor. Each registry and registrar has their own processes for such disclosure. Registrars will push back strongly on any attempt to contractually bind them to disclose data.		Support recommendation as written					No, I wish to continue to the next section
23	12/21/2018 10:29:14	Greg Mounier on behalf of Europol AGIS	Europol Advisory Group on Internet Security	Yes	I am submitting this on behalf of Europol's Advisory Group on Internet Security which consists of the leading cybersecurity companies and organizations in the world. The comments expressed here are those of the AGIS.	No, I would like to continue to the next section				Support Purpose as written		The AG IS expresses support in particular for Purposes 2, 3, and 4, which on their own and cumulatively empower the legitimate interests of the cybersecurity community in using Whois data for cybersecurity and overall data protection purposes. Moreover, it is critical to note that use of the DNS for cybercrime undermines trust in the system and the overall integrity of the DNS.	Support Purpose as written		The AG IS expresses support in particular for Purposes 2, 3, and 4, which on their own and cumulatively empower the legitimate interests of the cybersecurity community in using Whois data for cybersecurity and overall data protection purposes. Moreover, it is critical to note that use of the DNS for cybercrime undermines trust in the system and the overall integrity of the DNS.	Support Purpose as written		The AG IS expresses support in particular for Purposes 2, 3, and 4, which on their own and cumulatively empower the legitimate interests of the cybersecurity community in using Whois data for cybersecurity and overall data protection purposes. Moreover, it is critical to note that use of the DNS for cybercrime undermines trust in the system and the overall integrity of the DNS.											Cybersecurity and anti-fraud purposes, such as those noted in Recitals 47 and 49 of the GDPR.	As Whois serves as a public directory for the public databases central to the domain name system, there are many purposes for processing such data. The EPDP draft processing purposes articulate such purposes and their legal bases, including the GDPR’s Art. 6.1(f) lawful purpose for the legitimate interest of the data controller or a third party. A GDPR legitimate interest analysis requires an assessment as to whether an interest is legitimate to begin with, and, if so, whether such an interest is overridden by the interests or fundamental rights and freedoms of data subjects. The AG IS recommends that the EPDP holistically consider all of the important interests and rights at stake with regard to cybersecurity, the security and stability of the DNS, and overall data protection risks posed by maliciously registered or hijacked domain name registrations. The EPDP should consider and articulate a true assessment of interests in rights considering the victims of DNS abuse, the security and stability of the DNS, the many GDPR recitals articulating overriding interests, and the GDPR’s risk-based approach to appropriate safeguards for personal data. Whois data is used for cybersecurity purposes, and the processing of personal data for cybersecurity purposes is recognized in the GDPR. Moreover, it is critical to note that use of the DNS for cybercrime undermines trust in the system and the overall integrity of the DNS.	No, I wish to continue to the next section					Support intent of recommendation with edits		The AG IS expresses general support for Recommendation 3 but notes that existing Whois accuracy efforts, whether through policy or enforcement, do not appear to achieve an outcome consistent with the requirements of GDPR Art. 5.1(d). It is critical for the EPDP to take a holistic approach to data protection requirements, and ICANN’s mandate to ensure the overall security and stability of the DNS, while respecting the rights of data subjects to have accurate records of their personal data maintained.		No, I wish to continue to the next section	Yes																									No		Regarding the undecided redaction or non redaction of the Organization field The AG IS opposes the redaction of the Organization field, which is important for cybersecurity, and is a legal person under GDPR Recital 14A. Here, it is important for the EPDP to recognize that the Organization field is not private information and is in fact consistent with business record requirements from many EU member states as well as European Directive 2000/31/EC. Accordingly, in analyzing interests and rights, the Organization field should not be equated with other fields containing personal data under the GDPR. Regarding the redacted City field The AG IS opposes the redaction of the City field, which is not personal data, and which is a useful field for cybersecurity. Regarding the redacted Email field The AG IS opposes redaction of the Email field without a suitable replacement. Some European ccTLDs publish entire Whois records, including a registrant’s email address and other personal data, consistent with GDPR. Nonetheless, if the community chooses to redact this field as a matter of policy then it is important to ensure that another universal, cross-TLD identifier, whether generated through anonymization or tokenization, exist in its place. An email form is not suitable for cybersecurity purposes. Regarding the redacted “Tech Fields” The AG IS opposes the fragmentation of Tech Contact fields. Since the inception of Whois, the Tech Contact field has been a useful means for reaching those best able to resolve technical issues as well as for reaching victims for DNS abuse. Accordingly, this should continue to be available as an option for all registrants of gTLDs.	No	The AG IS opposes the redaction of the Organization field, which is important for cybersecurity, and is a legal person under GDPR Recital 14A. Here, it is important for the EPDP to recognize that the Organization field is not private information and is in fact consistent with business record requirements from many EU member states as well as European Directive 2000/31/EC. Accordingly, in analyzing interests and rights, the Organization field should not be equated with other fields containing personal data under the GDPR.		Intent and wording of this recommendation requires amendment		The AG IS opposes the redaction of the Organization field, which is important for cybersecurity, and is a legal person under GDPR Recital 14A. Here, it is important for the EPDP to recognize that the Organization field is not private information and is in fact consistent with business record requirements from many EU member states as well as European Directive 2000/31/EC. Accordingly, in analyzing interests and rights, the Organization field should not be equated with other fields containing personal data under the GDPR.		Intent and wording of this recommendation requires amendment		The AG IS opposes redaction of the Email field without a suitable replacement. Some European ccTLDs publish entire Whois records, including a registrant’s email address and other personal data, consistent with GDPR. Nonetheless, if the community chooses to redact this field as a matter of policy then it is important to ensure that another universal, cross-TLD identifier, whether generated through anonymization or tokenization, exist in its place. An email form is not suitable for cybersecurity purposes.		Intent and wording of this recommendation requires amendment		The AG IS believes that the EPDP proposed one year data retention period is insufficient for important cybersecurity purposes that, like other legitimate interests, must be considered beyond use for Transfer Dispute Resolution Policy purposes. Offenders, including those responsible for significant security threats, inadvertently reveal crucial identifiers, often at the beginning of their career but also over time. Likewise, changes in a Whois record over the course of years provides important insight into not only cybersecurity investigations but also prevention of future attacks through correlation analysis. Consequently, the analysis of historical Whois data is part and parcel of most cybersecurity investigations. Over the years, there have been many examples of botnets, DDoS attacks, malware hosting, SPAM, and phishing campaigns that have been successfully uncovered because of Whois record correlation with data points older than a year. For example, the perpetrator of a 2016 Mirai botnet offshoot attack on approximately a million Deutsche Telekom routers in Germany was discovered using historical Whois data that predated the attack by several years. Accordingly, it is important to not only retain the most recent registration record but also all registration history for a long period of time. Recent examples suggest at least six years is necessary.		The AG IS recommends the EPDP Team ensure that legal and natural persons are treated in a distinct manner to the extent that changes to personal data publishing and access are made. GDPR’s definitions along with Recital 14 makes clear that it does not apply to the processing of “personal data which concerns legal persons.”							Support intent of recommendation with edits		The AG IS supports the intent of the recommendation but notes that it is important to provide a means for multiple queries, particularly when pivoting off fields in an investigation, and reverse Whois, which is critical for cybersecurity investigations. Moreover, there should be a means for expedient access in certain circumstances, such as a global cybersecurity attack. To the extent queries are logged, there should be guidance for how this will work, what would be included in the logs, and permitted uses of the logs.							No, I wish to continue to the next section
24	12/21/2018 11:16:31	Neil Fried	Motion Picture Association of America	Yes	Submitting on behalf of the Motion Picture Association	No, I would like to continue to the next section	Support Purpose intent with wording change	AS SUBJECT TO REGISTRY AND REGISTRAR TERMS, CONDITIONS AND POLICIES, AND ICANN CONSENSUS POLICIES: (I) TO ESTABLISH THE RIGHTS [Insert: "AND OBLIGATIONS"] OF A REGISTERED NAME HOLDER IN A REGISTERED NAME; (II) TO ENSURE THAT A REGISTERED NAME HOLDER MAY EXERCISE ITS RIGHTS [Insert: "and fulfill its obligations"] IN THE USE AND DISPOSITION OF THE REGISTERED NAME; AND (III) TO ACTIVATE A REGISTERED NAME AND ALLOCATE IT TO THE REGISTERED NAME HOLDER	ICANN, registrars, registry operators, and registered domain name holders have long been subject to certain requirements regarding registration of a domain name. For example, the Registrar Accreditation Agreement requires that “[t]he Registered Name Holder shall represent that, to the best of the Registered Name Holder's knowledge and belief, neither the registration of the Registered Name nor the manner in which it is directly or indirectly used infringes the legal rights of any third party,” RAA, sec. 3.7.7.9, https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en#raa. Similarly, the Registry Agreement provides that the “Registry Operator will include a provision in its Registry-Registrar Agreement that requires Registrars to include in their Registration Agreements a provision prohibiting Registered Name Holders from distributing malware, abusively operating botnets, phishing, piracy, trademark or copyright infringement, fraudulent or deceptive practices, counterfeiting or otherwise engaging in activity contrary to applicable law, and providing (consistent with applicable law and any related procedures) consequences for such activities including suspension of the domain name,” Registry Agreement, Specification 11, sec. 3(a), https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-31jul17-en.html#specification11. Ensuring compliance with obligations such as these will require collection and processing of data as part of the WHOIS system, including providing access to third parties.	Support Purpose intent with wording change	[Strike: "MAINTAINING"] [Insert: "Ensuring"] THE SECURITY, STABILITY, AND RESILIENCY OF THE DOMAIN NAME SYSTEM IN ACCORDANCE WITH ICANN'S MISSION [Insert: "commitments, and core values"] THROUGH THE ENABLING OF LAWFUL ACCESS [Insert: "to data elements"] FOR LEGITIMATE THIRD-PARTY INTERESTS [Insert: "of law enforcement, cybersecurity, consumer protection, intellectual property rights protection, combatting domain name system abuse, and"] [Strike: "TO DATA ELEMENTS COLLECTED"] FOR THE OTHER PURPOSES IDENTIFIED HEREIN	For the sake of clarity and notice, this purpose should specifically identify as permissible the collection and processing of data for the long acknowledged legitimate interests of law enforcement, cybersecurity, consumer protection, and combatting intellectual property infringement and domain name abuse, including for investigations and enforcement actions related to those interests. Providing this added detail is consistent with Article 13(1) of the GDPR and the April 2018 letter from the Article 29 Data Protection Working Party to Göran Marby, both of which indicate that notice should be provided regarding the purposes for processing data. See GDPR, art. 13(1), https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679&from=EN; Letter from ARTICLE 29 Data Protection Working Party to Göran Marby, President and CEO, ICANN, April 11, 2018, https://www.icann.org/en/system/files/correspondence/jelinek-to-marby-11apr18-en.pdf.	Support Purpose intent with wording change	ENABLE COMMUNICATION WITH AND/OR NOTIFICATION TO THE REGISTERED NAME HOLDER AND/OR THEIR DELEGATED AGENTS OF TECHNICAL, [Insert: "legal,"] AND/OR ADMINISTRATIVE ISSUES WITH A REGISTERED NAME [Add: ", or for the other purposes identified herein."]	Communication with a registrant may be necessary to fulfill purposes identified herein that go beyond technical and administrative issues, and such communication will require the collection and processing of data as part of the WHOIS system, including sharing with third parties.				Support Purpose as written		ICANN, registry operators, registrars, and registered domain name holders are subject to a variety of contractual and other obligations. See, e.g., Registrar Accreditation Agreement, sec. 3.7.7.9 (requiring the registered name holder to refrain from using the domain name in a manner that infringes the legal rights of any third party), https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en#raa; Registry Agreement, Specification 11, sec. 3(a) (providing that the registry operator will require registrars to prohibit registered name holders from engaging in illicit activity, such as “distributing malware, abusively operating botnets, phishing, piracy, trademark or copyright infringement, fraudulent or deceptive practices, [and] counterfeiting), https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-31jul17-en.html#specification11. Ensuring compliance with obligations such as these will require the collection and processing of WHOIS data, including providing access to third parties.	Significant change required: changing intent and wording	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 [Insert: ", but including where such policies take into account use of the domain names" ), NAMELY, THE UDRP, URS, PDDRP, RRDRP, AND FUTURE DEVELOPED DOMAIN NAME REGISTRATIONRELATED DISPUTE PROCEDURES FOR WHICH IT IS ESTABLISHED THAT THE PROCESSING OF PERSONAL DATA IS NECESSARY.	Eligibility for grant or renewal of a domain name is subject to certain conditions on use. See, e.g., Registrar Accreditation Agreement, sec. 3.7.7.9 (requiring the registered name holder to refrain from using the domain name in a manner that infringes the legal rights of any third party), https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en#raa; Registry Agreement, Specification 11, sec. 3(a) (providing that the registry operator will require registrars to prohibit registered name holders from engaging in illicit activity, such as “distributing malware, abusively operating botnets, phishing, piracy, trademark or copyright infringement, fraudulent or deceptive practices, [and] counterfeiting), https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-31jul17-en.html#specification11. Section 1.1 of the ICANN bylaws provides that ICANN’s mission includes coordinating the development and implementation of policies with respect to gTLD registrars and registries in the areas described by annexes G-1 and G-2. See ICANN Bylaws, Sec. 1.1(i)(a), https://www.icann.org/resources/pages/governance/bylaws-en/. Annex G-1, in turn, states that “[t]he topics, issues, policies, procedures and principles referenced in Section 1.1(a)(i) with respect to gTLD registrars” include “resolution of disputes regarding the registration of domain names (as opposed to the use of such domain names, but including where such policies take into account use of the domain names).” Id., Annex G-1. Purpose #6 should thus reflect the fact that misuse of a domain name is relevant to domain name eligibility, and that collection and processing of data as part of the WHOIS system, including sharing with third parties, is necessary to coordinate, operationalize, and facilitate policies on such eligibility and resolution of disputes.	Support Purpose as written		Eligibility for a domain name can turn on policies regarding misuse of domain names. See, e.g., Registrar Accreditation Agreement, sec. 3.7.7.9 (requiring the registered name holder to refrain from using the domain name in a manner that infringes the legal rights of any third party), https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en#raa; Registry Agreement, Specification 11, sec. 3(a) (providing that the registry operator will require registrars to prohibit registered name holders from engaging in illicit activity, such as “distributing malware, abusively operating botnets, phishing, piracy, trademark or copyright infringement, fraudulent or deceptive practices, [and] counterfeiting), https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-31jul17-en.html#specification11. The collection and processing of data as part of the WHOIS system, including access by third parties, is necessary to determine whether such misuse has occurred.		Additional Purpose 1: Promoting the transparency, accountability, and trust necessary to ensure a safe, secure, and supportive environment online for communication, commerce, innovation, and creativity—such as by combating illicit online conduct and ensuring public safety, consumer protection, law enforcement, dispute resolution, protection of intellectual property, prevention of domain name abuse, and enforcement of rights—as well as to provide access to third-parties and law enforcement authorities for such purposes. Additional Purpose 2: To facilitate analysis regarding misuse of domain names in deciding whether to create additional gTLDs, as well as to create or amend policies regarding the misuse of gTLDs.	Rationale for Additional Purpose 1: Since before the dawn of the commercial internet, access to WHOIS data has been a cornerstone of the transparency, accountability, and trust necessary to ensure a safe, secure, and supportive online environment for communication, commerce, innovation, and creativity. As ICANN itself notes, the Internet Engineering Task Force began publishing a protocol for a directory service in 1982 that listed the contact information of anyone transmitting data across the ARPANET. See History of WHOIS, ICANN WHOIS, https://whois.icann.org/en/history-whois (last visited Dec. 11, 2018). “As the Internet grew,” that system “began to serve the needs of different stakeholders such as domain name registrants, law enforcement agents, intellectual property and trademark owners, businesses and individual users.” Id. Access to WHOIS information is critical to creating the transparency, accountability, and trust that is fundamental to the multistakeholder model of internet governance, and that all internet users need to be comfortable interacting online. Without reliable and timely access to WHOIS data, individuals and businesses will have difficulty determining—when necessary—whom they are engaging with online, whether to verify the identity of the entity; to find a contact for purposes of conveying information, preferences, questions, and concerns; or to seek redress for mistakes and harms. Moreover, law enforcement and other entities will have a harder time investigating, preventing, and mitigating illicit behavior online. Promoting a safe and secure online environment—as well as the collection, processing, and sharing of registration data to accomplish that purpose—is perfectly consistent with the European Union’s General Data Protection Regulation. WHOIS data had been publicly available prior to the May 2018 adoption of the Temporary Specification, and domain name registrants have long been on notice that they must provide certain information that will be publicly disclosed, including for matters of public safety, consumer protection, law enforcement, dispute resolution, protection of intellectual property, and enforcement of rights—reducing expectations of privacy. Moreover, the GDPR acknowledges that a variety of interests can warrant collection and disclosure, such as public safety, law enforcement and investigation, enforcement of rights or a contract, fulfillment of a legal obligation, cybersecurity, and preventing fraud. See GDPR, arts. 2(2)(d), 5(1)(b), 6, 23, https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679&from=EN. See also ICANN, GOVERNMENTAL ADVISORY COMMITTEE, Communiqué—San Juan, Puerto Rico (Mar. 15, 2018) (stating that the GDPR allows for access to data for legitimate purposes), https://gac.icann.org/advice/communiques/20180315_icann61%20gac%20communique_finall.pdf. Promoting a safe and secure online environment is also consistent with ICANN’s Bylaws. Section 1.1, for example, provides that ICANN’s mission includes coordinating the development and implementation of policies with respect to gTLD registrars and registries in the areas described by annexes G-1 and G-2. See ICANN Bylaws, Sec. 1.1(i)(a), https://www.icann.org/resources/pages/governance/bylaws-en/. Annexes G-1 and G2, in turn, include “issues for which uniform or coordinated resolution is reasonably necessary to facilitate interoperability, security and/or stability of the Internet”; “resolution of disputes regarding the registration of domain names (as opposed to the use of such domain names, but including where such policies take into account use of the domain names)”; and “reservation of registered names in a TLD … that may not be renewed due to reasons reasonably related to … intellectual property.” Similarly, Section 4.6(e)(ii) provides that ICANN will periodically “assess the effectiveness of the then current gTLD registry directory service and whether its implementation meets the legitimate needs of law enforcement, promoting consumer trust and safeguarding registrant data” (emphasis added). Thus, it is in ICANN’s remit to ensure WHOIS data remains accessible to promote the safety and the security of the internet itself, not just the safety and security of the domain name system, as well as to protect intellectual property. To be clear, these purposes have nothing to do with curbing or discriminating against particular internet expression, but rather are content neutral purposes related to combatting illegal conduct, including unauthorized dissemination of copyrighted material. Detailing these purposes is consistent with Article 13(1) of the GDPR and the April 2018 letter from the Article 29 Data Protection Working Party to Göran Marby, both of which indicate that notice should be provided regarding the purposes for processing data. See GDPR, art. 13(1), https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679&from=EN; Letter from ARTICLE 29 Data Protection Working Party to Göran Marby, President and CEO, ICANN, April 11, 2018, https://www.icann.org/en/system/files/correspondence/jelinek-to-marby-11apr18-en.pdf. Rationale for Additional Purpose 2: ICANN’s mission includes adopting policies regarding the creation of additional gTLDs. Misuse of gTLDs’s is relevant in determining whether to create such additional gTLDs, and whether to expand existing policies or create new ones regarding misuse. Analysis of misuse will require collection and processing of data as part of the WHOIS system, including sharing with third parties.	No, I wish to continue to the next section	Support intent of recommendation with edits	Per the EPDP Team Charter, the EPDP Team is committed to [Strike: "considering"] [Insert: "developing"] a system for Standardized Access to non-public Registration Data once the gating questions in the charter have been answered [Insert: ", such as the proposal from ICANN for a unified access model, or through other means that ICANN has suggested exploring, including ICANN assuming legal responsibility for providing access as a sole controller. See Göran Marby, ICANN President and CEO, ICANN GDPR and Data Protection/Privacy Update, ICANN (Sept. 24, 2018), https://www.icann.org/news/blog/icann-gdpr-and-data-protection-privacy-update."] • 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, [Insert: "this will include"] disclosure [Insert: "to law enforcement authorities and third parties"] in the course of intellectual property infringement and DNS abuse cases [Strike: "will be considered"].	The two instances of the word “considering” suggests the ePDP might conclude that no such standardized model should be created, and that disclosure is not necessary in intellectual property infringement cases. Failure to adopt a standardized model is contrary to the ePDP Charter, which states that work on a standardized model “shall begin once the gating questions above have been answered and finalized in preparation for the Temporary Specification initial report.” ePDP Charter at 7, https://gnso.icann.org/sites/default/files/file/field-file-attach/temp-spec-gtld-rd-epdp-19jul18-en.pdf. Similarly, failure to disclose to law enforcement authorities and third parties in intellectual property infringement cases would be contrary to the longstanding purpose of the WHOIS system to thwart such infringement. As ICANN itself notes, the Internet Engineering Task Force began publishing a protocol for a directory service in 1982 that listed the contact information of anyone transmitting data across the ARPANET. See History of WHOIS, ICANN WHOIS, https://whois.icann.org/en/history-whois (last visited Dec. 11, 2018). “As the Internet grew,” that system “began to serve the needs of different stakeholders such as domain name registrants, law enforcement agents, intellectual property and trademark owners, businesses and individual users.” Id.		Intent and wording of this recommendation requires amendment	[Replace all with: "Current ICANN contracts and consensus policies may need to be revised—and registration data may need to be collected, processed and shared with third parties—to ensure the accuracy of registration data."]	The WHOIS system can only be as successful in meeting its purposes as it is accurate. Entities providing data, as well as entities relying on such data for legitimate purposes, have legitimate expectations that such data will be kept up to date and accurate. In addition, the GDPR creates obligations to ensure data that is collected, processed, and shared is accurate. See GDPR art. 5(1)(d), https://eur-lex.europa.eu/legal-content/EN/TXT/?qid=1528874672298&uri=CELEX%3A32016R0679. For both reasons, and in light of the fact that substantial data inaccuracies continue to persist within the WHOIS system, it stands to reason that current policies may be insufficient and require revision, and that data may need to be shared with third parties for purposes of verification, updating, and correction.		No, I wish to continue to the next section	Yes																				Support recommendation as written	Yes			ICANN, registrars, registry operators, and registered domain name holders have long been subject to certain requirements. See, e.g., Registrar Accreditation Agreement, sec. 3.7.7.9 (requiring the registered name holder to refrain from using the domain name in a manner that infringes the legal rights of any third party), https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en#raa; Registry Agreement, Specification 11, sec. 3(a) (providing that the registry operator will require registrars to prohibit registered name holders from engaging in illicit activity, such as “distributing malware, abusively operating botnets, phishing, piracy, trademark or copyright infringement, fraudulent or deceptive practices, [and] counterfeiting), https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-31jul17-en.html#specification11. Ensuring compliance with those obligations will require collection and processing of data as part of the WHOIS system, including providing access to third parties.	No	City and email should not be redacted.	City of residence is not sensitive personal information. Email addresses are critical data points for combatting illicit activity and DNS abuse—including intellectual property infringement—as well as for purposes of consumer protection and public safety. Combatting the harm to consumers and businesses posed by illicit use of domain names outweighs the slight privacy interest in an email address of a domain name holder, especially since the domain name holder is willingly engaging in public-facing activity and such data about registered domain name holders has historically been publicly available, reducing expectations of privacy. Significantly, a registrant can easily select an email address that does not disclose sensitive information, if he or she chooses. For purposes of notice, registrars should inform registrants that their email address will not be redacted.	No	The GDPR applies only to information about “natural persons.” See GDPR, art. 1 (describing the subject matter and objectives of the regulation as relating to the protection of natural persons), https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679&from=EN. The GDPR thus imposes no obligation to obfuscate information about businesses or other legal entities. Because access to such information is necessary to promote the transparency, accountability, and trust that is critical to encourage commerce, communications, and creativity online, as well as for purposes of consumer protection, law enforcement, and enforcement of intellectual property and other rights, such information should remain available. This is also consistent with ICANN President and CEO Göran Marby’s comments making “it a high priority to find a path forward to ensure compliance with the GDPR while maintaining WHOIS to the greatest extent possible.” Data Protection and Privacy Update—Plans for the New Year, ICANN Blog (Dec. 21, 2017), https://www.icann.org/news/blog/data-protection-and-privacy-update-plans-for-the-new-year.														The EPDP team should recognize: 1) that the GDPR has no legal force outside the EU’s jurisdiction, and so does not bind parties or services that do not have a significant EU nexus. 2) that ICANN President and CEO Göran Marby has made “it a high priority to find a path forward to ensure compliance with the GDPR while maintaining WHOIS to the greatest extent possible.” Data Protection and Privacy Update—Plans for the New Year, ICANN Blog (Dec. 21, 2017), https://www.icann.org/news/blog/data-protection-and-privacy-update-plans-for-the-new-year. 3) that an ICANN policy that globalizes EU privacy law in such a way will put strains on the credibility and legitimacy of the multistakeholder governance model and independence of ICANN, increase the odds that nations enact WHOIS or ICANN-specific laws, and lead to fragmentation that creates added complexity in developing and enforcing ICANN policy as well as jeopardizes the security, stability, and resiliency of the DNS system. 4) that geographic differentiation is possible, as evidenced by the policies of certain country code TLDs and geography-specific gTLDs requiring a geographic nexus to be eligible to register for a domain name. Taken together, these points suggest that contracted parties should be required to differentiate between registrants on a geographic basis and that no redaction of data should occur regarding the collection, processing and sharing of data outside the E.U. in the provision of non-E.U. services.	It would be inappropriate for an ICANN policy decision to give the GDPR effect beyond the EU’s jurisdiction. Such an ICANN policy decision would impinge on the policy prerogatives of other nations and the welfare of their citizens by unnecessarily and inappropriately extending EU privacy policy in a way that limits access to WHOIS data, which serves important law enforcement, consumer protection, public safety, cybersecurity, and intellectual property purposes that ICANN has itself recognized. It is one thing for ICANN policy to require contracted parties to abide by local laws that apply to them; it is another to require the contracted parties to abide by laws that would not otherwise apply, either geographically or in substance, and to do so in a way that contradicts longstanding WHOIS policies regarding the availability of data. In addition, requiring differentiation will lead to more consistent application than a permissive policy, which would likely result in a hodgepodge of different decisions by contracted parties. While prohibiting differentiation would result in a consistent approach, that approach would go beyond the requirements of the GDPR and contradict Göran Marby’s statements regarding preserving WHOIS access to the greatest extent possible.		The EPDP team should recognize: 1) that the GDPR applies only to natural persons, see GDPR, art. 1, https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679&from=EN), and so does not require redaction of any data regarding businesses or other legal persons. 2) that ICANN President and CEO Göran Marby has made “it a high priority to find a path forward to ensure compliance with the GDPR while maintaining WHOIS to the greatest extent possible.” Data Protection and Privacy Update—Plans for the New Year, ICANN Blog (Dec. 21, 2017), https://www.icann.org/news/blog/data-protection-and-privacy-update-plans-for-the-new-year. 3) that an ICANN policy that overbroadly applies the GDPR will put strains on the legitimacy of the multistakeholder governance model, increase the odds that nations enact WHOIS or ICANN-specific laws, and lead to fragmentation that creates added complexity in developing and enforcing ICANN policy as well as jeopardizes the security, stability, and resiliency of the DNS system. 4) that differentiation between natural and legal persons is possible, as evidenced by the practices of certain country code TLDs and gTLDs to do precisely that. Taken together, these points suggest that contracted parties should be required to differentiate between natural and legal persons and that no redaction of data should occur regarding the collection, processing, or sharing of data related to legal persons.	It would be inappropriate for an ICANN policy to apply GDPR beyond its scope. Such a decision would unnecessarily and inappropriately limit access to WHOIS data, which serves important law enforcement, consumer protection, public safety, cybersecurity, and intellectual property purposes that ICANN has itself recognized. In addition, requiring differentiation will lead to more consistent application than a permissive policy, which would likely result in a hodgepodge of different decisions by contracted parties. While prohibiting differentiation would result in a consistent approach, that approach would go beyond the requirements of the GDPR and contradict Göran Marby’s statements regarding preserving WHOIS access to the greatest extent possible.			Support intent of recommendation with edits	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 [Insert: "and incorporated in the team's final report"] , 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].	The Temporary Specification was meant to be just that: temporary. Absent a completed recommendation in the final report specifically delineating how contracted parties will provide access to redacted data to parties with a legitimate interest, as well as a deadline for creating that system, the EPDP runs the risk of unreasonably prolonging the Temp Spec. The result would be merely a redaction policy, rather than the standardized access model to non-public registration data that the EPDP is tasked with formulating. Nonetheless, if the May 25th deadline for expiration of the Temp Spec arrives without a completed formulation of a standardized access, the Temp Spec should be extended. To do otherwise might suggest that contracted parties are no longer under any obligations, resulting in a hodgepodge of access policies. This would harm the longstanding, legitimate purposes of the WHOIS system; contradict Goran Marby's commitment to preserve the availability of data under the WHOIS system to the greatest extent possible; put strains on the credibility and legitimacy of the multistakeholder governance model; increase the odds that nations enact WHOIS or ICANN-specific laws; and lead to fragmentation that creates added complexity in developing and enforcing ICANN policy as well as jeopardizes the security, stability, and resiliency of the DNS system.							Yes
25	12/21/2018 11:23:03	Monique A. Goeschl	Verein für Anti-Piraterie der Film- und Videobranche (VAP)	No		No, I would like to continue to the next section				Support Purpose as written															Significant change required: changing intent and wording	omit "OPTIONAL" and "VOLUNTARILY"	Without mandatory compliance with and commitment to agreed standards of good faith operation, non-compliant actors will continue to abuse the registration system and registry operators will have no legal basis to adhere to or be accountable to.				No, I wish to continue to the next section	Support intent of recommendation with edits	Intellectual property infringement and DNS abuse cases will be recognized as legitimate purposes for disclosure.	A right holder must be able to contact the registrant of a domain in order to send a notification of infringement and the registrar/registry must facilitate this basic level of communication. This is especially the case where domain operators mask their registration information. As a representative of right holders whose rights are systematically infringed on a commercial scale, VAP's right of information is regularly ignored or rejected with the argument that the infrastructure provider is not liable for content of a domain. Thereby registrars/registries ignore their own terms and conditions which purportedly prohibit the use of domains for illegitimate purposes.		Delete recommendation		Accuracy is an integral element to a sustainable domain name system. In our experience, registration information of domains established for illegitimate purposes regularly contain fake names and addresses. In fact, if there is a legitimate complaint regarding inaccurate registration data, there should be an independent verification procedure.		No, I wish to continue to the next section																																				Support intent of recommendation with edits	...but for private persons must not identify...	GDPR is for the protection of data privacy of individuals, not commercial operations. Where a domain is obviously being used for commercial purposes, there should be full transparency on contact email address. Key quantitative and qualitative indicators can be identified and agreed upon to establish baseline criteria for classification of commercial purpose.						Registrants of commercial operations should be considered legal persons.	Good governance/due diligence	It is not always possible to identify the geographic location of the registrant, for example if anonymization or proxy services are implemented.	Suggest referring to legislation on unfair commercial practices		Not until there is a decision on which address qualifies as the domicile/jurisdiction of the registrant (see also anonymized/proxy registration)		Intent and wording of this recommendation requires amendment	See provisions of the EU Regulation for platform-to-business trade promoting fairness and transparency for business users of online intermediation services. https://ec.europa.eu/digital-single-market/en/platforms-to-business-trading-practices	Internet infrastructure providers have a gateway function - there is an imbalance of informational power that must be rectified by transparency and due diligence by the providers. From the viewpoint of a third party with legitimate requests, there should also be the possibility to object to decisions by infrastructure providers not to provide requested information. These decisions are often haphazard and inconsistent with transparency recommendations.							No, I wish to continue to the next section
26	12/21/2018 11:30:45	Tucows Domains Inc.	RrSG	No		No, I would like to continue to the next section	Support Purpose as written			Support Purpose intent with wording change	MAINTAINING THE SECURITY, STABILITY, AND RESILIENCY OF THE DOMAIN NAME SYSTEM IN ACCORDANCE WITH ICANN'S MISSION.	While the enabling of lawful access for legitimate third-party interests to data already collected may be a valid legal basis for processing data, it is not part of ICANN’s existing mandate, and the EPDP team should be careful not to overstep the project goals by expanding ICANN’s mission.	Support Purpose intent with wording change	Enable communication with and/or notification to the Registered Name Holder and/or their delegated agents of technical and/or administrative issues (if applicable) with a Registered Name;	Including “and/or” with regard to the TECH and ADMIN contacts implies that there must always be these alternate contacts in addition to the RNH; as these should be optional, if they are used at all, we recommend the text provided above (adding “if applicable”.)	Support Purpose as written		This purpose must be limited to data security and recovery mechanisms and not to additional data sharing, which is suggested in the purpose rationale.	Support Purpose as written			Support Purpose intent with wording change	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, AND RRDRP FOR WHICH IT IS ESTABLISHED THAT THE PROCESSING OF PERSONAL DATA IS NECESSARY	Undefined potential future processes should not be included in policy	Support Purpose as written						No, I wish to continue to the next section	Support intent of recommendation with edits	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 legal and DNS abuse cases will be considered.	We support disclosure of Registration Data in the course of investigation of DNS and legal abuse. We do not find it necessary to call out specific types of legal abuse. Accordingly, we propose the edited version provided above.	We have proposed this modification as we support the exploration of a Standardized Access model that complies with legal and regulatory obligations, but it should be noted such a model ought not be construed to be policy as it has not completed a true PDP nor was it contemplated to be a policy when it was entered into the EPDP charter. We further note that a “system” for Standardized Access need not be a technical system but could also be a procedure. Finally, data that is distributed must be limited data that there was a legal basis to collect and that the distribution is not, itself, a legal basis.	Support intent of recommendation with edits	The EPDP Team recommends that the following requirements related to the accuracy of registration data under the current ICANN contracts and consensus policies shall not be affected by this policy: RAA Section 3.7.7.2, Whois Accuracy Program Specification, Whois Data Reminder Policy, Restored Names Accuracy Policy	Specificity is important, so that there is no confusion around what ICANN requirements could be considered to be part of the requirement for accuracy.		No, I wish to continue to the next section	No	Collection of the following data elements is not necessary to achieve the Purposes identified above: Registrant Street Registrant City Registrant State/Province Registrant Postal Code Registrant phone / phone ext Registrant fax / fax ext Tech Name Tech Phone Tech Email	We do not agree that the registrant or technical contact data indicated here is necessary for registrars to collect under GDPR lawful basis 6 (1) (b); a domain name can be allocated to a registrant with only a subset of the current registrant data set (see response to #42 above). We do not agree that the registrant or technical contact data indicated here should be collected under GDPR lawful basis 6 (1) (f); compliance with ICANN contracts can be achieved and demonstrated with a minimized data set (as indicated in #42 above). We do not agree that a Technical contact is necessary at all, and so it should not be required under any legal basis. We also note that Nameservers are marked as mandatory data; not every TLD requires Nameservers to be designated on a registered name, and so those data elements should be marked as optional.			Optional	Technical contact data is not necessary to complete the registration, and thus it should be optional. When we say “optional” we mean both that it be optional for the registrar or reseller to present as an option to the registrant and it should be optional for the registrant to complete.	No	Technical contact data is not necessary to complete the registration, so registrars should not be required to offer these contact fields. GDPR requires minimization of data processing.	Yes	If these contact points match the registrant contact set, they are redundant and thus there’s no legal basis for collecting them. If these contact points are different, the registrar has no legal or contractual relationship with the registrant and thus there is again no legal basis for collecting, storing, or processing these data.		No	None of the data elements which the registrar is required to collect should be transferred to the registry operator, with the exception of any elements required to fulfill the registry’s validation requirements.	There’s no reason to transfer registration contact data to the registry, since the registrar holds the data and can identify who the RNH is. The additional optional elements may be transferred in order to fulfill the registry’s validation requirements in certain cases but need not be required per ICANN policy.		Support intent of recommendation with edits	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 transferred by Registries and Registrars to data escrow providers should include the minimal data set, and not the data elements we indicated should be redacted in question 42 above.		ICANN may require that Contracted Parties backup their data in a particular manner so that the databases can be reconstructed in the event of a business or technical failure. We note that the data processed for this purpose must be minimized and appropriate parties must have agreements in place with escrow providers in order to protect that data. Registrars should not be required to collect data specifically for the purpose of backing it up with a data escrow provider, but if the data is already collected it can be required to include it in the backup. It is important to note that ICANN (including, but not limited to, ICANN Org and ICANN Contractual Compliance) should not have access to the DEA deposits. ICANN may require backups to the DEA, but there is no legal basis for ICANN to access this information; in the event of a business or technical failure that requires that the database be reconstructed, the access should be given to the newly-assigned provider, not to ICANN. This would allow the new registrar to enter into and fulfil their contract with the registrant, while there remains no legal justification for the transfer of RNH data to other parties not included in the contract with the RNH (for example, ICANN).	Support intent of recommendation with edits	No	Transfer of the following data elements is not necessary to achieve the Purposes identified above: Registrant Street Registrant City Registrant State/Province Registrant Postal Code Registrant phone / phone ext Registrant fax / fax ext Tech Name Tech Phone Tech Email In addition, the remaining data elements (Registrant Name, Registrant Organization, Registrant Email, Registrant Country) should only be transferred to ICANN after ICANN has demonstrated a specific legitimate purpose to access those particular data elements.	The data elements listed above are not necessary for ICANN Contractual Compliance to complete “monitoring requests, audits, and complaints submitted by registry operators, registrars, registered name holders, and other internet users” in the bulk of such situations. No data should be automatically transferred, either by or to ICANN but should only be transferred upon a showing of legitimate interest on a case-by-case basis. Our experience has been that ICANN Contractual Compliance does not ever require the above-listed data elements. We also note that, as to the remaining data elements, which are occasionally called for, they should never be presumptively required but each data element should be justified by ICANN Contractual Compliance if and when they believe the data element to be necessary for a specific matter on a case-by-case basis. Registrars should not be penalized by ICANN Contractual Compliance in the instance that they disagree with ICANN Contractual Compliance determination regarding legitimate interest as Registrars have been placed in the position of being the stewards of their registrants’ personal data. Finally, the data elements listed above are not only not necessary for ICANN Contractual Compliance, they are not necessary for ICANN’s purposes at all and should not be required to be collected by Registrars.	If ICANN provides a Data Processing Agreement or some appropriate assurances re how they handle, store, process, and delete data, and the data are truly a minimal set, ICANN might be able to request certain minimal data elements which are needed for the purposes listed (see pg 115 of current clean copy). At this time, however we have no assurance that ICANN will require a truly minimal set; hopefully this will be determined within the UAM work.	Yes	This question is badly designed. We select “yes” because we think these data must be redacted but, in addition, that MORE data elements should be redacted beyond what are listed here: Organization, State, and Country should also be redacted; there are NO data elements that need to be publicly displayed.	The data can be provided to those third parties with a legitimate legal basis to access it without publicly displaying these fields.	Yes	In a sampling of the Organization field for registrations sponsored by our family of registrars, we found that the Organization field is most likely to match the registrant name or be completed with placeholder data (such as “NONE” or “—”). We did not find substantial indication that it was useful to determine the status of the registrant as either a natural or legal person. As such, using its to existence attempt to determine the status of the registrant is inappropriate and displaying the data it may contain risks revealing personal data. It should be redacted by default.		Delete recommendation	Should be deleted entirely	The Organization field should be redacted, so there’s no need for further guidance to registrants as to what they should know when populating that field.		Intent and wording of this recommendation requires amendment	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 should be modified such that the registrar MAY provide an email address or web form to facilitate communication with the relevant contact but, if the Registrar provides such, it MUST NOT identify the contact email address or the contact itself without the data subject’s explicit prior consent to such publication.	It exceeds ICANN’s purview to require that registrars operate an email service, be it forwarding or a web form that transmits to the RNH via email. The Security, Stability, and Resilience of the Domain Name System can be maintained without giving all Internet users the ability to contact all gTLD domain owners. This functionality should be optional for registrars to provide, if not entirely removed from ICANN’s contractual requirements.		Support intent of recommendation with edits	The EPDP Team recommends that Registrars are required to retain the mandatory data elements for a period of one year following the life of the registration. ICANN must also commit to deleting this personal data after a period of one year following receipt of such data. Any “optional” data elements (such as the Technical contact may become) should be retained only while in use, and should be deleted once the data subject opts out of using that optional data. This retention period conforms to the specific statute of limitations within the Transfer Dispute Resolution Policy (“TDRP”).	This data retention duration should apply to ICANN, the Registrar, and the Registry (if applicable). There is no need for ICANN to retain the herein specified mandatory data elements for longer than one year. Optional data should only be kept while the legal basis for processing remains active; if this legal basis is the data subject’s consent to allow optional data use, then once that consent is revoked the data must no longer be retained.		Tucows strongly supports the position taken by the Contracted Parties and NCSG on these questions. They have done a thorough and admirable job of identifying the risks and drawbacks of differentiating on geographic or person-type basis.	Privacy is a right that ought not inure solely to European citizens. In addition, the Internet being the global system that it is, there is no simple way to appropriately determine who is and who is not protected by the GDPR or other relevant data processing laws. For entities operating in or transferring data through the EU, these rights must be extended to all personal data that is transmitted.	The Internet global system, and as such, there is no way of appropriately determining who is and is not a European citizen or otherwise protected by the GDPR. IP addresses can be spoofed, geolocation is only accurate to a point, and people move freely about the globe. It is not possible for a registrar to know the person type or location of a registered name holder with sufficient certainty to protect those whose data must be protected. In addition, the risk of releasing data is high: both to the natural person whose personal data was compromised and made public and to the company that released it. The monetary penalties to the company, however, pale in comparison to the compromised privacy of the natural person. Finally, there are many and varied similar laws, including in Argentina and the United States. Developing systems that respect personal privacy rather than adhere to a Eurocentric worldview is simply good sense.	It is simply not possible for a registrar to know whether a registrant is a natural person or a legal person with sufficient certainty to protect those whose data must be protected. Tucows conducted a sampling of domains registered to our family of registrars and noted that the majority of the data in the “org” field was the same as what appeared in “Registrant Name” or was a placeholder. We strongly caution against using this field as indicative of anything. In addition, the risk of releasing data is high: both to the natural person whose personal data was compromised and made public and to the company that released it. The monetary penalties to the company, however, pale in comparison to the compromised privacy of the natural person. Finally, there are many and varied similar laws, including in Argentina and the United States. Developing systems that respect personal privacy rather than adhere to a Eurocentric worldview is simply good sense.		Tucows believes that privacy is a right that ought not inure solely to European citizens. As there are many current laws that also protect the privacy of the individual—and others being debated—we do not see value in conducting such a study.	CIRA, the .ca registry, differentiates between “Individual” and “Non-Individual” domain registrant types; this is done by requiring each registrant to self-select from a set of possible options (https://cira.ca/canadian-presence-requirements-registrants). CIRA provides a Privacy service Domains owned by Individuals while publishing the contact info for domains owned by non-Individuals. This method does not scale for global use. It is a fairly common occurrence for a registrant to select incorrectly, and be surprised to find that their personal contact information has been published by the registry Whois page and made fully available on the Internet. If the person type is optionally self-reported it will be inconsistently used and unreliable, while if it is made mandatory in order for the registrar to validate the registrant’s status then it violates the GDPR’s principle of data minimization, since our industry history shows that domains can be registered without collection of this personal data.	Support intent of recommendation with edits	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 and consensus has been achieved; this can only occur after resolution of the gating questions.	We support the Recommendation as written but note that determination of legitimate purpose must be conducted on a per-request basis. It is simply not the case that a party’s status is sufficient to be provided with full access to all personal data. Each request for access must include justification and be reviewed individually, understanding the balance between the right of the requestor for access to personal data where appropriate and the natural person’s right to privacy. This is a balancing test and will, necessarily, be different in each case.	Each registry and registrar should be able to evaluate to whom they may disclose personal data. It would be impossible to have a blanket order to disclose personal data as the legitimacy of such disclosure is not merely dependent upon the identity of the requestor but must include balancing other factors such as the requestor, the jurisdiction of the data subject, and the legal basis. Tucows will push back strongly on any attempt to contractually bind them to disclose data without such a balancing test.	Support recommendation as written			ICANN is either a controller, dictating which data contracted parties must collect (as evidenced by the tone of this questionnaire), or a joint controller. In either case, an agreement is required by law.		No, I wish to continue to the next section
27	12/21/2018 11:37:48	Brian Beckham	Head, Internet Dispute Resolution Section	Yes	World Intellectual Property Organization Arbitration and Mediation Center	No, I would like to continue to the next section																Support Purpose intent with wording change	“but including where such policies take into account use of the domain names"	We suggest adding the above text to mirror the ICANN Bylaws.								Intent and wording of this recommendation requires amendment		With six months of GDPR experience behind us, it is obvious that ICANN needs to turn its concerted attention to addressing the need for a unified/standardized system for reasonable access to non-public registrant data. Failure to provide a solution is harming a range of legitimate causes. As stated by the Interpol representative at the ICANN Meeting in Barcelona, “investigations are affected by [and] have been slowed down or have been challenged by WHOIS.”	Decisive action in developing a unified/standardized access model would foster predictability, in all stakeholders’ interests, and to this end WIPO remains willing to assist in a potential accreditation body capacity. Even if this reflects the EPDP Charter, we find Recommendation No. 2 troubling in that it suggests the EPDP will “turn its attention to considering a system for Standardized Access to non-public Registration Data once the gating questions in the charter have been answered”. Not only does this fail to commit to actually coming up with a solution, it proposes to only begin “considering” one once the “gating questions” have been answered. We see no compelling reason why work on a unified/standardized system for reasonable access to non-public registrant data cannot commence immediately in parallel with the EPDP effort.					No, I wish to continue to the next section							To the extent any of the currently-collected data elements (i.e., admin and tech contacts) would no longer be collected, and pending any relevant rule change, ICANN should advise UDRP providers that due process obligations will be deemed to be met for purposes of UDRP case administration as long as a provider uses all available information to notify cases.				To the extent any of the currently-collected data elements (i.e., admin and tech contacts) would no longer be collected, and pending any relevant rule change, ICANN should advise UDRP providers that due process obligations will be deemed to be met for purposes of UDRP case administration as long as a provider uses all available information to notify cases.																													Intent and wording of this recommendation requires amendment			Further to our observations on ICANN’s request for feedback on Proposed Interim Models for Compliance with ICANN Agreements and Policies in Relation to the GDPR, a one-year data retention practice would risk harming legitimate investigations. ICANN may recall that other industries’ (e.g., accounting and legal) data retention best practices generally point to seven years as a guide. (See e.g., www.sec.gov/rules/final/33-8180.htm, and www.vantageinsurance.co.uk/assets/files/atrisk/September%202011.pdf.)																	No, I wish to continue to the next section
28	12/21/2018 12:00:36	Lars Steffen	eco – Association of the Internet Industry	No		No, I would like to continue to the next section	Support Purpose as written			Purpose should be deleted		At the time of the preparation of the report the question of access to data has neither been fully discussed nor has the lawfulness of responses to disclosure requests been assessed exhaustively. It is difficult to assess the lawfulness of such purpose in the absence of knowing the parameters for disclosure, should any such recommendations be made. Additionally, even without the definition of a related purpose, information may be provided to respond to lawful disclosure requests, such as requests from competent law enforcement authorities. As a consequence, no definition of a purpose needs to be defined for these cases. It is questionable whether data may lawfully be kept to enable those holding the data to disclose it to third party beyond such cases. Therefore, a purpose relating to disclosure of data to third parties may be unlawful and it should only be included in the final report conditional to affirmative confirmation by either a competent authority or legal counsel.	Support Purpose intent with wording change	ENABLE COMMUNICATION WITH AND/OR NOTIFICATION TO THE REGISTERED NAME HOLDER FOR MATTERS RELATING TO THE DOMAIN NAME AND / OR ITS FUNCTIONALITY.	Where the registered name holder is permitted to designate agents, any correspondence with such agents is in fact communication with the registered name holder. Thus, the additional language is at best redundant, if not misleading as it might be construed as a justification to install or maintain the roles of the technical or administrative contact although the current practice of collecting and otherwise processing the respective data for these contacts is not part of the preliminary recommendations of the EPDP team. The additional clarification on the type of communication shall further specify the purpose to ensure that contactability shall not need to be facilitated by contracted parties to e.g. serve as a communications channel with customers of the registered name holder on support queries.	Support Purpose as written		We support the purpose as written. The legal basis for the processing shall, however, be determined as being Art. 6 I f GDPR as it is not related to performing the contract with the registered name holder.	Support Purpose intent with wording change	HANDLE CONTRACTUAL COMPLIANCE MONITORING REQUESTS, AUDITS, AND COMPLAINTS SUBMITTED BY REGISTRY OPERATORS, REGISTRARS, REGISTERED NAME HOLDERS, AND OTHER INTERNET USERS AS DEPICTED IN THE ATTACHED RECORD OR PROCESSING ACTIVITIES. (The document would actually need to be added to the recommendation)	There is no full understanding as to how ICANN exactly handles compliance matters. A record or processing activities to help understand what data is needed to perform the tasks, how it is handled and how long it is retained by ICANN has not been provided. Therefore, it is difficult to support a purpose relating to activities that are not fully transparent to the community. Whilst we support the essence of the purpose, our support is conditional to processing activities that are clearly and exhaustively depicted in a corresponding record. Also, it shall be limited to such processing of personal data that is needed, and not only desirable to have, to perform the tasks. The legal basis for this processing shall be clarified as being Art. 6 I f GDPR.	Support Purpose intent with wording change	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.	Future policies must not be covered by or referenced to in the language of the purpose for a lack of specificity. When new policies are created, these might need to be covered by additional purposes to be added to the documentation.	Support Purpose as written				There are no additional purposes we would like to suggest. Our comment relates to the purposes as defined in this document. We regard it as necessary to test the language of the purposes against the overall package of recommendations that the EPDP will come up with to ensure that all recommended processing activities are adequately reflected in a purpose that passes the test of GDPR requirements. Also, it shall be noted and made explicitly clear in the final report that the purposes and related processing activities only cover those areas that shall be governed by ICANN’s policies and thus be made part of ICANN’s contracts and be enforced accordingly. However, there may be additional purposes pursued by contracted parties and ICANN that are out of scope of this EPDP or ICANN’s governance. Nothing in the EPDP’s findings shall prevent the contracted parties or ICANN from conducting additional processing activities, which certainly must be compliant with applicable laws.		No, I wish to continue to the next section	Delete recommendation	The recommendation shall only be supported conditional to confirmation that such processing is possible in a legally compliant fashion. One way of doing this is to recommend the preparation of a code of conduct according to Art. 40 of the GDPR and enact the recommendation only if and when such code of conduct is approved.			Support recommendation as written			The recommendation shall be kept as it is. No additional requirements to verify the accuracy of data given by the data subject or to validate such data shall be part of any recommendation of the EPDP team. Whilst contracted parties shall ensure that data is accurately recorded in their system as provided by the data subjects, any additional requirements are neither warranted by GDPR nor in scope of the EPDP.	No, I wish to continue to the next section	Yes			No additional elements shall be collected.		Optional	The collection of data on the tech-c must be optional as it is not needed to perform the contract with the data subject. As a consequence, the processing requires consent. Any recommendations relating to the role of the tech-c must ensure that all legal requirements for consent-based processing are followed and, where the data is not collected from the data subject, Art. 14 of the GDPR needs to be complied with.	No	There are technical and legal challenges with consent-based processing. These are likely out of scope for this EPDP to resolve. Therefore, the offering should be optional until such time when an industry-wide approach has been agreed upon.	Yes	These data elements are not needed in practice. The role of the admin-c is not different than the role of the registered name holder. The billing contact is not used for billing purposes as the account holder is invoiced. Thus, according to the principle of data minimization, both roles shall not be maintained further and no relating data shall be collected.		Yes		The transfer of data from registrar to registry can only take place based on different purposes and different legal grounds. Where the processing is based on Art. 6 I b GDPR to perform the contract, it can unconditionally be transferred. Where the processing takes place based on Art. 6 I f GDPR, it can only take place if the registry actually asserts to have a legitimate interest in such processing. Absent the assertion of such interest, no data shall be transferred based on Art. 6 I f GDPR.		Support recommendation as written				Support recommendation as written	Yes		The support is conditional to a record of processing activities that shall be provided by ICANN org and be exhaustive.		Yes	N/A		Yes	There is consensus that the registrant field shall be redacted. As the registrant field is populated with the same data as the organization field, it is only straightforward also to redact the organization field. This issue is closely linked to the distinction of natural and legal persons. If and when a compliant way to make a distinction between natural and legal persons can be found, the organization field can be published where no personal data is revealed. However, such mechanism does not exist (yet).		Delete recommendation	Whilst it might be desirable for the registrar to provide information to the registered name holder, it does not seem likely that the provision of educational material will ensure compliant handling of the organization information. Hence, a solution to allow for the compliant treatment of organization data needs to be found, one component of which may or may not be the provision of educational material. This, again, relates to the distinction between natural and legal persons. If a solution for that issue is found, the question on the publication of the organization field can be answered easily.			Support intent of recommendation with edits	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. The preferred option is the offering of web form.	The reason for spelling out the web form as a preferred option is that e-mail addresses as a communications channel might lead to disclosure of personal data if, e.g. an auto responder is deployed by the registered name holder.	The requirement for offering a communications channel shall be designed to follow a “relay & delete” approach. Contracted parties shall not be obliged to ensure or record delivery of communication or otherwise commit to service level agreements.	Support recommendation as written		We support the fact that a retention period is now substantiated with policy requirements, namely the TDRP. It shall be clarified, however, that data retained for that purpose may only be used for that purpose and not for other purposes. The purpose would cover escrowing data as that is also to ensure the legal position of the registered name holder according to the TDRP can be secured.		We support the reasons spelled out in the initial report in favour of a uniform approach globally.			Contracted parties should not be required to make the distinction between natural and legal persons as legal persons’ data can include personal data, which constitutes compliance risks. If and when there is a sufficient level of certainty that different treatment based on the self-identification by the registered name holder is a practice that will not be sanctioned by the authorities, a distinction can be considered. A sufficient level of certainty could be established with an affirmative statement by competent authorities, the EDPB or a code of conduct according to Art. 40 GDPR.		No. A study will not help resolve the compliance questions.	We are not aware of any examples where the practice of making a distinction between natural and legal persons has been approved by a competent authority.		No comment on such recommendation can be made until the EPDP team had a full discussion of the matter.			Support recommendation as written		We support the rationale offered in the initial report. There has been criticism of the joint controller approach, but more based on concerns regarding the implementation. To date, no other concept has been proposed with a sufficient level of detail to even assess the legality. Absent a sound alternative proposal, the joint controller approach shall be pursued. The parties at risk of being sanctioned as well as the wider community should bear in mind that - not having the arrangements / agreements in place or - having agreements in place that do not provide adequate rights to the data subjects poses significant risks on contracted parties. Implementing a joint controller setup does not seem to have any of the two above risks. If and when competent authorities constitute that fewer or other requirements are sufficient, the concept can be changed, but for the time being, the community should ensure that there will be no compliance risks that could not only put contracted parties but also ICANN at stake.			No, I wish to continue to the next section
29	12/21/2018 14:03:21	Zoe Bonython	RrSG	No		No, I would like to continue to the next section	Support Purpose as written		We support the concerns that were expressed by our RrSG Rep with regard to the use of the term "rights," in the context of a commercial service contract. Any modification or deletion of the qualifying introduction ("As subject to...") will negate support for this purpose.	Purpose should be deleted		ICANN's mission does not explicitly include enabling third-party access to registration data. Third-party access may be found to be a legitimate secondary purpose. Additionally, the EDPB has already cautioned ICANN against conflating its purposes with that of third-party interests. https://edpb.europa.eu/sites/edpb/files/files/news/icann_letter_en.pdf	Support Purpose intent with wording change	Change to: Enable Communications with and/or notification to the RNH, or their designated agent, for issues regarding a Registered Name	Recommendation is poorly written and contains excess wording to no benefit.	Support Purpose intent with wording change	Delete "OR OTHER UNAVAILABILITY OF A REGISTRAR OR REGISTRY OPERATOR"	Additional language is overbroad.	Support Purpose intent with wording change		While there is purpose in ICANN being able to enforce compliance of its agreements with Contracted Parties, this purpose is contingent on the resolution of ICANN's status as a data controller or joint controller. Clearer definitions are needed re monitoring and auditing registration data before they can be included as components for this purpose.	Support Purpose intent with wording change	Change to: 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 DISPUTE PROCEDURES FOR WHICH IT IS ESTABLISHED THAT THE PROCESSING OF PERSONAL DATA IS NECESSARY.	Proposed recommendation is awkward and overly specific without gain.	Support Purpose intent with wording change	Replace “CRITERIA VOLUNTARILY ADOPTED BY THE REGISTRY OPERATOR” with “WHERE APPLICABLE AND AS VOLUNTARILY ADOPTED BY THE REGISTRY OPERATOR AND SUPPORTED BY REGISTRARS OFFERING THAT GTLD.”	“Criteria” may not be applicable to GDPR or other data protection laws, and Registrars offering the gTLD must also voluntarily support this purpose as a precondition to offering the gTLD.	No additional comments, except to note that this exercise (catalog of purposes) was part of RDS PDP. Note duplication of effort and compare/contrast outcomes	None		No, I wish to continue to the next section	Delete recommendation		While we understand this language was compromise language within the ePDP team, the RrSG does not believe it is appropriate to consider this a policy recommendation at this time. As stated in the ePDP charter and reinforced in the initial report, the topic of Standardized Access to non-Public registration Data should only be considered once all of the gating questions have been answered. The access discussion was clearly going to be one of the most challenging issues for the ePDP team to address and it was very deliberate of the GNSO council to structure the Charter in this manner so as to head-off the possibility of this topic derailing the work of the group. It is crucial the team be allowed to address and lock down solid policy recommendations based on the gating questions before addressing the issue of access to non-public Registration Data. Members of the RrSG participating in the ePDP team have been consistent in voicing their openness to participating in the discussion surrounding access once the gating questions have been addressed and we reinforce that sentiment in these comments. At such time that the working group has resolved all of the gating questions, we look forward to moving on to the discussion around access.		Support recommendation as written				No, I wish to continue to the next section	No	Eliminate from 'Registrant Fields': Phone ext, Fax & Fax ext. Also eliminate: Tech ID, all Tech Fields (Name, Phone, Email).	While the RrSG welcomes the omission of the Admin-C and Billing-C, the retention of Tech-C (albeit as an optional field) is inconsistent with decisions of the German Courts in ICANN v EPAG. In particular, the higher regional court commented that 'it is already not clear to what extent the storage of the data of the so-called Tech-C... is absolutely necessary for the Applicant’s purposes.' A field that is given as optional cannot, by definition, be considered 'necessary' for GDPR purposes. RrSG notes that the initial report highlights a divergence of views as to whether optional fields should be optional for registrars to collect, or optional for registrants to provide (and by implication compulsory for registrars to offer). RrSG supports the elimination of Tech-C.	See response to section on legal v natural persons		Optional	The preference is to delete the Tech-C data elements. Technical contact data is not necessary to complete a registration.	No	If optional fields were provided by the registrar the data subject/registrant would voluntarily add any information that they consented to being disclosed in WHOIS.	Yes	The RrSG supports the recommendation that contact information for billing and administrative contacts should not be collected. Administrative and billing contacts are a relic from the original WHOIS specification and have now been superseded by subsequent data fields, namely the registrant fields (for admin contacts), and the registrar-collected customer data (for billing contacts).		No	Any personal data currently redacted on WHOIS should not be transferred from the registrar to the registry, with the exception of if they collect specific elements to validate requirements (e.g. local presence).	Registries must provide legal justification/purpose for receiving personal data. Simply wanting the data is not sufficient. If the requirements are met, and there is a data protection addendum or other similar contractual protections in place, we would be happy to share the personal data. Transfer of data from registrar to registry would also expose that data to access requirements that may be unlawful in the jurisdiction that the registrar is based.		Intent and wording of this recommendation requires amendment	Recommended changes to the wording: The EPDP Team recommends that each Registry/Registrar enter into legally compliant data processing agreements with the data escrow providers. The EPDP Team recommends that registries and registrars transfer the necessary personal data to the data escrow provider in order to safeguard the Registered Name Holder's Registration Data, to enable the further administration of a domain name. The data elements workbook sets out the data elements in Annex D, Workbook 4 and must be in line with the principle of data minimisation.	The data elements which are not personal data are sufficient but the only personal data elements to be transferred should be those collected in line with data minimisation.		Delete recommendation	No	In the event ICANN require personal data, they must provide a legal justification and purpose, it must be proportionate and it will be done on a case by case basis.	While ICANN compliance may require to check with registries or registrars in respect of a compliance issue for a domain name, there is no clarity on why ICANN require the personal data of a Registered Name Holder.		Yes			Yes	ORGANIZATION: The publication of the ORGANIZATION field would be possible only if it did not contain personal data relating to private individuals. Regretfully, this is usually not the case as registrants have put that field to various non-intended uses, not the least of which is the repetition of the first and last name fields. Further, certain organizational structures of legal entities contain personal information in the name of the entity and while such data would not be protected under the GDPR as the entity name, the personal data contained therein would be protected. As the possibility of unintended publication of personal data could not be prevented in case of publication of the ORGANIZATION field, contracted parties need to be able to determine on their own whether they need to redact this field. Additionally, because there is 20+ years of legacy WHOIS data in circulation that was obtained (often in violation of WHOIS terms of use), resold, and archived, the registrant org field is being used as an “index” to match redacted records to unredacted archives, leading to the ability to indirectly identify data subjects, many of whom may be natural persons. We therefore propose that the redaction of this field be optional.	CITY: Non-redaction of the city field in connection with other available data such as the domain name itself may allow the identification of the registrant, especially for smaller cities or towns with only a few hundred inhabitants. We therefore propose that as a default the CITY field remain redacted. EMAIL: We support the EPDP recommendation. TECH: As the main concern of the TECH fields is to provide the ability to contact a knowledgeable party, it should be sufficient to provide only the necessary contact details to enable such contact. For such purposes, the identity of these contacts is not required. Furthermore, in legacy registrations many registrants filled this contact with their own details. Therefore, removal of redaction would expose their personal information. We therefore propose that the name and phone number remain redacted and the email contact be handled in accordance with the EPDP team recommendation.	Delete recommendation			If the Final Report recommends that the Organization field not be redacted, then the language of Recommendation #9 should be replaced with the following: “The EPDP team recommends that registrars provide information to Registered Name Holders about how to complete the Organization field.”	Support intent of recommendation with edits		We support the intent of this recommendation but believe it should be up to the registrar to determine if this is an option they want to make available for domains under their management. Registrars may choose to allow for other methods of contactability not specified in the Temporary Specification and we believe it should be left up to each individual registrar on how they want to make that option available to registered name holders. Furthermore, we would encourage registrars to implement a web-based contact form as opposed to relay e-mail addresses as the latter have the potential to be compromised and lead to unforeseen issues down the road.		Support intent of recommendation with edits	Change to: “The EPDP Team recommends that Registrars are required to retain the herein specified data elements for a period of at least one year following the life of the registration….”	We support the intent of this recommendation but would suggest the language be edited as noted above to allow for registrars to choose to retain data for longer than one year if applicable law or other guidance suggests longer than a one year data retention period.		The RrSG would like to spell out our numerous high-level concerns against making any Consensus Policy recommendations for contractual requirements regarding a mandatory distinction between legal and natural persons as well as requiring a differentiation of registered name holders on a geographic basis. Our concerns involve: • Legal - Aside from GDPR, other data protection laws around the world are less clear on the distinction between legal and natural persons. Future regulations may contain contrary requirements. Furthermore, data of legal entities may contain or consist of personal information of natural persons, which would be entitled to protection under the GDPR and similar data protection regimes. Likewise, the geographic distinctions also create uncertainties. The goal of whatever consensus policy comes out of this working group should be one that is not focused solely on one privacy law but rather creates policy that will be as future-proof as possible. • Technical - Contracted Parties are uniquely situated to assess the current level of the technological means available to us, and it is our position that a technical basis to reliably and confidently make such a distinction does not exist. Additionally, any distinction schema would be dependent upon Registrant Self-Identification, which is fraught with error and would create artificial barriers to entry for those persons or organizations around the globe looking to register and use a domain name. • Commercial - Developing and deploying this technology on a global scale will involve significant costs, which may be prohibitive for smaller organizations and a barrier to market entry. Regardless of whether the distinction(s) are applied to new registrations or legacy domain names, it would be a logistical nightmare for Contracted Parties, and a source of confusion for Registrants, many of whom could lose access to their registrations. • Asymmetrical Risks vs. Benefits - Contracted Parties would assume all regulatory risks of such an obligation, exclusively for the benefit of unburdened third parties. Simply put, registrars cannot accept a policy which creates such a high degree of risk for something that does not need to be differentiated. • Scope - The distinction between Legal and Natural persons, or geographic regions, does not currently exist in the Domain Name System. Therefore, any recommendation mandating this change is outside the scope of the ePDP, and possibly the “picket fence” of Registrar and Registry contracts. While some may point to certain ccTLD registries which do call for similar distinctions, attempting to equate that to the gTLD space (and its expansive, global nature) is simply not appropriate.	See above	See above	See above	See above	No. Any study would not change the basis for the above rationale, so there would be no point on spending time and resources on it.	There are several European ccTLD registries which make such a distinction, however introducing such efforts at this late stage for all gTLDs across the board would be unfeasible, presenting a significant technical and logistical burden which disproportionately affects smaller registrars. Additionally, the existence of such programs in other contexts does not alleviate the concerns raised in #84 above, which remain valid and pose significant risks.	Intent and wording of this recommendation requires amendment	Change to: “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 NonPublic Registration Data has been completed, and only after resolution of the gating questions"	Each registry and registrar should be able to evaluate to whom they may disclose personal data. There are local laws to take into consideration, as well as any data privacy legislation. It would be impossible to have a blanket order to disclose personal data as it would depend on the requestor. Each registry and registrar has their own processes for such disclosure. Registrars will push back strongly on any attempt to contractually bind them to disclose data.		Support recommendation as written					No, I wish to continue to the next section
30	12/21/2018 14:29:38	Domain.com, LLC & affiliates - ICANN accredited registrars	RrSG	No		No, I would like to continue to the next section	Support Purpose as written			Purpose should be deleted		Enabling third-party access to data elements is not within ICANN’s mission. Further, “enabling” third-party access is not a legitimate purpose for collecting data. It is instead is instead a right where under certain circumstances where and when allowed by law.	Support Purpose intent with wording change			Support Purpose intent with wording change			Support Purpose intent with wording change			Support Purpose intent with wording change			Support Purpose intent with wording change						No, I wish to continue to the next section	Delete recommendation				Support recommendation as written				No, I wish to continue to the next section	No	Technical Contact	There is no legitimate purpose for a registrar to collect a technical contact in order to register a domain name. Additionally, if it were to be made optional as the EPDP team suggests, Domain.com support the comments made by the Registrar Stakeholder Group in its input of the report that optional data is not “necessary” data for GDPR purposes.			Optional		No		Yes			No				Intent and wording of this recommendation requires amendment				Delete recommendation	No				Yes			Yes			Delete recommendation				Support intent of recommendation with edits				Support intent of recommendation with edits											Intent and wording of this recommendation requires amendment				Support recommendation as written					No, I wish to continue to the next section
31	12/21/2018 15:06:00	Ashley Roberts	Valideus	No		No, I would like to continue to the next section																									No, I wish to continue to the next section									No, I wish to continue to the next section																																																												No, I wish to continue to the next section
32	12/21/2018 16:02:37	Ashley Heineman	NTIA	Yes	United States Government	No, I would like to continue to the next section				Support Purpose intent with wording change	The U.S. proposes Purpose 2 be edited to include a reference to ICANN’s “commitments and core values.”	The U.S. believes this purpose is consistent with the EPDP Charter and European Data Protection Board guidance. Purpose 2 is narrowly tailored to the purpose and processing activities of ICANN and does not address the specific interests and purposes of third parties, subjects to be addressed at a later date. The U.S. strongly believes that for ICANN to meet its fundamental purpose of maintaining the security, stability, and resiliency of the DNS there are legitimate interests internal and external to ICANN necessary for ICANN to achieve this. To reflect this, the U.S. proposes Purpose 2 be edited to include a reference to ICANN’s “commitments and core values.” With this edit, Purpose 2 becomes the baseline necessary for ICANN and the community to develop and implement an access model at a later date that includes legitimate third party interests such as law enforcement, cybersecurity, and intellectual property enforcement.																			No, I wish to continue to the next section	Support recommendation as written								No, I wish to continue to the next section						Optional		Yes	The U.S. believes that registrars should continue to be required to collect information contained in the tech fields in addition to the registrant fields. There are a number of useful reasons for providing the information contained in the tech fields that are distinct from the registrant fields, including when a registrant has specific/distinct contacts responsible for acquiring/maintaining registration and other contacts responsible for ensuring the security of the domain. In this example, being able to reach the informed technical contact responsible for security issues directly and quickly to respond to issues such as the domain being under control of a botnet, may be a matter of urgency. In light of this and other examples, the U.S. does not believe it is appropriate for registrars to unilaterally determine that the information contained in the tech fields are not necessary to collect. And while contracted parties have expressed concerns that continuing to make it a requirement to collect this information exposes them to increased legal liability risk in cases of third party contacts, the U.S. believes that the European Data Protection Board has already provided guidance on the matter saying it is permissible as long as the individual concerned is informed (see EDPB letter to Goran Marby, July 5, 2018, footnote 15).																	No	City and organization	The U.S. wants the organization name and city fields to remain public and not be redacted. There is no evidence that indicates that publication of these fields is in violation of GDPR or is personally identifiable in combination with other published fields. In fact, there are other public online resources that make these fields (and others) available. Most notably are the business registers that are maintained and published by most European countries and consolidated by the European Business Register. The U.S. appreciates that the organization field has been incorrectly filled in by some registrants in the past and that in some cases they have included personally identifiable information. The U.S. does not see previous inaccurate information as justification to stop publication of these fields, but rather an opportunity to better inform registrants for new registrations and to clean up historical records in a phased in manner (e.g., including through annual notices to registrants, etc.).	No	The U.S. wants the organization name and city fields to remain public and not be redacted. There is no evidence that indicates that publication of these fields is in violation of GDPR or is personally identifiable in combination with other published fields. In fact, there are other public online resources that make these fields (and others) available. Most notably are the business registers that are maintained and published by most European countries and consolidated by the European Business Register. The U.S. appreciates that the organization field has been incorrectly filled in by some registrants in the past and that in some cases they have included personally identifiable information. The U.S. does not see previous inaccurate information as justification to stop publication of these fields, but rather an opportunity to better inform registrants for new registrations and to clean up historical records in a phased in manner (e.g., including through annual notices to registrants, etc.).		Support recommendation as written															GDPR does not apply to legal persons	The U.S. supports making a distinction between legal and natural persons as it pertains to the publication of registration data. Specifically, as GDPR does not apply to legal persons, the U.S. believes that information pertaining to legal persons should be publicly displayed. Recognizing that there are challenges in current systems making this distinction from both technical and procedural perspectives, rather than making it an immediate requirement, the U.S. believes that the EPDP should develop a recommendation that the GNSO immediately initiate a process to address this distinction as a future contractual requirement. The U.S. points to the wording proposed by the GAC, which ties the distinction directly to the further development and implementation of RDAP. Specifically: “the GAC proposes that the EPDP consider the following as a new recommendation: Recommendation x: A mechanism be developed within RDAP to differentiate between natural and legal persons. This differentiation is to be implemented within the rollout of RDAP along with a procedure to allow for a phased approach to update legacy registration information.”		There are other public online resources that make information associated with legal persons publicly available. Most notably are the business registers that are maintained and published by most European countries and consolidated by the European Business Register.	Support intent of recommendation with edits	the U.S. would like to see these criteria “incorporated” as opposed to “further explored” as part of implementation, consistent with the GAC comments.	The U.S. believes the criteria provide much needed predictability and clarity around the obligation of “reasonable access” including what the process and expectations for requesting and providing access need to be. The criteria are easy to implement as contracted parties have the flexibility to implement them in a manner that works for individual business models with the only obligation being to make the terms publicly available and otherwise communicated to the requesting parties. The U.S. wants these criteria incorporated as part of implementation and believes they will streamline the process of requesting and providing access for all parties.		Delete recommendation		The U.S. believes that this recommendation appears to go beyond what is necessary for the EPDP. Proposing a specific legal vehicle (i.e., Joint Controller Agreement) without adequate consideration of how this would impact ICANN and the different types of registries and registrars that are ICANN’s contracted parties is concerning and has the potential to derail the work of the group.		[As noted previously] The U.S. supports making a distinction between legal and natural persons as it pertains to the publication of registration data. Specifically, as GDPR does not apply to legal persons, the U.S. believes that information pertaining to legal persons should be publicly displayed. Recognizing that there are challenges in current systems making this distinction from both technical and procedural perspectives, rather than making it an immediate requirement, the U.S. believes that the EPDP should develop a recommendation that the GNSO immediately initiate a process to address this distinction as a future contractual requirement. The U.S. points to the wording proposed by the GAC, which ties the distinction directly to the further development and implementation of RDAP. Specifically: “the GAC proposes that the EPDP consider the following as a new recommendation: Recommendation x: A mechanism be developed within RDAP to differentiate between natural and legal persons. This differentiation is to be implemented within the rollout of RDAP along with a procedure to allow for a phased approach to update legacy registration information.”	No, I wish to continue to the next section
33	12/21/2018 16:17:34	Jeremy Dallman, David Ladd – Microsoft Threat Intelligence Center; Amy Hogan-Burney, Richard Boscovich – Digital Crimes Unit; Makalika Naholowaa, Teresa Rodewald, Cam Gatta – Trademark; Mark Svancarek, Ben Wallace, Paul Mitchell –Internet Technology & Governance Policy; Cole Quinn – Domains and Registry; Joanne Charles – Privacy & Regulatory Affairs	Microsoft Corporation	No		No, I would like to continue to the next section	Support Purpose intent with wording change	(I) TO ESTABLISH THE RIGHTS AND OBLIGATIONS OF A REGISTERED NAME HOLDER IN A REGISTERED NAME;	Microsoft notes that a registrant provides their contact details not only to establish their claim to a specific domain, but also in agreement to certain obligations in connection with their registration, and the provision of their data is integral to establishing the identity of the registrant so that the registrar, registry operators and (potentially) third parties are able to identify the party which has undertaken such obligations, even beyond Purpose 3 which deals with communication.	Support Purpose intent with wording change	“Ensuring 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 such as cybersecurity investigations, intellectual property enforcement, consumer protection, DNS abuse mitigation, and law enforcement, to data elements collected for the other purposes identified herein.”	ICANN’s mission is to ensure the stable and secure operation of the Internet’s unique identifier systems, and this requires that ICANN ensure access to domain registration data for criminal law enforcement, cybersecurity investigations, consumer protection, and intellectual property protection. (Note that we do not ask for ICANN’s active involvement in any such investigation, dispute, or litigation. Rather, we submit that ICANN’s role has always been to ensure that the mechanisms exist which enable domain registration data to be made available for those who need it for legitimate purposes.) Microsoft and others are empowered by law to perform civil cybersecurity investigations. US federal legislation (e.g. the Lanham Act and the Computer Fraud and Abuse Act) has introduced civil causes of actions or claims for private litigants to bring actions. Certain causes of action are specifically tailored for civil cybersecurity cases. In the Rustock investigations, Lanham Act civil seizure warrants were required to take malware servers offline. Brand protection is inextricably linked to consumer protection and the possible harm to consumer is exacerbated by the availability of pirate and counterfeit goods online and the ease with which they can be obtained /purchased. Our ability to protect consumers by using these existing statutes and adapt them into the cybersecurity realm has been extremely successful. The original wording does not accurately reflect this. Key to these statutes is the concept of notice. For us to bring any type of case, we must show the court that there has been a legitimate attempt to provide Notice of Process. If we can’t provide this to the court, the case may be dismissed. We will discuss some implications of this elsewhere where publication of email addresses is discussed, but it should be apparent that many types of civil actions and dispute resolutions depend on identifying and contacting registrants. Therefore, we believe that more specificity is required to clarify that legitimate third-party interests play an important role maintaining the security, stability and resiliency of the domain name system, a role which has been impaired since the registrars and registries began making registration data unavailable to these legitimate third parties. In this regard, we are encouraged by the recent opinion of the ICANN Security and Stability Advisory Committee. Microsoft has relied on registration data for many types of investigations, both reactive (identifying bad actors after known attacks) and proactive (using registration data to prevent future attacks by these same actors), and our work provides important support to law enforcement. A few Microsoft investigative efforts using registration data are documented here: • Anti-Phishing Working Group’s study • Cybersecurity Tech Accord study Finally, when Microsoft trademarks and intellectual property have been abused, and related cybersecurity issues have not been identified, it is often the case that a letter or email from Microsoft informing a registrant of the problem is enough to resolve the issue. This desirable outcome benefits all parties and depends on access to accurate data.	Support Purpose intent with wording change	“ENABLE COMMUNICATION WITH AND/OR NOTIFICATION TO THE REGISTERED NAME HOLDER AND/OR THEIR DELEGATED AGENTS OF TECHNICAL, LEGAL, AND/OR ADMINISTRATIVE ISSUES WITH A REGISTERED NAME.”	In addition to administrative issues, communication should be enabled for legal issues involving a domain name. Enabling communication for legal issues ensures proper notice and due process where a domain name might implicate certain legal matters.	Support Purpose as written			Support Purpose as written		Our support for the statement as written is based on the assumption that existing accuracy obligations will continue to be contractually maintained and effectively enforced by ICANN. Our cyber research and digital crimes investigations benefit when the registration data is accurate. Often registrants are unaware that they have been compromised and being able to contact them when anomalous behavior is detected is can be helpful. This is one way that accurate registration data allows us to protect registrants, Internet users, and general consumers. Likewise, in cases where Microsoft trademarks and intellectual property have been abused, it is often the case that a letter or email from Microsoft informing a registrant of the problem is often enough to resolve the issue. This desirable outcome benefits all parties and depends on accurate data. To the extent that the data is not accurate, we require the compliance functions to be in place and enforced by ICANN to hold registrars accountable to their accuracy obligations.	Support Purpose intent with wording change	“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, BUT INCLUDING WHERE SUCH POLICIES TAKE INTO ACCOUNT USE OF THE DOMAIN NAMES), NAMELY, THE UDRP, URS, PDDRP, RRDRP, AND ANY FUTURE DEVELOPED DOMAIN NAME REGISTRATION¬-RELATED DISPUTE PROCEDURES FOR WHICH IT IS ESTABLISHED THAT THE PROCESSING OF PERSONAL DATA IS NECESSARY. THIS PURPOSE SHOULD NOT BE READ TO LIMIT ANY OTHER PURPOSE WHERE PROCESSING OF DATA HAS BEEN RECOGNIZED AS LEGITIMATE IN CONNECTION WITH FACILITATING INVESTIGATION AND ACTION CONCERNING ANY OTHER LEGAL ISSUES INVOLVING A DOMAIN NAME, INCLUDING HOW A DOMAIN NAME IS USED.”	The language of the recommendation as currently written is not a full and accurate quotation from the ICANN Bylaws, and seems to conflict with the provisions of the UDRP and URS policies. The amended text above rectifies this. We also note that investigations into trademark disputes often detect serious Internet threats. For example, a domain name which mimics a Microsoft trademark may in fact be the endpoint for a phishing attack leading to credential harvesting or malware infection.	Support Purpose as written				A. A new purpose to address the needs and benefits provided by DNS security and stability research conducted through publication of reports on threats to the operational stability, reliability, security, global interoperability, resilience, and openness of the DNS, and on the accuracy of WHOIS. B. A new purpose to enable ICANN to conduct operations, facilitation activities, and implement consensus policies (adopted in accordance with the ICANN Bylaws) consistent with its mission of furthering the operational stability, reliability, global interoperability, resilience and openness of the DNS.	A. Research is a legitimate basis for processing per GDPR Article 6(1)f, with specific safeguards defined in Article 89. It is also squarely within ICANN’s mission and mandate, as the requirement for research derives from Section 1.2a (Commitments) of the ICANN bylaws: (i) Preserve and enhance the administration of the DNS and the operational stability, reliability, security, global interoperability, resilience, and openness of the DNS and the Internet; (ii) Maintain the capacity and ability to coordinate the DNS at the overall level and work for the maintenance of a single, interoperable Internet; This purpose exists to ensure that ICANN may continue to use registration data in support of its mission, while maintaining data subject privacy through appropriate safeguards such as pseudonymization. In addition, this purpose enables ICANN to continue to operate its Accuracy Reporting System (ARS), which publishes periodic reports on accuracy, using full WHOIS contact fields. The ARS is an important program approved by the ICANN Board in response to the recommendations from the 1st WHOIS Review Team. A.B. Prior to the May 25th adoption of the Temporary Spec, and consistent with its mission and mandate under the Bylaws, ICANN used full WHOIS data as part of op/sec related activities of the Office of the CTO to collaborate with public/private sector investigators, to train law enforcement agencies in techniques for mitigating cybersecurity threats such as CONFLICKER, or to work with a compliance related complaint. It also used WHOIS as it implemented consensus policies that involve the use of WHOIS data fields (such as in transfer policy processes or Thick WHOIS). It is important that ICANN continue to provide these services to enhance the DNS.	Yes
34	12/21/2018 16:34:28	Ben Butler	SSAC	Yes	Comments are made based on the collection of consensus views of SSAC members. See SAC104 for full information, rationale, and recommendations.		Support Purpose as written			Support Purpose as written			Support Purpose intent with wording change	This wording conflicts with Recommendation 4, which would do away with Administrative and Technical Contacts.	The wording on this recommendation could be fine as long as the role-specific contacts such as Technical remain intact. See responses to items 44, 45 below for more detail	Support Purpose as written			Support Purpose as written			Support Purpose as written			Support Purpose as written				SSAC supports the creation of an additional purpose for the processing of registration data (in deliberations referred to previously as Purpose O). This purpose would be for ICANN Org teams other than Contractual Compliance to be able to conduct research.	ICANN teams (like OCTO and SSR) should have the ability to conduct research relating to security, stability and overall patterns affecting the DNS ecosystem. This may require them to be able to access pseudonymized registration data.		Support recommendation as written		SSAC considers the creation and implementation of a standardized access system that will provide reliable and timely access to registration data to parties with legitimate interests under the law to be of vital importance. We emphasize that this work should begin as soon as it is possible to do so.	Much of the work to identify, investigate, and remove threats to the DNS is conducted by 3rd party cybersecurity professionals. The current system under the Temp Spec does not allow for sufficient or reliable access such that this work can continue to be as effective. Work to replace this with a scalable access model should begin without delay.	Intent and wording of this recommendation requires amendment		GDPR principle 1(d) requires that “Personal Data shall be accurate and, where necessary, kept up to date; every reasonable step must be taken to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay (‘accuracy’).” It is not logical to examine if only some ICANN policies comply with GDPR but to not examine others. Here the EPDP WP makes a recommendation about data accuracy, but so far the EPDP team has not fully explored the data accuracy requirements of the GDPR, and whether the procedures in the 2013 Registrar Accreditation Agreement (RAA) and the Temp Spec are GDPR-compliant. That needs to be done. SSAC believes that data accuracy in RDS is vital, and has commented many times on the importance of accuracy in RDS data.	A balanced situation is needed. An accredited RDS access program will allow examination of the data and challenges by parties who are pre-qualified and responsible actors, and some better requirements around reasonable access would assist non-accredited parties and would also be part of a balanced solution. Please see our notes regarding Preliminary Rec #12 / Question #8 for community input below. This situation also makes it more important for ICANN Compliance—which can request the data for examination--to perform accuracy checks going forward. See SAC104 for additional comments and information.	No, I wish to continue to the next section	Yes			The proposal for “Tech Fields” has two major problems. First, it allows registrars to choose whether to even give registrants the option of providing a technical contact. That will harm contactability, effectively reducing the ability of parties to solve technical issues on the Internet, and will deprive some registrants of an important capability they currently deploy. Second, the proposal creates significant, unnecessary technical and operational problems. It basically breaks how EPP is structured to handle contact data, would complicate transfers, and more. Below we propose a better solution that serves registrants and security better, without such wide-ranging technical changes. In the interest of security and stability, SSAC suggests a simpler solution that requires fewer changes and takes advantage of EPP’s object-based model: Registrars must offer the RDH the opportunity to provide a full Technical Contact, containing the same data fields that are provided for Registrant contacts. The Technical Contact should be optional for the RDH to provide. If a Technical Contact is provided to the registrar, the data must be provisioned to the registry, and the following fields must be published in public RDDs output: Name, Phone, Email, City, Country.	Recommendation 4’s Data Elements Fields proposal inadvertently requires significant changes to the EPP specifications and client-server implementations. This would create unnecessary confusion for current domain contacts, and would create unnecessary additional implementation delays. It will create a series of operational issues since registries would still be required to provide support for a technical contact. We see only two ways to implement such “Tech Fields” in EPP. One option is to make those three pieces of data fields in the domain name object itself. But that breaks the way EPP handles contact information. The other option is to put the data in a new kind of EPP “Tech Field” object. However, this new “Tech Field” object would be different from the contact objects used for the Registrant role, since Registrant contacts have a different set of mandatory data fields. Note that in EPP, contact objects are “generic” in that all contact objects contain the same required or minimum data fields. A contact object is then associated to a role with the domain: Registrant, Admin, Tech, or Billing. In EPP there is currently no such thing as a “Tech Contact Object” or an “Administrative Contact Object” – there are only generic contact objects, which are designated to serve a particular role when associated with a domain name object. The EPDP proposal would break that paradigm. Among the other implications: when creating objects, registrars would have to specify the Role that the contact object will be (and can only be) used for, which is something that is not done now. And registrars would have to create all-new “Tech Field” objects. to replace all existing contacts associated with Tech Contact roles. The “Tech fields” proposal also creates transfer problems. Some registrars have stated that they want to offer Tech contacts to their registrants. What will happen when a registrant using such a registrar wants to transfer his or her domain to a registrar that does not support Tech contacts? Introducing this kind of discontinuity and lack of standardization into the domain registration and management process is neither necessary nor desirable. See SAC104 for additional comments and information.	Optional	See above responses to 44, 45	Yes	See above responses to 44, 45				Yes								Support intent of recommendation with edits	Yes			The RAA currently requires that several other types of data be collected, data that has never been displayed in RDDS. For clarity, the report should state that these RAA provisions are not affected and should remain in place. Most important is the identity of the “Account Holder”, which the RAA defines as “the person or entity that is paying for the Registered Name or otherwise controls the management of the registered name, when that person or entity is not the Registered Name Holder.	No	Tech Fields collected (as optionally provided by data subject) should be the same fields as those fields collected for Registrant contact. If the tech contact data is collected from the Registrant, to the extent allowable by law, said data should not be redacted.	See 44, 45 above	No	Efforts should be made to provide educational material such that the data provided in the Org field can be relied on to not contain personal data, or else that the data is provided with proper informed consent by the data subject. With these conditions in place, the publication of the Org field can be useful.		Support recommendation as written				Support recommendation as written				Support recommendation as written							The GDPR states clearly that it “does not cover processing of personal data which concerns legal persons.” We recommend that registrars be required to deploy mechanisms that ensure a reliable declaration or determination of natural or legal person status for new registrations going forward, and to eventually obtain those declarations or determinations for existing registrations and their registrants.	Contact data associated with natural persons should be published in RDS. In SAC101, SSAC stated: “The new policy [The Temporary Specification] allows RDDS operators complete freedom to choose when to redact domain contact data from publication, whether or not a domain contact is protected by GDPR or by any other local privacy law. The result has been blanket redactions, hiding more data than is legally called for. A more balanced and justified approach is needed…. access should not be less timely, more restricted, and less public than law requires…. We also note that as of this writing, most ccTLD operators in the European Union continue to publish some (and sometimes all) contact data fields for domains registered by legal persons. Some continue to publish some personal data for natural person registrants in public WHOIS output.	SAC101 also highlights RIPE-NCC’s solution, which allows for the publication of data about natural persons contained in the contact data for legal persons. This process provides mechanisms that RIPE-NCC says were specifically designed to comply with GDPR. The RIPE-NCC solution seems to be balanced in that it provides contactability and does not over-apply the law. SSAC believes that RIPE’s model deserves a full examination and neutral legal evaluation.	See SAC104 for additional comments and information	Support recommendation as written			We recommend standardized, transparent requirements for “reasonable access” that can be clearly understood by contracted parties and potential requestors, and are clear enough to be enforced by ICANN Compliance. The current lack of definition inhibits reasonable requests and impacts the ability of security actors to fight abuse and cybercrime. Notable accounts of these problems are contained in the Joint APWG/M3AAWG GDPR and WHOIS User Survey results, and statements from the 60-plus members of the Cybersecurity Tech Accord. The Temp Spec’s current requirement is so vague as to be unenforceable See SAC104 for additional comments and information.	Support recommendation as written					No, I wish to continue to the next section
35	12/21/2018 16:35:31	Lori Schulman Senior Director, Internet Policy	International Trademark Association (INTA)	Yes	The International Trademark Association (INTA) is a global association of brand owners, legal professionals, academics, civil society and trademark and domain industry service providers and others dedicated to defending trademarks and related intellectual property (IP) rights to foster consumer protection, economic growth and innovation. With more than 7,200 members in over 192 countries, one of INTA’s goals is the promotion and protection of trademarks as a primary means for consumers to make informed choices regarding the products and services they purchase. INTA members frequently rely on and use ownership information in the global WHOIS database to locate and contact the registrant behind web sites that infringe the intellectual property rights of others, steal personal information, sell counterfeit goods, distribute malicious software and perpetuate fraud. During the last two decades, INTA has been the leading voice of trademark owners within the Internet community, serving as a founding member of the Intellectual Property Constituency (IPC). INTA’s Internet Committee is a group of over 175 trademark owners and professionals from around the world charged with evaluating treaties, laws, regulations and procedures relating to domain name assignment, use of trademarks on the Internet, and unfair competition on the Internet, whose mission is to advance the balanced protection of trademarks on the Internet.	No, I would like to continue to the next section	Support Purpose intent with wording change		INTA supports Purpose intent with a modification. The Purpose should be more accurately defined to refer to both the rights “and obligations” of the registered name holder, which reflects the practical and legal context in which a name is registered. For example, a registered name holder provides their contact details not only to establish their claim to a specific domain but also to put third parties on notice of that claim. The name holder also agrees to certain obligations in connection with their registration, and the provision of registration data is integral to establishing the identity of the name holder so that the registrar, registry operators and (potentially) third parties are able to identify the party which has undertaken such obligations. This goes beyond Purpose 3 (described below) which deals with communication.	Support Purpose intent with wording change	ENSURING THE SECURITY, STABILITY, AND RESILIENCY OF THE DOMAIN NAME SYSTEM IN ACCORDANCE WITH ICANN'S MISSION, AS SET FORTH IN ICANN’S BYLAWS TOGETHER WITH ICANN’S COMMITMENTS AND CORE VALUES, THROUGH THE ENABLING OF LAWFUL ACCESS FOR LEGITIMATE THIRD PARTY INTERESTS, SUCH AS LAW ENFORCEMENT, INTELLECTUAL PROPERTY RIGHTS HOLDERS AND CYBERSECURITY PROFESSIONALS,TO DATA ELEMENTS COLLECTED FOR THE OTHER PURPOSES IDENTIFIED HEREIN.	As described in the Bylaws, ICANN’s mission is to “ensure” the security, stability and resiliency of the DNS, not merely “maintain” it. This underscores that ICANN’s policies in this regard are proactive. The scope of ICANN’s Mission was carefully clarified and described in its Bylaws, and this is what should guide the interpretation of this purpose. For clarity sake, reference to the definition in the Bylaws is important. Furthermore, in order to ensure that there are examples of what may constitute legitimate third party interests, INTA believes strongly that those of law enforcement, intellectual property owners, and cybersecurity professionals are recognized as stakeholders in this area. This has been historically true at ICANN and should remain so, and is consistent with ICANN’s obligation to uphold the broader public interest, in furtherance of fulfilling ICANN’s Mission, under its Bylaws.	Support Purpose intent with wording change	ENABLE COMMUNICATION WITH AND/OR NOTIFICATION TO THE REGISTERED NAME HOLDER AND/OR THEIR DELEGATED AGENTS OF TECHNICAL, LEGAL, AND/OR ADMINISTRATIVE ISSUES WITH A REGISTERED NAME	The existing wording is unduly narrow and fails to acknowledge that the relationship between the registrant and the registrar is a legal one, which includes obligations not only in relation to the act of registering and technically maintaining the domain name, but other obligations pertaining to the terms of use which are included as part of the framework of agreements and obligations between ICANN, Registry Operators, Registrars and Registrants. These obligations are in accordance with ICANN’s Mission, as set forth in its Bylaws. Communication with the registrant when such terms are breached is a logical and proportionate purpose for data processing.	Support Purpose as written			Support Purpose as written			Significant change required: changing intent and wording	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, BUT INCLUDING WHERE SUCH POLICIES TAKE INTO ACCOUNT USE OF THE DOMAIN NAMES), NAMELY, THE UDRP, URS, PDDRP, RRDRP, AND ANY FUTURE DEVELOPED DOMAIN NAME REGISTRATION-RELATED DISPUTE PROCEDURES FOR WHICH IT IS ESTABLISHED THAT THE PROCESSING OF PERSONAL DATA IS NECESSARY. THIS PURPOSE SHOULD NOT BE READ TO LIMIT ANY OTHER PURPOSE WHERE PROCESSING OF DATA HAS BEEN RECOGNIZED AS LEGITIMATE IN CONNECTION WITH FACILITATING INVESTIGATION AND ACTION CONCERNING ANY OTHER LEGAL ISSUES INVOLVING A DOMAIN NAME, INCLUDING HOW A DOMAIN NAME IS USED.	INTA is concerned with the narrow and selective reference to the exclusion of processing for this purpose where it relates “use of domain names”, which ignores long standing ICANN policies applicable to domain name disputes. ICANN’s Bylaws specifically reference policies taking into account the use of domain names as part of ICANN’s mission, and in policy as well as practice, UDRP actions depend on a showing of bad faith relating to the use of a particular domain. The approach of the proposed language in the Initial Report may be seen as an attempt to undermine or alter the implementation of ICANN consensus policy in this area. It is therefore essential that this gross oversight be corrected through the inclusion of the language from the Bylaws. As a point of reference, INTA’s first proposed addition to the purpose statement quotes verbatim the language from the Bylaws.	Support Purpose as written				Purposes should reference the need for processing for law enforcement, DNS abuse, IP infringement and consumer protection purposes. INTA also supports clarification of purposes to include research of DNS abuse since this falls squarely within ICANN’s mission and is one of the primary bases for the obligation of registrars to collect registrant data insofar as ICANN is concerned. If these purposes cannot be clarified within the framework of the existing purposes enumerated above, then it may be necessary to include additional purposes.	The list of purposes set forth above are integral to accomplishing ICANN’s mission, and ensuring the health and welfare of the DNS system, for the benefit of individual registrants, as well as the many stakeholders who have an interest in the DNS system.	No, I wish to continue to the next section	Support intent of recommendation with edits	INTA requests that the general comment in Recommendation #2 be edited to read as follows: “In this context, amongst others, the EPDP Team will develop a policy that prescribes the method for disclosing non-public registrant data to third parties that have established legitimate interest in viewing registrant data including intellectual property rights holders, cybersecurity firms, organizations that mitigate DNS abuse, and law enforcement agencies, among others.”	INTA strongly supports this recommendation for the EPDP Team to develop a standardized, or “unified,” system for access to non-public registration data after the gating questions have been answered. INTA proposes edits to this recommendation to ensure that the protection of intellectual property rights is expressly recognized as a legitimate interest under GDPR and therefore understood to be within scope of the final policy. The term “legitimate” implies that the interest is bolstered by recognition of a legal right, which in the case of intellectual property is the reason for its very existence. Intellectual property rights are regarded as third generation human rights and are duly recognized as human rights under Article 27 (2) of the Universal Declaration of Human Rights. The Article provides that ‘Everyone has the right to the protection of the moral and material interests resulting from any scientific, literary or artistic production of which he is the author.’ In the Article 29 Working Party’s letter to ICANN dated April 11, 2018, the A29WP “welcome[d] the decision of ICANN to propose an interim model which involves layered access, as well as an “accreditation program” for access to non-public WHOIS data.” This communication signaled A29WP’s support for a standardized access program. This support is further echoed, in a May 27 communication to ICANN, in which the EPDB reiterated that it expects ICANN “to develop and implement a WHOIS model which will enable legitimate uses by relevant stakeholders, such as law enforcement, of personal data concerning registrants in compliance with the GDPR, without leading to an unlimited publication of those data.” With respect to the reference to “relevant stakeholders,” ICANN has identified “intellectual property rights holders as being such stakeholders with a legitimate interest in having access to registrant data. For the reasons expressed above and in deference to the statements provided, INTA recommends the edits provided above.		Intent and wording of this recommendation requires amendment	The accuracy requirements under the ICANN contracts and consensus policies need to be reflected in the EPDP recommendations, particularly because accuracy is itself a fundamental component of the GDPR. Greater accuracy will enhance the objectives of compliance with the GDPR while maintaining the WHOIS framework to the greatest extent possible, since accuracy is a common element of both sides of that equation. Therefore, the EPDP should consider requirements to include in its policy recommendations that will support maintaining and enhancing accuracy in the DNS, such as: ● Additional validation - currently only one field is validated as operational under the RAA (email or telephone number). The EPDP should consider how to expand the validation requirements to include other fields. ● Enhanced compliance tools - ICANN should be given broader powers to investigate the steps taken by a registrar in response to a complaint of inaccuracy, and to require registrars with unacceptably low accuracy rates to submit remediation plans. ● Cross-field address validation - ICANN should implement this requirement under the 2013 RAA. ● Rectification- ICANN should ensure that there is a standard, robust process for data subjects to have their data corrected. ● Accuracy Reporting System -- ICANN should continue publishing its periodic Accuracy Reports, and the policy should allow ICANN the ability to access the full WHOIS records necessary to conduct this analysis.	GDPR Article 5 states that personal data shall be "accurate and, where necessary, kept up to date; every reasonable step must be taken to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay." The ico. (Information Commissioner’s Office in the UK) points out in its “Principle (d): Accuracy” that one of the new features of GDPR as compared to the principles under its predecessor is that there is now a “clearer proactive obligation to take reasonable steps to delete or correct inaccurate personal data.” The ICO notes that “[i]n order to ensure that your records are not inaccurate or misleading in [the case of personal data someone else provides], you must: … ● take reasonable steps in the circumstances to ensure the accuracy of the information; and ● carefully consider any challenges to the accuracy of the information.” The ico. goes on to say that “The more important it is that the personal data is accurate, the greater the effort you should put into ensuring its accuracy. So if you are using the data to make decisions that may significantly affect the individual concerned or others, you need to put more effort into ensuring accuracy. This may mean you have to get independent confirmation that the data is accurate.” The accuracy of WHOIS significantly affects not just the registrant but those third parties that access WHOIS for legitimate purposes such as intellectual property infringement of all types. The EPDP had been chartered to ensure that the new WHOIS policy complies with all of the principles of the GDPR. As a result, its work is not complete until it conducts a careful analysis of GDPR’s accuracy principles, and updates the WHOIS policy to address the unacceptably low levels of accuracy that exists today.		No, I wish to continue to the next section	Yes		INTA strongly supports the proposition that all data elements should continue to be collected/generated and that they should continue to be made freely available to the greatest extent possible while remaining GDPR compliant. In addition to supporting the various Purposes identified in the Initial Report, collection and access to these data elements support various other important public interests, including (a) consumer protection against counterfeits, fraud, phishing schemes etc., (b) the ability of law enforcement to efficiently respond to online criminal activity, and (c) efforts by brand owners to protect their brands online. Additionally, it is critically important to note that domain names commonly trade on the private market for millions of dollars. It has become commonplace for domain names to be worth more than most homes around the world. Accordingly, it is an unreasonable burden to place on the buyers in these transactions to mask the identity of the sellers, and thereby frustrate the ability to conduct diligence on the provenance of the domain. Like with any other financial transaction of this size, Buyers need to be afforded the protection of knowing the seller’s identity so that they can conduct the necessary due diligence and ensure that, for example, they are not dealing with a foreign government, funding any illicit activity, or even purchasing the domain from one of their employees.			Optional	INTA does not believe that collection of Technical Contact information should be “Mandatory”, However, the OPTION to provide this information should be required as some Registrants may wish to provide this information in order to route the appropriate communications within their organization. Therefore, INTA believes that Registrars should be required to provide registrants with the “OPTION” to provide Technical Contact information, although provision of this information by registrants should not be mandatory.	Yes	INTA does not believe that collection of Technical Contact information should be mandatory. However, the option to provide this information should be required as some Registrants, may wish to provide this information in order to route the appropriate communications within their organization. Therefore, INTA believes that Registrars should be required to provide registrants with the “OPTION” to provide Technical Contact information, although provision of this information by registrants should not be mandatory.	No	INTA does not believe that collection of Billing and Administrative Contact information should be mandatory. However, the option to provide this information should be required as some Registrants may wish to provide this information in order to route the appropriate communications within their organization. Therefore, INTA believes that Registrars should be required to provide registrants with the “OPTION” to provide Billing and Administrative Contact information, although provision of this information should not be mandatory.										Support recommendation as written			INTA supports compliance having all the data it needs to efficiently carry out its vital function to ensure that contractual obligations are being met, and issues are resolved as quickly as possible. This is particularly vital in the context of ICANN Compliance activities to support the combat of DNS abuse.		No	INTA supports publication of Registrant Email, Organization, and Registrant City. None of these data elements should be redacted.	In order to minimize consumer harm, it is important that swift action is taken in instances of suspected malicious activity. Malicious sites support a range of harmful bad practices including offering counterfeit goods or services, infringing trademarks or supporting some other illegal purpose like the support of malware. Typically, when a rights holders begins an investigation into whether a website is malicious, the email address is the first line of inquiry. Knowing the Registrant's city is another data point used to determine whether the site may be controlled by a bad actor or, instead, a business partner or other friendly entity. As important as it is to find bad actors, it is equally important to identify authorized users and avoid unnecessary enforcement actions including UDRP filings or other means of enforcement. Access to accurate and timely information can help rights holders avoid bringing registrants into the UDRP process unnecessarily. From a privacy perspective, oftentimes a Registrant’s Email address will not have sufficient identifying information to be able to decipher personal information, while still giving others an opportunity to correspond directly with the Registrant. Practically speaking, Registrants may provide email addresses without any personally identifying information. The implications of using email with personally identifiable information could be explained to Registrants during the domain name registration process. Therefore, Registrants will have full notice as to the accessibility of the email address and the ability to provide an email address with non personally identifying information. The legal basis of GDPR Article 6.1 (f) and corresponding balancing tests support the exercise of rights and furtherance of interests of third parties including law enforcement and intellectual property rights holders. The risk of the Registrant receiving unsolicited emails must be weighed against the risk of perpetuating online abuse and consumer fraud. As explained in INTA's response to Purpose 1 above, Registrants have rights and obligations within the domain name system. The risk of the Registrant receiving unsolicited communication cannot outweigh the accountability and transparency necessary when operating a website or email address related to a domain name. Alternatives like communicating through an anonymized email address or web form are not sufficient to overcome the challenges of redacted email. This is because communications from anonymized email addresses or web forms may either be marked as spam or never be properly forwarded. The net effect is that a third party attempting to get in contact with a Registrant would not be able to know if the email failed or if the Registrant is simply not responsive. Redacting or masking the email address of Registrants unduly restricts law enforcement, enforcement of intellectual property rights and consumer protection. It also prevents parties from amicably settling disputes related to potential online infringements and may trigger unnecessary legal actions based on the failure to properly identify a party prior to a legal filing. Many of these harms are rightfully avoided by publishing an accurate, contactable email address. The rationale for publishing organization information is more thoroughly explained below.	No			Support recommendation as written		As discussed fully in the answer to Recommendation #11 below, any ICANN Consensus Policy for generic top-level domain Registration Data should include a clear distinction between the treatment of data belonging to natural persons and data belonging to legal persons. Clear registrar guidance explaining to Registered Name Holders what information should and should not be included in the Organization field would help ensure that this distinction is clearly delineated, easy to follow, and consistent with the requirements of the GDRP while at the same time supporting accurate, reliable, and uniform Registration Data and preserving an ability to address law enforcement needs, intellectual property protection, consumer protection issues, and DNS abuse. Specifically, the very act of informing the public that the Organization field is reserved for Registered Name Holders that are legal persons should significantly reduce the likelihood that personal information is inadvertently entered into the Organization field. Additionally, providing further guidance about the Organization field to Registered Name Holders can help address concerns specific to certain types of businesses. For example, Registered Name Holders that are sole proprietors can be instructed to only fill out the Organization field if they do business under a fictitious name. Similarly, legal entities with names that include the personal name of an affiliated person can be instructed to either use a d/b/a in the Organization field or forego filling out the Organization field entirely.		Delete recommendation	INTA supports deleting this recommendation, as explained further below. In the alternative, INTA supports amending the recommendation to read: “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. HOWEVER, a Registrar MUST ensure that the email or web form is delivered to the registrant, and if it is not must inform the party seeking contact that the communication cannot be delivered to the registrant as the registrant has provided inaccurate contact information. A Registrar MUST then promptly take steps to secure accurate contact information.”	As explained more thoroughly in the response to Recommendation 8, INTA supports publication of the Registrant’s email address so that third parties may more easily identify and contact the Registrant directly. However, if the consensus of the EPDP working group is that such information should remain redacted, INTA requests that Registrars be required to ensure that the anonymized email address or web form contact, in fact, reaches the Registrant. Third parties looking to reach a Registrant often do not know if an anonymized email or web form reached the Registrant, or if the Registrant is simply ignoring the communication. If Registrars were required to not only ensure the accuracy of registrant contact information, but also notify a party seeking contact that the information did not reach its destination, then it may be possible to rely on anonymized email or web form only.						As INTA has noted previously, it shares ICANN’s objective to “identify the appropriate balance for a path forward to ensure compliance with the GDPR while maintaining the existing WHOIS system to the greatest extent possible.” In other words: whatever Consensus Policy emerges from the EPDP should be “calibrated” as much as possible – so as not to over-comply with the GDPR. INTA thus agrees with the reasoning of the BC and IPC, as articulated in the Initial Report, that Contracted Parties should be required (not merely permitted) to make differentiations (for example, in what gTLD registration data should be redacted vs. published in the public WHOIS) that are consistent with the territorial scope of the GDPR. At the least, INTA suggests that the EPDP consider other factors on this “permitted vs. required” distinction, such as: (a) the risk of fragmentation from a non-mandatory, permissive regime; and (b) whether existing examples where registries and registrars are already making similar kinds of differentiations may shed any light on the feasibility of how to do so at scale. That said, for the reasons outlined below, INTA does not necessarily agree with the premise of this question that the differentiation that Contracted Parties should be required (not merely permitted) to make will always necessarily be “on a geographic basis”. As the Initial Report notes, the actual location of the registrant is not always dispositive as to whether GDPR applies. Fortunately, the EDPB has recently issued Guidelines on this exact question – the territorial scope of the GDPR – that are illustrative in this regard.[5] For that reason, INTA also respectfully suggests that the EPDP consider (c) the recent guidance on the territorial scope of the GDPR from the EDPB.	a) Fragmentation. As noted in Section (e) of the EPDP Initiation Request, fragmentation of the WHOIS system is a policy outcome to be avoided – at least in part because it could jeopardize the security and stability of the Internet. INTA agrees with this. And so too, apparently, do those members of the EPDP (specifically, the Contracted Parties and the NCSG) who oppose requiring differentiation between registrants consistent with the territorial scope of the GDPR. As they have argued in the Initial Report: “Not having a common approach for all registrants could lead to two classes of registrants, which may result in competitive advantages to certain registrars/registries (due to their establishment in jurisdictions with privacy protection), fragmentation in the marketplace and interoperability issues.” See: Initial Report at 48. In that sense, INTA and the Contracted Parties/NCSG appear to agree on the overarching policy objective – that “RDS policies should be as unified as possible”, and that fragmentation is problematic. They just disagree on how to get there – specifically, on whether a “permissive” or “mandatory” policy is most likely to do so. On that specific disagreement, INTA does not understand how permitting but not requiring differentiation is somehow going to result in less (not more) fragmentation. The whole point of a “permissive” regime (as opposed to a mandatory one) is to allow each Contracted Party to make decisions as to differentiations on their own. The Contracted Parties/NCSG admit as much when they state: There are significant liability implications for Contracted Parties if they are incorrect in applying the appropriate data protection rules. Contracted parties should be free to choose whether or not to take that risk as a business decision rather than a contractual requirement. Whatever the merits of that argument on its own terms, it is clearly contrary to the reasoning of the EPDP Initiation Request, which cautioned against an outcome in which “each registry operator and registrar might make their own determination regarding what gTLD registration data should be collected, transferred and published, leading to a fragmentation of the globally distributed WHOIS system and the handling of gTLD registration data.” (emphasis added). Obviously, different Contracted Parties are going to have different risk tolerances – and thus are going to answer this question, and others, differently. The whole point of a consensus policy is to avoid that kind of fragmented decision-making. INTA does not understand – and the Initial Report does not make clear – why this differentiation question is somehow special, such that it would warrant an exception to the general preference that RDS policies be as unified as possible. b) Existing examples. Unlike Question 90 below, which asks for “existing examples where a legal/natural differentiation is already made”, for some reason the questions from the EPDP do not ask for existing examples where differentiations based on geography are already made. In that sense, the questions from the EPDP appear to take at face value (or at least, do not solicit any input from public comments that may be contrary to) the claims from the Contracted Parties/NCSG that: 1) “It is often difficult to identify a registrant’s applicable jurisdiction with sufficient certainty to apply appropriate data protection rules”; and 2) that “Any consensus policy needs to be commercially reasonable and implementable, and in the current market place, differentiation based on geographic location will be difficult to scale, costly, and, accordingly, neither commercially reasonable nor implementable.”[4] It is unfortunate that the EPDP did not ask for any input testing or challenging those assumptions – because the claim that geographic differentiation is somehow commercially unreasonable is inconsistent with numerous examples from the current marketplace that specifically differentiate between registrants on a geographic basis. Most obviously, various ccTLDs restrict registration to registrants with a nexus to a particular geographic region. (See, e.g., https://eurid.eu/d/205796/Registration_Policy_EN.PDF (outlining eligibility criteria for the .eu ccTLD); https://www.about.us/policies/ustld-nexus-requirements (outlining the United States nexus requirement for the .us ccTLD); https://cira.ca/sites/default/files/public/policy/cprregistrants-en.pdf (outlining the Canadian presence requirements for the .ca ccTLD). Likewise, various “geographic” gTLDs also restrict registration to registrants with a nexus to a particular geographic region. (See, e.g., https://www.ownit.nyc/policies/nyc-nexus-policy (“Registrants in .nyc must be either: a natural person whose primary place of domicile is a valid physical address in the City of New York . . . ; or an entity or organization that has a physical street address in the City of New York . . . .”).) In addition, it appears that at least some registrars (such as GoDaddy) are already making geographic differentiations for purposes of providing various privacy-related account-management services to their customers. (https://www.godaddy.com/help/edit-my-privacy-options-for-european-economic-area-residents-27893 (noting that the process and information provided applies only to EEA residents); https://www.godaddy.com/help/download-my-data-for-european-economic-area-residents-27892) These examples belie the claim that differentiation based on geography is neither commercially reasonable nor implementable. At the least, they suggest that the EPDP should consider as an additional factor how the registries and registrars that are already making such differentiations have been able to do so. c) EDPB Guidelines. For the foregoing reasons, INTA sees no credible argument that differentiation should be permitted but not required (at least if uniformity is to be preferred over fragmentation). But INTA does agree with the point raised in the Initial Report that the actual location of the registrant may not always be dispositive as to whether the GDPR will apply. Fortunately, the EDPB has recently issued helpful Guidelines on that exact question – the territorial scope of the GDPR. INTA will not attempt in this Comment to exhaustively summarize those Guidelines. But in general terms, they do support a potential Consensus Policy that would require Contracted Parties to, for example, only redact gTLD registration data when: 1) the Contracted Party is collecting such data within the context of the activities of “an establishment in the EU” (as that term is defined in the EDPB Guidelines); or 2) when the Contracted Party is “targeting” domain-name registration services to individuals in the EU (as that term is also defined in the EDPB Guidelines). At a minimum, INTA suggests that the EPDP consider the recent EDPB Guidelines as an additional factor on this issue.	The question assumes the conclusion – that there are some risks associated with differentiation. And it does not ask the converse question: whether there are any risks associated with not requiring (but merely permitting) differentiation – such as the substantial risk of fragmentation that will result if each Contracted Party is permitted to make its own determination on the basis of its own unique risk tolerance.	Considering the risk of fragmentation from a permissive regime and existing examples where a legal/natural differentiation is already made, INTA is of the view that this distinction is necessary and practicably achievable. The solution that the Contracted Parties/NCSG have proposed (namely, that differentiation between natural and legal persons should be permitted, but not required) appears to suit the conveniences of those parties, but is an incongruous means of addressing the purported risk of possible inadvertent disclosure of personal data relating to natural persons who work for or represent a legal person – such as natural persons who manage administrative or technical issues on behalf of a legal person registrant. The EPDP should not ignore that if policy makers and legislators had intended the GDPR to cover a broader group of data subjects, they would have specifically said so. While implementation may be a challenge, ICANN should not through its policies effectively extend the reach of the GDPR to an entirely separate class of data subject.	a) Fragmentation INTA has provided its rationale as to “fragmentation” in its Response to the question above. b) Existing examples INTA has provided its rationale as to “existing examples” in its Response to the question above and has provided existing examples for the “legal vs. natural person” distinction in its Response to the question below. c) Fit INTA agrees with the Initial Report that there may be some risk that stems from the fact that natural persons employed by a legal person (and who may be designated as the registrant, admin, or technical contact for that legal person) still enjoy rights and protections under the GDPR – even if their employer does not.[1] INTA is concerned that the Initial Report does not explain why the EPDP thinks the best way to address that risk is to permit Contracted Parties to make their own determination as to whether (and how) to differentiate between legal and natural persons. INTA respectfully suggests that a permissive regime would more likely exacerbate that risk (given the lack of uniformity for registrants across different Contracted Parties) than ameliorate it. INTA supports the alternative proposal referenced in the Initial Report namely, that the risk of inadvertent disclosure “may be minimized through clear explanatory language beneath each field when filling in data fields within domain name registrations”. This solution is far more likely to address the potential risk identified. INTA does not share the concern that such explanatory language may be somehow inconsistent with the concept of “privacy by design.” This solution seems tailored for privacy by design. It stands to reason that a policy that leaves the decision of how to handle the legal vs. natural person distinction to each Contracted Party to implement different safeguards on their own will be riddled with inconsistencies. On the other hand, a policy that implements, by design, a consistent explanatory language beneath each data field minimizes the risk of inadvertent disclosure for all registrants across all registries and registrars. Registrants are, therefore, offered informed choice rather than arbitrary decision making by a third party. This outcome is consistent of GDPR principles that keep control of the data with the data subject.	INTA would welcome further study on procedures that could improve the means to distinguish between different registrants for the purposes of more accurately and precisely applying the GDPR. However, INTA would also wish to note that the Guidelines on the territorial scope of the GDPR that were recently issued by the EDPB shed a great deal more light on what factors need to be taken into account, and should be considered along with additional data about how the registries and registrars that are already making these types of differentiations (namely, geographic differentiations; or legal person vs. natural person differentiations) have already been able to do so.	Yes. The registry that operates the .TEL gTLD makes this differentiation. So does the .eu ccTLD. See https://www.do.tel/wp-content/uploads/2017/05/Whois_Policy.pdf (“With respect to the amount and type of domain name registrant data provided in response to queries of the WHOIS service by the general public, the WHOIS service will distinguish between domain name registrants that are companies, businesses, partnerships, non-profit entities, associations, or other types of legal constructs (‘Legal Persons’), and domain name registrants that are human beings, perceptible through the senses and subject to physical laws (‘Natural Persons’). Domain name registrants will be required to specify whether they qualify as Legal Persons or Natural Persons by clicking the appropriate box during the registration process.”). See also https://eurid.eu/d/205797/whois_policy_en.pdf.	Support intent of recommendation with edits	INTA recommends that the clause: “Furthermore, the EPDP Team recommends that criteria around the term “reasonable” are further explored as part of the implementation of these policy recommendations addressing:” Be amended to read: “Furthermore, the EPDP Team recommends that definitions, criteria and processes around the term “reasonable access” will be determined as part of the final policy including how to address:”	Third parties that currently have a legitimate interest and lawful purpose for gaining access to non-public registrant data face a confusing array of different registrar and registry requirements and processes to access this data making such access extremely difficult, inefficient and, in many cases, non-existent. Third parties that currently have a legitimate interest and lawful purpose for gaining access to non-public registrant data face a confusing array of different Registrar and Registry requirements and processes to access this data making such access extremely difficult, inefficient and, in many cases, non-existent. INTA members, through responses submitted to INTA’s WHOISchallenges.org mailbox, report that ICANN’s implementation of the Temporary Specification has adversely affected access and usage of domain name registration information and the ability to address infringing activity and to mitigate abuse. With only a small percentage of Registrars returning complete WHOIS records, the impact felt by the absence of Registrant data is pervasive. Data recently published by MarkMonitor, an INTA member, revealed that nearly 80% of the requests for registrant data made to Registrars have been either ignored or denied. While the EPDP Team works on a future policy regarding standardized access as referenced in Recommendation #2, the EPDP Team should now also define and develop simple processes around “reasonable access” and make sure that implementation details of these processes are completed within this EPDP and not delayed until future discussions regarding implementation.							No, I wish to continue to the next section
36	12/21/2018 16:53:33	Wolf-Ulrich Knoben	GNSO, ISPCP Constituency	Yes	GNSO, ISPCP Constituency	No, I would like to continue to the next section	Support Purpose as written			Purpose should be deleted		At the time of the preparation of the report the question of access to data has neither been fully discussed nor has the lawfulness of responses to disclosure requests been assessed exhaustively. It is difficult to assess the lawfulness of such purpose in the absence of knowing the parameters for disclosure, should any such recommendations be made. Additionally, even without the definition of a related purpose, information may be provided to respond to lawful disclosure requests, such as requests from competent law enforcement authorities. As a consequence, no definition of a purpose needs to be defined for these cases. It is questionable whether data may lawfully be kept to enable those holding the data to disclose it to third party beyond such cases. Therefore, a purpose relating to disclosure of data to third parties may be unlawful and it should only be included in the final report conditional to affirmative confirmation by either a competent authority or legal counsel.	Support Purpose intent with wording change	ENABLE COMMUNICATION WITH AND/OR NOTIFICATION TO THE REGISTERED NAME HOLDER FOR MATTERS RELATING TO THE DOMAIN NAME AND / OR ITS FUNCTIONALITY.	Where the registered name holder is permitted to designate agents, any correspondence with such agents is in fact communication with the registered name holder. Thus, the additional language is at best redundant, if not misleading as it might be construed as a justification to install or maintain the roles of the technical or administrative contact although the current practice of collecting and otherwise processing the respective data for these contacts is not part of the preliminary recommendations of the EPDP team. The additional clarification on the type of communication shall further specify the purpose to ensure that contactability shall not need to be facilitated by contracted parties to e.g. serve as a communications channel with customers of the registered name holder on support queries.	Support Purpose as written		We support the purpose as written. The legal basis for the processing shall, however, be determined as being Art. 6 I f GDPR as it is not related to performing the contract with the registered name holder.	Support Purpose intent with wording change	HANDLE CONTRACTUAL COMPLIANCE MONITORING REQUESTS, AUDITS, AND COMPLAINTS SUBMITTED BY REGISTRY OPERATORS, REGISTRARS, REGISTERED NAME HOLDERS, AND OTHER INTERNET USERS AS DEPICTED IN THE ATTACHED RECORD OR PROCESSING ACTIVITIES. (The document would actually need to be added to the recommendation)	There is no full understanding as to how ICANN exactly handles compliance matters. A record or processing activities to help understand what data is needed to perform the tasks, how it is handled and how long it is retained by ICANN has not been provided. Therefore, it is difficult to support a purpose relating to activities that are not fully transparent to the community. Whilst we support the essence of the purpose, our support is conditional to processing activities that are clearly and exhaustively depicted in a corresponding record. Also, it shall be limited to such processing of personal data that is needed, and not only desirable to have, to perform the tasks. The legal basis for this processing shall be clarified as being Art. 6 I f GDPR.	Support Purpose intent with wording change	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.	Future policies must not be covered by or referenced to in the language of the purpose for a lack of specificity. When new policies are created, these might need to be covered by additional purposes to be added to the documentation.	Support Purpose as written				There are no additional purposes we would like to suggest. Our comment relates to the purposes as defined in this document. We regard it as necessary to test the language of the purposes against the overall package of recommendations that the EPDP will come up with to ensure that all recommended processing activities are adequately reflected in a purpose that passes the test of GDPR requirements. Also, it shall be noted and made explicitly clear in the final report that the purposes and related processing activities only cover those areas that shall be governed by ICANN’s policies and thus be made part of ICANN’s contracts and be enforced accordingly. However, there may be additional purposes pursued by contracted parties and ICANN that are out of scope of this EPDP or ICANN’s governance. Nothing in the EPDP’s findings shall prevent the contracted parties or ICANN from conducting additional processing activities, which certainly must be compliant with applicable laws.		No, I wish to continue to the next section	Delete recommendation	The recommendation shall only be supported conditional to confirmation that such processing is possible in a legally compliant fashion. One way of doing this is to recommend the preparation of a code of conduct according to Art. 40 of the GDPR and enact the recommendation only if and when such code of conduct is approved.			Support recommendation as written			The recommendation shall be kept as it is. No additional requirements to verify the accuracy of data given by the data subject or to validate such data shall be part of any recommendation of the EPDP team. Whilst contracted parties shall ensure that data is accurately recorded in their system as provided by the data subjects, any additional requirements are neither warranted by GDPR nor in scope of the EPDP.	No, I wish to continue to the next section	Yes			No additional elements shall be collected.		Optional	The collection of data on the tech-c must be optional as it is not needed to perform the contract with the data subject. As a consequence, the processing requires consent. Any recommendations relating to the role of the tech-c must ensure that all legal requirements for consent-based processing are followed and, where the data is not collected from the data subject, Art. 14 of the GDPR needs to be complied with.	No	There are technical and legal challenges with consent-based processing. These are likely out of scope for this EPDP to resolve. Therefore, the offering should be optional until such time when an industry-wide approach has been agreed upon.	Yes	These data elements are not needed in practice. The role of the admin-c is not different than the role of the registered name holder. The billing contact is not used for billing purposes as the account holder is invoiced. Thus, according to the principle of data minimization, both roles shall not be maintained further and no relating data shall be collected.		Yes		The transfer of data from registrar to registry can only take place based on different purposes and different legal grounds. Where the processing is based on Art. 6 I b GDPR to perform the contract, it can unconditionally be transferred. Where the processing takes place based on Art. 6 I f GDPR, it can only take place if the registry actually asserts to have a legitimate interest in such processing. Absent the assertion of such interest, no data shall be transferred based on Art. 6 I f GDPR.		Support recommendation as written				Support recommendation as written	Yes		The support is conditional to a record of processing activities that shall be provided by ICANN org and be exhaustive.		Yes	N/A		Yes	There is consensus that the registrant field shall be redacted. As the registrant field is populated with the same data as the organization field, it is only straightforward also to redact the organization field. This issue is closely linked to the distinction of natural and legal persons. If and when a compliant way to make a distinction between natural and legal persons can be found, the organization field can be published where no personal data is revealed. However, such mechanism does not exist (yet).		Delete recommendation	Whilst it might be desirable for the registrar to provide information to the registered name holder, it does not seem likely that the provision of educational material will ensure compliant handling of the organization information. Hence, a solution to allow for the compliant treatment of organization data needs to be found, one component of which may or may not be the provision of educational material. This, again, relates to the distinction between natural and legal persons. If a solution for that issue is found, the question on the publication of the organization field can be answered easily.			Support intent of recommendation with edits	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. The preferred option is the offering of web form.	The reason for spelling out the web form as a preferred option is that e-mail addresses as a communications channel might lead to disclosure of personal data if, e.g. an auto responder is deployed by the registered name holder.	The requirement for offering a communications channel shall be designed to follow a “relay & delete” approach. Contracted parties shall not be obliged to ensure or record delivery of communication or otherwise commit to service level agreements.	Support recommendation as written		We support the fact that a retention period is now substantiated with policy requirements, namely the TDRP. It shall be clarified, however, that data retained for that purpose may only be used for that purpose and not for other purposes. The purpose would cover escrowing data as that is also to ensure the legal position of the registered name holder according to the TDRP can be secured.		We support the reasons spelled out in the initial report in favour of a uniform approach globally.			Contracted parties should not be required to make the distinction between natural and legal persons as legal persons’ data can include personal data, which constitutes compliance risks. If and when there is a sufficient level of certainty that different treatment based on the self-identification by the registered name holder is a practice that will not be sanctioned by the authorities, a distinction can be considered. A sufficient level of certainty could be established with an affirmative statement by competent authorities, the EDPB or a code of conduct according to Art. 40 GDPR.		No. A study will not help resolve the compliance questions.			No comment on such recommendation can be made until the EPDP team had a full discussion of the matter.			Support recommendation as written		We support the rationale offered in the initial report. There has been criticism of the joint controller approach, but more based on concerns regarding the implementation. To date, no other concept has been proposed with a sufficient level of detail to even assess the legality. Absent a sound alternative proposal, the joint controller approach shall be pursued. The parties at risk of being sanctioned as well as the wider community should bear in mind that not having the arrangements / agreements in place or having agreements in place that do not provide adequate rights to the data subjects poses significant risks on contracted parties. Implementing a joint controller setup does not seem to have any of the two above risks. If and when competent authorities constitute that fewer or other requirements are sufficient, the concept can be changed, but for the time being, the community should ensure that there will be no compliance risks that could not only put contracted parties but also ICANN at stake.			No, I wish to continue to the next section
37	12/21/2018 16:54:38	Renee Fossen	Forum - URS and UDRP Provider	No		No, I would like to continue to the next section																									No, I wish to continue to the next section									No, I wish to continue to the next section																																																												No, I wish to continue to the next section
38	12/21/2018 17:26:36	Ayden Férdeline	Non-Commercial Stakeholders Group	Yes	Non-Commercial Stakeholders Group	No, I would like to continue to the next section	Support Purpose as written		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 should be deleted		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	Support Purpose as written		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.	Support Purpose as written		It is legitimate to collect and process data for this purpose, as it supports the rights and interests of the registrant.	Support Purpose as written		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.	Support Purpose intent with wording change	The NCSG requests that the first sentence of Purpose 6 be streamlined by replacing “coordinate, operationalize, and facilitate” with “operationalize”.	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 should be deleted	The NCSG believes this purpose should be deleted in its entirety. Editing should not be considered.	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.		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.		No, I wish to continue to the next section	Support intent of recommendation with edits	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.”	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.		Support recommendation as written		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.		No, I wish to continue to the next section	No	The NCSG opposes the inclusion of “Additional optional data elements as identified by Registry Operator in its registration policy.”	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.			Optional	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.	No	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.	Yes	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.		Yes		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.		Support recommendation as written		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.		Support recommendation as written	No	See below	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.		Yes	The NCSG requests the redaction of an additional data element: the State/Province field.	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.	Yes	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.		Delete recommendation		“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.		Support recommendation as written			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.	Support recommendation as written		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.		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.			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.	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@domain.TLD.	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.	There are no directly applicable examples that would work at a global scale.	Intent and wording of this recommendation requires amendment	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.	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.	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.	Support recommendation as written		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.			No, I wish to continue to the next section
39	12/21/2018 18:08:45	Sajda Ouachtouki	The Walt Disney Company	No		No, I would like to continue to the next section	Support Purpose as written			Support Purpose intent with wording change	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 -- including law enforcement, security, intellectual property, and consumer protection needs -- to data elements collected for the other purposes identified herein.	Maintaining the stable and secure operation of the Internet’s unique identifier systems requires that ICANN ensure access to domain registration data for law enforcement, cybersecurity, consumer protection, and intellectual property protection. Given the important role that access to domain registration data for these purposes plays in practice in the efforts to maintain security, stability and resilience of the domain name system, it is critical that these purposes are clearly identified from the outset. Disney’s own experiences have tracked those reported in the multiple studies (SSAC in SAC 101, Anti-Phishing Working Group, Cybersecurity Tech Accord) submitted to this process, documenting that the current access provided today is inadequate – contracted parties are often either slow to respond to legitimate requests or do not respond at all.	Support Purpose intent with wording change	Enable communication with and/or notification to the registered name holder and/or their delegated agents of technical, legal, and/or administrative issues with a registered name.	This change will clarify that legal issues involving a domain name also have a channel for communication to the registered name holder or agent.	Support Purpose as written			Support Purpose as written			Support Purpose intent with wording change	Coordinate, operationalize, and facilitate policies for resolution of disputes regarding or relating to domain names, namely, the UDRP, URS, PDDRP, RRDRP, and future developed domain name registration-related dispute procedures in accordance with ICANN’s Bylaws for which it is established that the processing of personal data is necessary.	The language of the recommendation should be changed because it is directly in conflict with the provisions of the UDRP and URS policies themselves, is inconsistent with ICANN’s bylaws, and perpetuates an artificial distinction between the act of registration and the use of a domain name in the context of ICANN’s general remit. ICANN’s bylaws clearly encompass the use of domain names with respect to dispute resolution by expressly including it “where such policies take into account use of domain names” (Section1.1(a)(i)), and it should be included here as well.								Support intent of recommendation with edits	Yes, we recommend the final line in Recommendation #2 be edited to read: “In this context, amongst others, the ePDP Team will develop a policy that prescribes the method for disclosing non-public registrant data to third parties that have established legitimate interest in viewing registrant data, such as intellectual property rights holders, cybersecurity firms, organizations that mitigate DNS abuse, and law enforcement agencies.”	This change will ensure that the policy developed by the EPDP meets the needs of all the stakeholders whose actions the successful maintenance of the stability, security and resiliency of DNS system rely. Failure to provide adequate access for all the stakeholders who have a role in preserving the stability, security and resilience, including intellectual property rightsholders, cybersecurity firms and other organizations that mitigate DNS abuse as well as law enforcement agencies runs the risk of undermining that security and furthering distrust of the Internet ecosystem. It would also be contrary to the longstanding purposes of the WHOIS system, which have always included these parties as evidenced in the earliest protocol for a directory service published in 1982 by the Internet Engineering Task Force that included contact information of anyone transmitting data across the ARPANET in order to “serve the needs of different stakeholders such as domain name registrants, law enforcement agents, intellectual property and trademark owners, businesses and individual users.” (History of WHOIS, ICANN WHOIS, https://whois.icann.org/en/history-whois). Moreover, providing reasonable access to all relevant stakeholders is clearly the expectation set by the European Data Protection Board in its May 27 communication to ICANN -- (ICANN is “to develop and implement a WHOIS model which will enable legitimate uses by relevant stakeholders, such as law enforcement, of personal data concerning registrants in compliance with the GDPR, without leading to an unlimited publication of those data”).		Support intent of recommendation with edits	Recommendation 3 should be edited to read: The EPDP Team recommends that requirements related to the accuracy of registration data under the current ICANN contracts be incorporated into this policy.	Accuracy is both fully within scope of the EPDP and specifically addressed by the GDPR – thus, ICANN and contracted parties should proactively address how they will ensure the accuracy of data from the beginning and not only how they will rectify inaccurate data brought to their attention after collection.		No, I wish to continue to the next section	Yes			Registrars should be required to provide an option for registered name holders to indicate that they are either a Legal or Natural person.	The distinction between Legal and Natural persons made in the GDPR can effectively be made for the purposes of these WHOIS related policies by allowing registered name holders to indicate which applies to them.																					No	Registrant email and city should not be redacted.	City of residence is not sensitive personal information and is needed in order to serve legal processes effectively, identify proper venue for litigation and understand which controlling law and procedure applies. Additionally, email addresses are critical data points for combatting illicit activity, consumer protection, public safety or any DNS abuse. Email addresses are a necessary data point for both notifying a potential victim as well as alleged perpetrator without necessarily identifying the domain name holder. Registrants have the ability to register a domain name with an unidentifiable email address and also have the option to use a privacy or proxy service when registering the domain name.	No	The GDPR applies only to information about Natural persons, not Legal persons. Legal entity registrants such as corporations should not have any WHOIS data redacted.														The new policy should differentiate between registrants for which GDPR applies and registrants outside the jurisdictional reach of GDPR. There should be no redaction of data collected outside the E.U. in the provision of non-E.U. services. The Guidelines issued by the EDPB on November 16, 2018 should be used in determining how best to implement a differentiation between registrants on a geographic basis for the purposes of compliance with the GDPR. Proposals should be reevaluated and further justified in light of the Guidelines, which suggest that it would be possible to agree that redactions to the data of registrants for these purposes should only be applied where: (a) the contracted party is collecting such data within the context of an establishment of the contracted party in an EU member state, or (b) the contracted party is targeting domain registration services to EU data subjects. The EPDP Team should seek to develop practical measures based on these Guidelines.	It is not necessary to universally apply the geographically limited GDPR, particularly when practical measures exist to implement the law consistent with its jurisdictional limits. ICANN should be primarily concerned with the objectives set forth in its mission, which has from the inception of the WHOIS framework included the practice of collecting and displaying the information of domain registrants for the purposes of ensuring the security and stability and resiliency of the DNS. To the extent exceptions are required to accommodate national laws, ICANN has policy in place to deal with the conflict - the WHOIS Conflicts Policy. The purpose of the EPDP process is to determine how to accommodate current practices to be compliant with the GDPR. The purpose is not to globalize the application of the GDPR, which would also raise the risk that some countries may seek to enact counterbalancing rules or laws to oblige disclosure of registrant data for what it considers to be legitimate purposes, leading to a more fractured and complex compliance landscape.		The team should revisit Recital 14 of the GDPR, which states: Protection afforded by this Regulation should apply to Natural persons, whatever their nationality or place of residence, in relation to the processing of their personal data. This Regulation does not cover the processing of personal data, which concerns Legal persons and in particular undertakings established as Legal persons, including the name and the form of the Legal person and the contact details of the Legal person.	Registrars should distinguish between Natural and Legal persons when accepting registrant data for a domain name registration. Legal person data should not be treated as a Natural person’s data since the GDPR does not apply.			Support intent of recommendation with edits	We recommend that the clause: “Furthermore, the EPDP Team recommends that criteria around the term “reasonable” are further explored as part of the implementation of these policy recommendations addressing:” Be amended to read: “Furthermore, the EPDP Team recommends that definitions, criteria, and processes around the term “reasonable access” will be determined as part of the final policy including how to address:”	Third parties that have a legitimate interest and lawful purpose for requesting disclosure of non-public registrant data face a confusing array of different registrar and registry requirements and processes, making access extremely difficult, inefficient and, in many cases, non-existent. The Walt Disney Company itself has faced challenges when making requests for registrant data to registrars. Since the GDPR went into effect, The Walt Disney Company has experienced a number of delays and denials to data requests that were crucial for addressing a number of intellectual property infringements. For example, in June 2018, The Walt Disney Company made a registrant contact information request to a registrar due to a trademark infringement. The request was not fulfilled and The Walt Disney Company was told that it needed a subpoena to receive the information. The Walt Disney Company’s experience is in line with the discoveries of a number of recent studies. For example, according to a survey conducted by INTA, the redaction of registrant data has made enforcement of intellectual property rights more difficult. Additionally, MarkMonitor recently published data revealing that nearly 80% of the requests for registrant data made to registrars have been either ignored or denied. While the EPDP Team works on a future policy regarding standardized access, it should also work on defining and developing simple processes around “reasonable access.”							No, I wish to continue to the next section
40	12/21/2018 18:20:14	Farzaneh Badii	Internet Governance Project	Yes	Internet Governance Project at Georgia Institute of Technology	No, I would like to continue to the next section	Support Purpose as written			Purpose should be deleted		Disclosure of personal information to the third party is not an ICANN purpose - ICANN does not process domain name registrants data to disclose it later. The only clause in which disclosure might be interpreted as in ICANN's mission and scope is elaborated in section 1.1 and G1 and G2. It reads as: "ICANN's scope is to coordinate the development and implementation of policies: - [...] with respect to gTLD registrars and registries, policies in the areas described in Annex G-1 and G-2 ;[....][for example] maintenance of and access to accurate and up-to-date information concerning registered names and name server." Nowhere in the bylaws ICANN directly is in charge of providing access nor facilitating access to registrants data. It is only in charge of developing consensus based, uniform and global policies and implementing them. Moreover, security stability and resiliency can only be interpreted in technical terms and in line with ICANN's narrow and technical mission. It cannot move beyond the narrow and technical definition and include non-technical interest such as protection of trademark.	Support Purpose as written		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.	Support Purpose as written			Significant change required: changing intent and wording	ICANN purpose for processing domain name registrants should be specific. This purpose is very broad and open to interpretation. Current compliance needs to process the data for compliance purposes should be identified and specifically mentioned. the whole purpose has to be re-written and justified by ICANN current compliance practices. More specifically, the purpose has to better use this document: https://mm.icann.org/pipermail/gnso-epdp-team/2018-November/000944.html in its wording. ICANN should also commit to developing and implementing policies that respect data minimization principles.		Significant change required: changing intent and wording	Addition of PDDRP and PRDRP are unnecessary. access to personal information of domain name registrants is not needed for the complainant, refer to the ICANN complaint form: https://forms.icann.org/en/resources/compliance/rrdrp/form And refer to the PDDRP policy: https://newgtlds.icann.org/en/program-status/pddrp In case of ICANN compliance need to have access, then it can be justified as an ICANN compliance purpose. (and specifically mentioned). PDDRP and PRDRP are different from UDRP and URS. They are disputes resolution policies against registries and not the registrants. The disputes also are not about domain name registration about the operation of registries. If the registries require processing personal information of domain name registrants to settle these disputes, they should justify their need in a more specific manner by referencing to specific policy clauses and practices.		Purpose should be deleted		This will add to the data registration directory fields, against minimization principles and against data protection as well as opening the door to collection of and disclosure of more sensitive data elements as WHOIS.		No additional purposes are required.		Yes	Support intent of recommendation with edits	We would prefer to replace the term “Standardized Access to nonpublic Registration Data” with the term “Lawful disclosure of nonpublic registration data to third parties with legitimate interests.”	In essence, Recommendation 2 is simply a restatement of one aspect of the EPDP’s charter. We note that later on in the report the wording change we propose here was accepted.		Delete recommendation		This recommendation is unnecessary; nothing in the temp spec or the current set of recommendations affects policies regarding accuracy in any way. While we understand that accuracy is important to specific stakeholder groups, and to the registrant, unreasonable fears about impact on existing accuracy policies should not be legitimized by a recommendation such as this.			No	We oppose the inclusion of “Additional optional data elements as identified by Registry Operator in its registration policy.”	As noted in our response to Purpose #7, we do not want the Whois data to be expanded to include a potentially unlimited number of new data elements reflecting individual policies of different registry operators.			Optional	The principal of data minimization requires that it be optional and not required. 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.	No	Some registrars feel that compliance with 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 demand for this field then registrars will offer it.	Yes	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.		Yes		Transfer of these data elements is appropriate and legal under GDPR		Support recommendation as written		Recommendation 6 is an appropriate measure to ensure that all data processing activities in which ICANN engages are compliant with data protection law		Support recommendation as written	No	See next answer.	We answer No here only because we believe that requests by ICANN compliance should be limited to those elements required to satisfy whatever issues they are dealing with at the time. In principle, this could mean that all data elements are required, but it may not need all elements for other purposes. We wish to underline the principle that compliance requests should not be open-ended fishing expeditions.		Yes	We support redaction of an additional data element: the State/Province field.	In nearly all cases, country level data will be sufficient to determine relevant jurisdiction for disputes. 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.	Yes	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 that are not doing anything illegal might be targeted because of their political, religious or social affiliations.		Delete recommendation		“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.		Support recommendation as written Support			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 GDPR. Recommendation 10 is a good way to optimize privacy while furthering the goal of contactability articulated by Purpose 3.	Support recommendation as written		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.		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 DNS. One of the main reasons for creating ICANN was to ensure that the DNS would have a globally consistent set of rules. We strongly oppose 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 DNS. This helps maintain the global compatibility of the Internet.			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. There is no need to consider additional factors.	We strongly oppose 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 to data protection and impose major cost burdens and risks on the contracted parties. Many registrants will not understand the distinction and will end up being misclassified as organizations and thus lose their data protection.	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 proceeding. Stakeholders who want to explore this further can initiate new PDPs after we have met the tight deadline for this EPDP. New policies can always be proposed. We simply do not have to the time to do so this time around.	There are no directly applicable examples that would work at global scale.	Support recommendation as written		We strongly support replacing “Standardized Access to Non¬Public Registration Data” with “parameters for responding to 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 spec, 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		Support recommendation as written		Understanding and specifying the roles and responsibilities of ICANN and the contracted parties, is a critical and unavoidable part of compliance with 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 JCA 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.
41	12/21/2018 18:51:57	Steve DelBianco	The ICANN Business Constituency	Yes	The ICANN Business Constituency	No, I would like to continue to the next section	Support Purpose as written			Support Purpose intent with wording change	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 -- including law enforcement, security, intellectual property, and consumer protection needs -- to data elements collected for the other purposes identified herein.	Purpose 2, as stated, is very general and non-specific. Legitimate third party interests are part of the fabric of security, stability and resiliency for the domain name system. Since the institution of the Temp Spec, the community has seen a degradation in its ability to investigate or address problems in the DNS -- a problem that can be remediated by access granted to these parties. It’s important to enumerate the types of third parties that are warranted access for previously identified legitimate purposes. Key findings of multiple studies have clearly demonstrated that lack of reasonable access is causing harm, and that contracted parties are either slow to respond to legitimate requests or do not respond at all: ● As noted by SSAC in SAC 101 (https://www.icann.org/en/system/files/files/sac-101-en.pdf), while legal obligations are a reality and must be complied with, access to registration data under the Temp Spec has been diminished far further than legal obligations require, and further than is prudent for responsible stewardship of the namespace. This point is more true under the EPDP’s proposals. The EPDP is obligated to consider the recommendations of SAC 101, and the requirements as listed by the GAC in its recent Communique’s related to WHOIS. To date, it has not. ● According to the Anti-Phishing Working Group’s study (https://apwg.org/apwg-news-center/icann-whois-access/temporySpecSurvey#_ftn1), cybercrime investigations have been seriously impeded, permitting harm to users, and Whois has become an unreliable or less meaningful source of threat intelligence. ● The Cybersecurity Tech Accord recently published its own study (https://cybertechaccord.org/mechanism_to_access_whois_data/), detailing the fact that partial data in public Whois following redaction is insufficient to investigate or respond to incidents, and that requests for access for legitimate purposes are routinely refused. Access for legitimate purposes is a pressing matter and increasing in urgency.	Support Purpose intent with wording change	ENABLE COMMUNICATION WITH AND/OR NOTIFICATION TO THE REGISTERED NAME HOLDER AND/OR THEIR DELEGATED AGENTS OF TECHNICAL, LEGAL, AND/OR ADMINISTRATIVE ISSUES WITH A REGISTERED NAME	Legal issues involving a domain name deserve a channel for communication to the registered name holder or agent; this is not enumerated in the current wording of the purpose, and particularly is not/should not be part of the “administrative” issues category. Legal communication can enable proper notice and/or due process in matters involving domain names, and those submitting such matters would benefit from specificity. The BC also recommends that the EPDP team further define “administrative” (a term that never has been fully defined in this context) as inclusive of matters such as rights infringement or resolution of claims of unlawful conduct. These clarifications will further assist third parties reporting contractual violations, who will be able to discern a “delegated agent” for administrative issues.	Support Purpose as written	The BC supports this purpose and we believe that registrars should be required to allow registered name holders to provide technical contact information, as some would so elect, to facilitate communication regarding technical issues.	The BC does not believe that collection of Technical Contact information should be mandatory. However, the OPTION to provide this information should be required since some registrants, particularly large corporate registrants, elect to provide this information in order to route appropriate communications within their organization. The EPDP team has pursued policy recommendations that, in many areas, guarantee registrant rights. The BC therefore advocates for the same in this instance: to preserve this registrant right, registrars should be required to offer the non-mandatory option.	Support Purpose as written		The BC supports the purpose as written, on the assumption that ICANN is performing contractual compliance monitoring and audits under its remit. This clarifies ICANN Compliance’s purpose for processing as detailed in the Summary of ICANN Org Contractual Compliance Data Processing Activities. (https://community.icann.org/display/EOTSFGRD/Input+from+ICANN+Org?preview=/90774122/97848455/Summary-Contractual-Compliance-Data-Processing-Activities.pdf)	Support Purpose intent with wording change	Coordinate, operationalize, and facilitate policies for resolution of disputes regarding or relating to domain names, namely, the UDRP, URS, PDDRP, RRDRP, and future developed domain name registration-related dispute procedures in accordance with ICANN’s Bylaws for which it is established that the processing of personal data is necessary.	The language of the recommendation is problematic as it perpetuates the artificial distinction between the act of registration and the use of a domain name in the context of ICANN’s general remit. It also is directly in conflict with the provisions of the UDRP and URS policies themselves. Further, the language of the recommendation as currently written is not a full and accurate quotation from the ICANN Bylaws, which state, in pertinent part: The topics, issues, policies, procedures and principles referenced in Section 1.1(a)(i) with respect to gTLD [registrars/registries] are:…”resolution of disputes regarding the registration of domain names (as opposed to the use of such domain names, but including where such policies take into account use of the domain names)…”	Support Purpose intent with wording change	Enabling registrars and registry operators to confirm that a registered name holder meets registration policy eligibility criteria required by the registry operator.	The language is sharpened here to reflect the fact that at the time data is processed, the registered name holder is required to meet the registration eligibility established by the registry operator. It is not voluntary on the part of the registrant.	The GDPR defines data controllers and data processors in Art. 4 as: (7) ‘controller’ means the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data; where the purposes and means of such processing are determined by Union or Member State law, the controller or the specific criteria for its nomination may be provided for by Union or Member State law; (8) ‘processor’ means a natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller; Under the Registrar Accreditation Agreement between registrars and ICANN, ICANN determines the purposes and means of the processing of personal data, in some instances for the purpose of WHOIS, by mandating data collection, transfer, storage, and display through minimum contractual terms that registrars maintain in contracts with Registered Name Holders (the data subjects). While there may be other terms in these contracts with Registered Name Holders aimed at allowing registrars to maintain a customer relationship (process payments in exchange for domain names), where ICANN determines the purposes and means of the processing of personal data for, things like WHOIS or escrow, ICANN is clearly a controller and the registrar a processor for the control. This does not exclude registrars as controllers of the same data where that data is collected for the registrar’s purposes (e.g., maintaining a customer relationship with the Registered Name Holders). Indeed, the eco (Association of the Internet Industry) GDPR Domain Industry Playbook V. 1.0 (https://www.eco.de/wp-content/uploads/2018/02/eco-domain-industry-playbook-v1.0-en.pdf) at page 61 notes that: "The main purpose of any data processing operation in connection with domain registration is the provision of the services associated with domain registration within the scope of the contractual relation. However, the activity of the enterprise participating in domain registration cannot be reduced to this singular purpose. Rather, the registration of domains is a service, which - jointly with the services of other companies - guarantees the overall functionality of the Internet (namely conveying content available in the World Wide Web). The special roles of registrar and registry within this technical ecosystem is also reflected e.g. in the fact that they are subject to certain duties as operators of critical infrastructures. The activity of registry and registrar - in this light - also serves other purposes beyond the mere domain registration for customers, in particular also with regard to the functionality of the technical infrastructure as such. Registrar and registry therefore also have to a certain extent a regulatory function, which for example may include participation in the prosecution of legal infringements committed under usage of this ecosystem. Against this background we would consider processing of data for the purpose of maintaining security measures or technical analysis (also operated by third party providers) as likely (depending on the individual case) being justified under Art. 6 (1) lit. f) GDPR." (emphasis added)	1. A new purpose to address the needs and benefits provided by DNS security and stability research conducted through publication of reports on threats to the operational stability, reliability, security, global interoperability, resilience, and openness of the DNS, and on the accuracy of WHOIS. 2. A new purpose to enable ICANN to conduct operations, facilitate activities, and implement consensus policies (adopted in accordance with the ICANN Bylaws) consistent with its mission of furthering the operational stability, reliability, global interoperability, resilience and openness of the DNS.	1. Research is a legitimate basis for processing, per GDPR Article 6(1)f, with specific safeguards defined in Article 89. It is also squarely within ICANN’s mission and mandate, as the requirement for research derives from Section 1.2a (Commitments) of the ICANN bylaws: (i) Preserve and enhance the administration of the DNS and the operational stability, reliability, security, global interoperability, resilience, and openness of the DNS and the Internet; (ii) Maintain the capacity and ability to coordinate the DNS at the overall level and work for the maintenance of a single, interoperable Internet; This purpose exists to ensure that ICANN may continue to use registration data in support of its mission, whilst maintaining the privacy of data subjects through appropriate safeguards such as pseudonymisation. In addition, this purpose enables ICANN to continue to operate its Accuracy Reporting System (ARS), which publishes periodic reports on accuracy, using full WHOIS contact fields. The ARS is an important program approved by the ICANN Board in response to the recommendations from the first WHOIS Review Team. 2. Prior to May 25, and consistent with its mission and mandate under the Bylaws, ICANN used full WHOIS data as part of operational security-related activities via the Office of the CTO -- this included collaborating with public/private sector investigators, training law enforcement agencies in techniques for mitigating cybersecurity threats (such as CONFICKER), and working with a compliance related complaint. ICANN also used WHOIS as it implemented consensus policies involving the use of WHOIS data fields (for example, transfer policy processes or Thick WHOIS). It is important that ICANN retain the ability to provide these services in order to fulfill its role in safeguarding the DNS.	No, I wish to continue to the next section	Support intent of recommendation with edits	The BC recommends that the final line of the recommendation should be edited to read: “In this context, amongst others, the ePDP Team will develop a policy that prescribes the method for disclosing non-public registrant data to third parties that have established legitimate interest in viewing registrant data, such as intellectual property rights holders, cybersecurity firms, organizations that mitigate DNS abuse, and law enforcement agencies.”	Now that the EPDP team’s gating questions have been sufficiently addressed, the BC strongly supports a recommendation that the EPDP Team contribute to ICANN Org’s development of a standardized, or “unified,” system for access to non-public registration data. Thus, the BC proposes edits to this recommendation to ensure that the protection of intellectual property and other rights are expressly recognized as a legitimate interest under GDPR and therefore understood to be within scope of the final policy. In the Article 29 Working Party’s letter to ICANN dated April 11, 2018 (https://www.icann.org/en/system/files/correspondence/jelinek-to-marby-11apr18-en.pdf), the A29WP “welcome[d] the decision of ICANN to propose an interim model which involves layered access, as well as an “accreditation program” for access to non-public WHOIS data.” This communication signaled A29WP’s support for a standardized access program. This support is further emphasized in a May 27 communication to ICANN (https://www.icann.org/en/system/files/files/statement-edpb-whois-27may18-en.pdf), in which the European Data Protection Board reiterated its expectation that ICANN is “to develop and implement a WHOIS model which will enable legitimate uses by relevant stakeholders, such as law enforcement, of personal data concerning registrants in compliance with the GDPR, without leading to an unlimited publication of those data.”		Support intent of recommendation with edits		According to Article 5 of the GDPR, personal data shall be "accurate and, where necessary, kept up to date; every reasonable step must be taken to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay." Within the GDPR, this is the second of three principles about data standards, along with data minimization and storage limitation that needs to be addressed. The ico. (Information Commissioner’s Office in the UK) points out in its Principle (d): Accuracy that one of the new features of GDPR as compared to the principles under its predecessor is that there is now a “clearer proactive obligation to take reasonable steps to delete or correct inaccurate personal data.” The ico. goes on to say that “The more important it is that the personal data is accurate, the greater the effort you should put into ensuring its accuracy. So if you are using the data to make decisions that may significantly affect the individual concerned or others, you need to put more effort into ensuring accuracy. This may mean you have to get independent confirmation that the data is accurate.” Accordingly, It is the position of the BC that the accuracy requirements that currently exist under the contracts must be at a minimum maintained. These should be expanded to improve accuracy levels in light of the requirements under GDPR for accuracy, and especially in light of the unacceptably low levels of accuracy as reflected in ICANN’s ARS reports. The EPDP’s work to align WHOIS with GDPR will be incomplete if it fails to recommend a policy to improve accuracy. The EPDP’s policy should address accuracy from the following perspectives: Collection: At intake, the EPDP should consider whether the current forms of validation are sufficient. In addition: ● The 2013 RAA contains requirements for cross-field validation that should be implemented as one component for demonstrating compliance with the GDPR. ● The EPDP policy should strive to improve accuracy consistent with GDPR, by revising the validation requirements specified under the RAA. For example, rather than having only one field in WHOIS validate (currently email OR phone number), the policy should consider requiring the validation of additional fields (as recommended by the EWG). ● The EPDP team should consider requiring additional forms of validation to examine accuracy of contact information from the perspective of syntactical and operational validity -- e.g., Syntax + Operability Accuracy methods (using the methodology of SSAC 058 found in the WHOIS Accuracy Reporting System (ARS). Please note that this is NOT a request to conduct validation of the Identity of the registrant. Maintenance: Once data is collected, Article 5 of the GDPR says that data must be kept up to date, which seemingly requires some sort of process that to be developed, documented, and put into place. The process should be used to: ● identify specific records that need to be erased or rectified without delay; ● flag and place registrar hold on domain name registrations identified as having false or incorrect data (pending correction from the Registered Name Holder); ● ensure a registrar doesn’t fall below certain statistical thresholds in terms of accuracy; and ● trigger an ICANN compliance inquiry where statistical thresholds for accuracy for any given registrar fall below certain levels. This should be considered for the registrars or registries that are well below the norm as reported by ICANN’s ARS. ICANN compliance should have the tools to require these registrars to submit and implement a rectification plan to improve its accuracy levels. Rectification: Article 5 of the GDPR says that ICANN and the contracted parties must ensure that personal data that are inaccurate … are erased or rectified without delay. Accordingly, a process should be developed, documented and put into place for a uniform method to report and rectify inaccurate data. This method should be published for the public, data subjects, and members of the community to have as a uniform method to report and rectify inaccurate data. In this regard, ICANN Compliance should be empowered to receive and act on complaints related to rectification of inaccurate WHOIS complaints, by creating a process specifically for this purpose.		No, I wish to continue to the next section	Yes		These data elements are required by ICANN to fulfill its mission and are in line with ICANN’s pursuit of a legitimate interest in this data, as well as the performance of the domain name registration contract, to which the data subject is party. Therefore, these data elements align to GDPR Article 6(1)b and 6(1)f.	Registrars should be required to provide the option for registered name holders to indicate whether they are Legal or Natural Persons.	GDPR does not apply to Legal Persons and, therefore, allowing registered name holders to indicate they are such Persons creates the opportunity and possibly the legal basis needed to publish the full Whois record or at least more fields therein. According to Recital 14 of the GDPR: The protection afforded by this Regulation should apply to natural persons, whatever their nationality or place of residence, in relation to the processing of their personal data. This Regulation does not cover the processing of personal data which concerns legal persons and in particular undertakings established as legal persons, including the name and the form of the legal person and the contact details of the legal person.	Optional	The EPDP team has pursued policy recommendations that, in many areas, guarantee registrant rights. The BC therefore advocates for the same in this instance: to preserve this registrant right, registrars should be required to offer the non-mandatory option. Further, should the registrant elect to enter this data, the registrar should be required to publish it.	Yes	As noted, some registrants elect to provide this data for a variety of reasons. Registrars should thus be required to offer the option to those who wish to exercise it. This is a prudent step in the EPDP’s various guarantees of registrant rights.	No	Registrants have always been afforded the ability to enter different points of contact for different needs regarding the performance of their contract with the Registrar. This should continue. Further, ICANN’s stated goal was, and is, to preserve Whois to the greatest extent possible -- presuming that to be the case, these fields should continue to be collected. Such a measure, as is the case elsewhere, is preservation of further registrant rights.		Yes		All data should be transferred to the registry, including data for the .com,.net and .jobs TLDs, the only remaining “thin” registries. Thick Whois Policy development concluded, several years ago, that we should transition data from thin to thick for the remaining thin registries. GDPR should not affect the agreed upon policy. Data transfer from registrar to registry can be completed in a manner that is compliant with GDPR.		Intent and wording of this recommendation requires amendment	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 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, along with the administrative contact, technical contact and any specialized data required by the registry and collected by the Registrar. (see Annex D, Workbook)	The BC recommends transferring all registration data collected by Registries and Registrars to data escrow providers. This would include all administrative and technical fields provided by the registrant and any “special data” required by Registries.		Intent and wording of this recommendation requires amendment	Yes		The BC agrees that all the data elements listed in Workbook 5 should be transferred from the registrar/registry to ICANN. We further recommend that all registrant data collected by registrar/registry be transferred to ICANN If a registrar/registry collects registrant data it should be transferred to ICANN to properly enable Compliance and other critical functions.		No	No. Registrant Email and City should not be redacted	Because time often is of the essence during security and law enforcement investigations, there must be an immediate method for contacting domain registrants that is more precise and affirmative than a web form or anonymous link. Unfortunately, experience with registrars following implementation of the Temp Spec (and further previous experience with Privacy/Proxy services) confirms that responsiveness to reveal requests is slow and unpredictable at best and entirely absent at worst. Email addresses, especially for Legal Persons, do not have to reveal personal data. The BC believes that, in order to serve the investigatory needs of law enforcement, security authorities and brand protection interests, registrars should, at a minimum, provide a uniquely hashed email string. In addition, the EPDP Charter (Part 1(f)) relates to publication of data. Registrars should give registrants the option to opt in to having their WHOIS Contact Data published rather than be redacted. The Temporary Specification 7.2.1/ Appendix C – Section 2.3 contains this requirement: As soon as commercially reasonable, Registrar MUST provide the opportunity for the Registered Name Holder to provide its Consent to publish the additional contact information outlined in Section 2.3 of Appendix A for the Registered Name Holder. Legal entity registrants such as corporations should not have any WHOIS data redacted. Natural person registrants may wish to display their information to ensure that their customers can confirm the authenticity of their website and prevent phishing and other impersonations. Domain owners may wish to be easily contactable in order to solicit interest in secondary market sales of their domain names. Enabling the consent feature is consistent with the accountability principles laid out in GDPR.	No	No. An Organization by definition refers to a Legal Person, and Legal Persons are exempt under GDPR and most other national privacy laws. No registrant data collected for a Legal Person should be redacted. The Registrant Organization field is included in the Temp Spec, as it should be, and it is the duty of parties to demonstrate that it should be redacted, not the reverse. (This was established in the email of Nov 19 in which ICANN responded to this very question by confirming the legal standing of Registrant Organizations under Article 6(1)(f).)		Support recommendation as written		The Business Constituency agrees with the language of this recommendation. Registrars should be required to inform registrants of the significance of providing an organization name and the fact that this information will be publicly displayed in a registrant data directory service.		Intent and wording of this recommendation requires amendment	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 and MUST provide the email address of registered name holders who are legal persons. The email address MUST be unique and uniform for each domain name registration attributed to a Registrant at a given Registrar. The email address MUST functionally forward communication received to the email address of the applicable contact and MUST describe the methods used to forward a communication and confirm its receipt. Registrar MAY implement commercially reasonable safeguards to prevent spam and other forms of abusive communications. It MUST NOT be feasible to extract or derive the email address of the contact from the email address provided to facilitate email communication with the relevant contact.	At minimum, the community must implement an effective and standardized method for replacing the email address with a pseudonymized email. Such a pseudonymized email would redact personally identifiable information by providing a unique, registrant-specific replacement address. This policy, in the context of the balancing exercise under 6(1)(f) GDPR, would grant reasonable latitude to legitimate third party interests and provide a reliable method of contact that would further allow for indexing such a contact to multiple domain names registered to the same person or entity. (Please refer to Opinion 06/2014 regarding the notion of legitimate interests of the data controller under Article 7 of Directive 95/46/EC of the Article 29 Working Party (now the European Data Protection Board), pp. 42-43.)		Support intent of recommendation with edits	The EPDP Team recommends that Registrars are required to retain the herein specified data elements for a period of three years following the life of the registration.	ICANN itself recommends a longer period of two years. Cybersecurity incidents have dwell time that can endure for years, as the recent Marriott/Starwood breach news proves. Attack indicators can be discovered long after the attack itself, and after DNS resources are deleted. Investigation timelines, particularly when it involves law enforcement, can be lengthy. It’s important that information about previously registered domains is retained for a useful period for security and law enforcement needs -- one year simply is insufficient. The consistent utilization, by security and LEA personnel, of historic data from various third party Whois services is testament to the need.		The new policy should differentiate between registrants for which GDPR applies and registrants outside the jurisdictional reach of GDPR. In addition, the EPDP should consider a policy recommendation to explore whether it is possible for ICANN to create a “rules engine” or dynamic chart that determines how the various privacy laws that exist or will exist in the future apply to WHOIS. Recognizing the complexity of this analysis, this policy recommendation could be implemented on a timeline different from other policies emerging from the EPDP. For example, based on the EDPB’s recent guidance, the dynamic chart could determine that the new WHOIS redactions implemented for GDPR apply to specific situations, such as where the contracted party is targeting domain registration services to the EU. Recently, the EPDP provided guidance on this issue in its Guidelines 3/2018 on the Territorial Scope of the GDPR. These Guidelines address the factors mentioned above and confirm that it should be feasible to distinguish between registrants on a geographic basis for the purposes of determining whether the GDPR should be applied. Redactions to the data of registrants for the purposes of compliance with the GDPR should be applied only where: (a) the contracted party is collecting such data within the context of an establishment of the contracted party in an EU member state, or (b) the contracted party is targeting domain registration services to EU data subjects.	The BC is concerned that the EPDP’s proposed policies significantly reduce the utility of WHOIS through the over-redaction of data due to interpretations that, in the end, are not applicable to GDPR. Making a geographic distinction is consistent with ICANN’s stated goal of preserving the WHOIS system to the greatest extent possible while complying with GDPR. ICANN (and its policies) should not serve as a means to achieve global application of a law that has limited territorial application. To do so adversely affects the ability of those that use WHOIS as a practical tool for easily resolving issues that protect consumers, mitigating security threats, and protecting its intellectual property without having resort to legal action.	ICANN risks the adoption of onerous regulations to counter the unnecessarily broad application of GDPR.	The team should revisit Recital 14 of the GDPR: Protection afforded by this Regulation should apply to natural persons, whatever their nationality or place of residence, in relation to the processing of their personal data. This Regulation does not cover the processing of personal data, which concerns legal persons and in particular undertakings established as legal persons, including the name and the form of the legal person and the contact details of the legal person. A registrar should distinguish between natural and legal persons when accepting registrant data for a domain name registration. Legal person data should not be treated as a natural person’s data since the GDPR does not apply.	As the BC has stated above, legal persons’ data should be publicly accessible. A registrar or registry should make the distinction between natural and legal persons in their processes and keep the data separate from natural persons’ data so as not to confuse the treatment of legal persons’ data.		Many ccTLD registries differentiate between natural and legal persons in the registration process. The extensive list below demonstrates that this differentiation is both practical and workable: .AT: Legal person data is publicly available in the whois and provides the organization, Street address, postal code, city, country, phone, email, and NIC handle. .BE: Legal person data is publicly available in Whois and provides the organization, language, street address, city, country and phone. A contact form is available. .CZ: Legal person data is publicly available in Whois and provides registrant organization, street address, city, country and NIC handle. It also provides the same data fields for admin and tech contacts. .DK: Natural and legal person data is treated identically in the publicly available whois and provides registrant organization, street address, city, country and nic-handle. (See .dk statement - https://www.dk-hostmaster.dk/en/gdpr) .ES: Legal person data is publicly available in Whois and provides registrant organization, admin contact name and name of technical contact. .EU: This ccTLD differentiates in the publicly available Whois record and provides the registrant name, language, city, country and email address. .FI: Legal person data is publicly available in the Whois and provides the registrant name, street address, city, country and phone. The technical contact’s name and email address are available. .FR: Legal person data is publicly available in Whois and provides the registrant organization, street address, city, country, phone and email address; the technical contact’s name, registrant org, street address, city, country, phone and email address; and the admin contact’s, name, registrant org, street address, city, country, phone and email address. .IE: Legal person data is publicly available in Whois and provides the registrant organization, admin and tech NIC handles. .IT: Legal person data is publicly available in Whois and the registrant organization, street address, city, country postal code, phone number and email address. The same data fields are available for admin and tech contacts and include individual names. .LT: Legal person data is publicly available in Whois and provides the registrant organization, street address, city, country postal code, phone number and email address. The same data fields are available for tech contact. .LV: This ccTLD distinguishes between natural and legal persons. Legal person data is publicly available in Whois and provides the registrant organization, street address, city, country postal code, phone number and email address. The same data fields are available for admin and tech contact and includes individual names. .LU: Legal person data is publicly available in Whois and provides the registrant organization, street address, city, country and postal code. The admin and tech contacts are masked. .MT: Legal person data is publicly available in Whois and provides the registrant organization, street address, city, country postal code, phone number and email address. The same data fields are available for admin and tech contact. .NL: Legal person data is publicly available in Whois and provides the registrant organization and admin email address. .PL: Legal person data is publicly available in Whois and provides the registrant organization, street address, city, country postal code. Organization is indicated in the record. .PT: Legal person data is publicly available in Whois and provides the registrant organization, street address, city, country and postal code. The same data fields are available for the managing body role. .SI: Legal person data is publicly available in Whois and provides the registrant organization, street address, city, country postal code, phone number and email address. The tech contact’s email address also is provided. .SE: Legal person data is publicly available in Whois and provides the registrant organization, street address, city, country postal code, phone number and Contact ID. The same data fields are available for admin and tech contacts and includes individual names.	Support intent of recommendation with edits	The Business Constituency recommends that the clause: “Furthermore, the EPDP Team recommends that criteria around the term “reasonable” are further explored as part of the implementation of these policy recommendations addressing:” be amended to read: “Furthermore, the EPDP Team recommends that definitions, criteria, and processes around the term “reasonable access” will be determined as part of the final policy including how to address:”	Third parties that currently have a legitimate interest and lawful purpose for requesting disclosure of non-public registrant data face a confusing array of different registrar and registry requirements and processes, making access extremely difficult, inefficient and, in many cases, non-existent. According to a survey conducted by INTA, the redaction of registrant data has made enforcement of intellectual property rights more difficult. Data recently published by MarkMonitor, a leading brand protection company, revealed that nearly 80% of the disclosure requests for registrant data made to registrars have been either ignored or denied. While the EPDP Team works on a future policy regarding standardized access as referenced in Recommendation #2, the EPDP Team should now also define and develop simple processes around “reasonable access” and make sure that implementation details of these processes are completed within this EPDP and not delayed until future discussions regarding implementation.		Support intent of recommendation with edits	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 either a Joint Controller Agreement or Controller-Processor agreement with the Contracted Parties.	The BC supports any controller/processor arrangement that will enable ICANN to assume sufficient legal responsibility such that ICANN can compel contracted parties to respond to Whois queries from accredited requestors, most likely as part of a Unified Access Model.			No, I wish to continue to the next section
42	12/21/2018 18:54:20	Tim Chen	DomainTools	Yes	on behalf of DomainTools	No, I would like to continue to the next section	Support Purpose as written			Support Purpose as written			Support Purpose as written			Support Purpose as written			Support Purpose as written			Support Purpose intent with wording change	COORDINATE, OPERATIONALIZE, AND FACILITATE POLICIES FOR RESOLUTION OF DISPUTES REGARDING OR RELATING TO THE REGISTRATION OF 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.	Given the remit of ICANN and the purpose of UDRP and related dispute resolution processes, inserting language specifically omitting the consideration of use is in opposition to those very things. Security and stability of DNS, as well as brand related abuses, by definition contemplate the use of the domain in some if not all cases.	Support Purpose as written				In support of cybersecurity research directly in line with ICANN's Mission to support the stable and secure operation of DNS.	GDPR Article 6(1)f supports research as a legitimate purpose. It needs to be highlighted that a vast network of global security researchers, acting independently, directly support DNS security efforts manifest at all levels including those of the individual, corporate, service-provider and nation-state. This is particularly evident in law enforcement work, which is one of the few arenas where such work is occasionally made public.	No, I wish to continue to the next section	Support intent of recommendation with edits	Prefer the final paragraph to read "In this context, amongst others, disclosure in the course of law enforcement, cybersecurity, DNS abuse, and intellectual property protection activity will be considered."	simply adding more detail and color by listing legitimate purposes which are specifically mentioned in the GDPR text (security and LEA)		Support recommendation as written				No, I wish to continue to the next section	Yes			ICANN should require a field for Registrants to indicate whether they are a Legal or Natural Person.	GDPR only protects Legal Persons. Collecting the Person-type data point will allow a more surgical application of relevant data protection laws. It should be noted that Legal Persons represent a significant number of global domain registrants and on average Legal Persons register multiple domains. The impact here is significant.	Optional	generally we should allow for separate contact info in other Contact roles, but not require it.	Yes	The necessary optionality is captured already. Requiring the presence of the data entry option protects the rights of registrants who prefer to indicate a technical contact. After all, contact for technical purposes is how Whois came about more than 25 years ago.	No	Much like the case for the option to enter Technical Contact data, the same argument holds here. It does not have to be mandatory, but registrants deserve the right to direct people to role-based contacts.		Yes				Delete recommendation	I would simply delete this entirely.	The EPDP already has agreed that all pre-Temp Spec registrant Whois data elements should continue to be collected. Escrow serves a purpose clearly in line with ICANN's Mission and also one in the best interest of the registrant. This data is not published so much like it can be collected, it can be stored securely. No changes are needed here.		Delete recommendation	Yes		ICANN itself is subject to GDPR, and its Compliance activities are worthy and in line with its Mission. No changes are needed here.		No	Registrant Organization. Email Address.	Registrant Organization: The Temp Spec does not redact this field. No arguments have yet been communicated that merit overriding the correct decision to publish a data field that is meant for Legal Persons. Email Address: The single most useful field for cybersecurity research and the resulting protection of the security and stability of DNS. There are ways to handle this data field that protect both its viability for this purpose and the privacy of the Natural Person registrants.	No	see above.		Support recommendation as written				Delete recommendation		Domain registrants deserve a way to be affirmatively contacted, and parties with a legitimate interest need a way to do the same. Any solution that uses the Registrar as a proxy is by definition not good enough.		Intent and wording of this recommendation requires amendment	should be at least the 2 years recommended by ICANN, preferably longer.	DomainTools knows how useful this data is and for how long, due to the actions of our security customers against our own historical Whois database. 1 year is not nearly long enough to support the legitimate interests outlined previously.					A domain registration for a Legal Person is an act of a Legal Person. Any data present in that registration is not subject to GDPR, including the business email of an employee.				Support recommendation as written									No, I wish to continue to the next section
43	12/21/2018 18:56:46	Sivasubramanian Muthusamy	Internet Society India Chennai	No	Commenting as an individual	No, I would like to continue to the next section	Significant change required: changing intent and wording	IV) To ensure that the Domain Name System operates with the required level of transparency ensuring the availability of available names to natural and artificial persons without the availability status being masked in the middle by data purporting to be Registrant data but may actually be that of intermediary registration data masking the speculative nature of intermediary registration which may sometimes be exploitative.	This is to ensure fairness in the availability of Domain Names to natural and artificial persons; It is acknowledged that some names that are beyond the purview of Trade Marks are desirable names by many, hence have a premium value. To ensure fairness and transparency of opportunities for registering premium names by existing and new processes between ICANN and Registries.	Significant change required: changing intent and wording	MAINTAINING THE SECURITY, STABILITY, AND RESILIENCY OF THE DOMAIN NAME SYSTEM IN ACCORDANCE WITH ICANN'S MISSION THROUGH THE ENABLING OF transparency of basic information concerning all web spaces with Domain Names to all users, transparency of a required level of information concerning commercial web spaces with Domain Names to all users, LAWFUL ACCESS FOR LEGITIMATE THIRD-PARTY INTERESTS TO additional / redacted DATA ELEMENTS COLLECTED FOR THE OTHER PURPOSES IDENTIFIED HEREIN	The EPDP recommendations may not have to be restrained by conflicts with the text of the GDPR; The policy development exercise by ICANN as a global, multi-stakeholder organization with a responsible role in the Domain Name System, needs to spell out its own purposes without restraint, irrespective of any conflicts with GDPR and communicate its recommendations to Europe as such. In this section, the Purpose is further clarified by the proposed text which emphasizes the preservation of Registrant Data by the earlier whois process which made data elements largely available for all users. Whois, by any other name, with fewer data elements if necessary, needs to exist for the benefit of all users; Some data fields may be designated as sensitive and redacted, but Lawful Access by Law and Order Agencies for part or all of the redacted data of all or requisitioned domain name registrations is to be defined; Same or lesser level of lawful access by Third Parties to be separately defined. The rationale for distinction between commercial and non-commercial Domain Names is further expanded in response to Question#1 and #87	Support Purpose intent with wording change	ENABLE COMMUNICATION WITH AND/OR NOTIFICATION TO THE REGISTERED NAME HOLDER directly as far as possible AND/OR through THEIR DELEGATED AGENTS OF TECHNICAL AND/OR ADMINISTRATIVE or other important ISSUES WITH A REGISTERED NAME	This is in consideration of the possibility that in the case of some individual users, some small businesses and even some large businesses, the process of designating an agent is sometimes careless, and it is not always that the communication to the designated agent reaches the actual Registrant; The proposed modification to the text is to emphasise that Registries and Registrars have a purpose in reaching the Registrant, directly as far as possible, and "through" the designated Agent where direct communication is not possible.	Support Purpose as written			Support Purpose as written			Support Purpose as written			Support Purpose as written				1. Mitigation of Domain Name Abuse. 2. To improve consumer trust in the Domain Name System	The rationale for this is explained in answer to Question 87	No, I wish to continue to the next section	Intent and wording of this recommendation requires amendment	Per the EPDP Team Charter, the EPDP Team is committed to considering a system for DIFFERENT CATEGORIES of Standardized Access to non-public Registration Data ....	If not intended already, standardisation needs to be considered as NOT a single standard for access to all non-public data by all legitimate requests, but different standards for access different data elements by differentiated legitimate requests; for instance requests by International Law and Order Agencies and a Commercial third party, both making legitimate requests may not access data by a single standard of access, by the same level of privileges.		Intent and wording of this recommendation requires amendment	The EPDP Team recommends that requirements related to the accuracy of registration data under the current ICANN contracts and consensus policies shall not be NEGATIVELY affected by this policy.	There is a need for improvements related to the accuracy of registration data. The existing level of registration data accuracy is inadequate.		No, I wish to continue to the next section	Yes			Optional Data elements need to be required data elements and additional data elements may also be necessary in the case of domain names registered for existing or intended commercial webspaces, so classified voluntarily by the Registrant or deemed as such by features of commercial activity, to be agreed as such by ICANN Community, (for instance the presence of a payment interface or pricing or subscription information). ICANN may have to consider ways of making a distinction between individual and commercial domain names, between natural persons and artificial persons, based on the web spaces the domain names point to; Even in the case of natural persons, if the domain name is for commercial use, the emphasis needs to be on transparency rather than privacy.		Mandatory	Often there is a disconnect between the Registrant and the Technical contact, where the technical contact is a different person or entity. The technical contact is more important to ensure the Security and Stability of the DNS, in various situations.			Yes	Too many categories. Could be limited to Registrant and Technical Contact data, with the stipulation/ understanding that the Registrant is responsible for Billing and that either the Registrant or Technical Contact be designated as Administrative Contact.		Yes			All data elements are to automatically transferred or better REPLICATED for the Registry. The Registry is to be deemed the ultimate custodian and broadly accountable for any data collected by the Registrar / Reseller by a system of Data Control agreements passed on to the Registrar and through the Registrar to the Reseller. The method of Registrant Data collection could also change. As in credit card transactions, where the card holder submits card information directly to the card company even though the form for card information is in the merchant's website, Domain Name registrations could have system of gathering Registrant Data by a similar form directly connected to the Registry Data base, from where the essential data elements necessary for the Registrar / Reseller's future commercial correspondence be transferred back to the Registrar / Reseller.	Intent and wording of this recommendation requires amendment	1. The EPDP Team recommends that ICANN Org establishes escrow infrastructure or enter into legal agreements with the data escrow providers, with the understanding that the escrow providers will not process any data.	Data escrow visualize scenarios of Registries not having adequate storage redundancy or rare scenarios of Top Level Domain Names discontinuing operations so abruptly that they don't even reliably transfer data to the alternate Registry Service Provider mandated by the gTLD agreements. While there is some rationale for data escrow, the escrow stipulation amounts to data replication - a copy of the data base. Whatever standards are adopted, whatever safeguards are imposed, escrow amounts to an additional copy of the data base. If this storage redundancy is required, then ICANN could consider ways of building inhouse capabilities for normally locked redundant storage inhouse.		Support intent of recommendation with edits	Yes			The wording could be modified as below 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 (replace "process" with "collect") - delete - "when required/requested" - delete , 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 ( replace "specifically-identified" with "all" ) data elements the EPDP Team recommends be transferred from registries and registrars to ICANN Compliance (see Annex D, Workbook 5).	No	In the case of Registrants registering domain names for commercial webspaces, none of the data elements to be redacted; more data elements may be necessary.				This comment submission in various sections emphasises the importance of making a distinction between registrants registering a domain name for individual webspace (for instance a personal blog) and a registrant registering a domain name for commercial use (for instance a website with a payment gateway or bank account details); With such a distinction between personal and commercial domain names the "Organization" field is essential for commercial domain names, but non-essential for personal domain names. What is referred to as "commercial domain name" is usually domain names registered by business entities legally known as artificial persons, but also includes individuals carrying out commercial activity in the webspace linked to the domain name.				The "organization" field needs to appear only in the section for commercial name registrations in the extended Domain Name Registration form	Support recommendation as written				Support recommendation as written				The EPDP may not introduce such a complication for Registrars and Registries, but would rather insist on the non-geographic nature of the Domain Name System.		It would reverse the evolution of the global DNS; Also, it is not practical for Registries and Registrars to differentiate between Registrants on a geographical basis and grant different privileges, apply different rules between Registrants from different Economic Zones, from across 195 countries, some with multiple provincial legal frameworks.	In Data Protection terminology, "Personal data" is more of a generic or 'loose' term that happens to apply indiscriminately both to individual and business data. In DNS, Registration Data does not make any distinction between individual registrants and business registrants whose web space is for some form of (e)commerce activity. While there is a need for privacy of personal data of individual registrants, the opposite, need for greater transparency, may be required in the case of data related to any form of commercial, perhaps even Government and non Government web spaces. The rationale is that the online presence of small and large businesses alike are often short of information pertaining to physical location, names of functionaries, officials or the person in-charge. A Phone company does not have listed phone number, an email company does not have a visible email addresses! This is part of a pattern of multiple players transacting business online from a carefully guarded climate of "do-not-reply" email accounts, phones without a call back number, answering machines, conveniently assisted by BPO intermediaries who keep the consumer at an unapproachable distance. A hotel reservation portal or a small shop online transacts business online without allowing the consumer the ability to reach them for various reasons. Limiting access to Registration data without discrimination of whether the data belongs to an individual as personal data or if it is Registration data of a domain name that points to a commercial web space, and limiting access only for 'legitimate uses' may perpetuate this trend of inaccessibility of business entities, widen the disconnect between business and consumer with the effect that multiple commercial registrants would continue to design their online presence to transact business without due accountability. The sections on Lawfulness & Purposes of Processing gTLD Registration Data as written, might have the unintended consequence of perpetuating unhealthy protection for segments that actually require information disclosure and transparency. EPDP team could actively consider this, and persuasively convey to Europe that ICANN as a responsible global multistakeholder organization would make this distinction in global public interest. Also, for this specific purpose, it is not sufficient to fit data into two classes namely "identifiable natural persons" and "artificial persons". The emphasis here is on Domain Names of Web spaces with commercial activity or intent, usually distinguished by the presence of a payment gateway or other forms of payment information; In this context, it is not sufficient if incorporated companies legally known as "artificial persons" are alone classed for additional data elements for transparency. Commercial Activity could also be undertaken by non-commercial entities in the form of subscription plans or donation requests; by individuals who operate businesses as individuals; Registrant Data needs to make a distinction between personal domain names such as the domain name for a personal blog and a commercial domain name which carries out any form of commercial activity.	GDPR is a good start. It is a very good start. It seeks to set right certain imbalances concerning the collection and use of personal data. However the GDPR may have to be more balanced in its next versions. What is legislated to safeguard privacy rights may get distorted to compromise other values, such as transparency. One example from history is from the legislation on Rights. A thoughtful author cites in his book, "Of the ten amendments that make up the US Bill of Rights, corporations have successfully asserted the applicability of five to win protections for themselves. These include the First Amendment right to free speech; the Fourth Amendment freedom from unreasonable search and seizures; the Fifth Amendment prohibition against takings and double jeopardy despite the fact that the Amendment clearly refers to natural persons; and the Sixth and Seventh Amendment rights to jury trials in criminal and Civil matters respectively" The instances cited are: The concept of property rights, originally developed to preserve an individual’s right to property is used to grant individual rights to entities that are themselves a form of property. As early as 1818, Congressman Daniel Webster used the idea of property rights to limit a state’s influence over a corporation. These were the earliest advances on the road to granting individual rights to “fictional persons” This was when real people were still bought and sold as property with fewer protections than corporations. Corporations aren’t specifically mentioned in America's 14th Amendment, or anywhere else in the Constitution. U.S. corporations have sought many of the same rights guaranteed to individuals, including the rights to own property, enter into contracts, and to sue and be sued just like individuals. 1978 Bellotti decision, which granted corporations the right to spend unlimited funds on ballot initiatives as part of their First Amendment right to freedom of speech; In the 2010 case Citizens United v. Federal Election Commission (FEC), the most sweeping expansion of corporate rights yet, the US Supreme Court cited Bellotti in its highly controversial 5-4 ruling that political speech by corporations is a form of free speech that is also covered under the First Amendment. Irrespective of how Europe may strengthen the GDPR by way of well considered safeguards against limitations and possible abuses of privacy legislation, the EPDP could work though resistant and misdirectinal arguments on the need to differentiate between natural and legal persons (and go beyond this categorization of differences to further differentiate between domain names for personal and commercial use.	No.	Even in simple web spaces, such as that of a non-profit organization with a membership form, such a distinction is easily made by a simple form that leads to a different set of questions if the membership is sought by an organization, and often differential membership fee is applied. While technical implementation in the case where Registrants themselves correctly disclose if the domain name is for personal or commercial use, in situations where a commercial domain name Registrant seeks to classify his commercial domain as a personal domain name, certain automated post-domain-registration checks could flag the domain name automatically. These include meta data scanning for commercial keywords, or automated crawling to look for signs of commercial activity such as the presence of a payment gateway or bank account information.	Intent and wording of this recommendation requires amendment	[Practicable]* timelines criteria for responses to be provided by ICANN.	The timeline criteria provided by contracted parties may differ from one contracted party to another based on each party's data infrastructure and overall organizational factors. Instead the timeline criteria could be provided by ICANN which could act as a single contact point for access requests which it could process in accordance with the policy that it is developing by its multi-stakeholder global process. Even the data access could be granted from ICANN Compliance database / escrow , by privilege levels as determined by the class of requester and the nature of request. Such a process may remarkably reduce the burden on Registries and Registrars and would also considerably ease the processes for the Requester who would otherwise have to request access from multiple Registries and Registrars, each in a different geographic location. If ICANN chooses to make lawful access as a single window process, it could design technical safeguards thoroughly, with more layers of security than any independant Registry or Registrar could afford to, while its legal team may have to designate this activity as a Service qualifying for as much legal immunity as could be built in, for its Board, Senior Staff and also with clauses for all legal costs pre-deflected to Requesters.		Support recommendation as written			The comment for Recommendation #12 above may be read together with this response.		No, I wish to continue to the next section
44	12/21/2018 19:01:25	A. Mark Massey	Domain Name Rights Coalition	No		No, I would like to continue to the next section	Support Purpose as written			Purpose should be deleted	full deletion	Purpose 2 is not required in order to create and operate a domain name. It does not justify any real purpose for collecting and processing data about the registrant. It is related to disclosure of the data that has already been collected. Under the GDPR, this is not considered a legitimate purpose. Lawful access for legitimate third party interests should be handled under the policy for “access” or disclosure. It does not need to be declared a purpose, thus this should be deleted.	Support Purpose as written		This is a legitimate purpose that is consistent with ICANN’s mission. Notification and communication with the domain name registrant for purposes of technical and/or administrative issue handling is helpful and necessary for both registrants and registrars.	Support Purpose as written		It is legitimate to collect and process data for this purpose, as it supports the rights and interests of the registrant.	Support Purpose intent with wording change	HANDLE CONTRACTUAL COMPLIANCE MONITORING REQUESTS, AUDITS, AND [ADD: Reasonable] COMPLAINTS SUBMITTED BY REGISTRY OPERATORS, REGISTRARS, REGISTERED NAME HOLDERS, AND OTHER INTERNET USERS	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 access to process this data to monitor compliance with its policies. As long as access to this processing of specific data that is fit-for-purpose is restricted to parties who need it for this defined purpose, we can support Purpose 5. We note below unreasonable complaints, and of course, for these, registrant data must not be shared.	Significant change required: changing intent and wording	Delete: “PDDRP, RRDRP, AND FUTURE DEVELOPED DOMAIN NAME REGISTRATION RELATED DISPUTE PROCEDURES FOR WHICH IT IS ESTABLISHED THAT THE PROCESSING OF PERSONAL DATA IS NECESSARY” The processing of registrant data must only be required for processing of disputes against the registrant, not for the processing of disputes against the registry or any other party in the ICANN chain of contracts. This is not the case in the proceedings deleted above.	Purpose 6 is too broad. UDRP and URS are actions against individual domain name registrants, and for those purposes, assuming a full and valid “John Doe complaint” has been filed with an approved ICANN dispute resolution provider, the identity of the individual registrant can be disclosed to a) the Provider, and b) to the Complainant (who is a trademark owner). Such disclosure serves a balancing of interests as well because absent disclosure of the Registrant contact information so that the Registrant can receive full documentation of the proceeding against his/her/its domain name, along with deadlines and avenues of response and challenge. However the PDDRP and RRDRP are entirely different. These are proceedings against the Registry itself. In the “Trademark Post-Delegation Dispute Resolution Procedure (Trademark PDDRP) (note: the only type of PDDRP that exists), the proceeding is against the Registry (not the Registrant). The allegation is as follows: => ‘The Trademark PDDRP generally addresses a Registry Operator's complicity in trademark infringement on the first or second level of a New gTLD. At least 30 days prior to filing a formal complaint, a rights holder must notify the Registry of the alleged infringing conduct and express a willingness to meet to resolve the issue. Review the Trademark PDDRP [PDF, 181 KB].” https://newgtlds.icann.org/en/program-status/pddrp To the extent in a PDDPRP that the Registry is also the registrant of domain names used for abuse, it is likely those domain names will be used as part of the pattern of conduct of the Registry. But to the extent that there may be thousands or even millions of innocent domain name registrants within a gTLD accused of complicity with trademark infringement at a registry-scale, there is absolutely no waiver of interest and no relinquishing of privacy for the purpose of pursuit of an arbitration against an entirely different third party (the Registry). Accordingly, processing the personal data of registrants for the purpose of “coordinating, operationalizing and facilitating” a PDDRP dispute between a trademark owner and an ICANN Registry cannot be one which by definition includes the registration data of all registrants -- domain name registrants are not accused in the PDDRP Ditto for the Registry Restriction Dispute Resolution Procedure (RRDRP) which is similarly a proceeding in the New gTLD Applicant Guidebook against the Registry itself and the allegation is as follows: => “The RRDRP is intended to address circumstances in which a community-based New gTLD Registry Operator deviates from the registration restrictions outlined in its Registry Agreement.” https://newgtlds.icann.org/en/program-status/pddrp The proceeding for an RRDRP, as with the PDDRP above, is expressly against the Registry. In the future, there may be thousands or even millions of innocent domain name registrants completely in compliance with the community-based standards of a community-based gTLD. It is absolutely inconsistent with the GDPR or any notion of registrant privacy and protection to deem all registrants of a gTLD to have consented or in any way agreed to the disclosure of their personal information should the titans (large organizations and registries) fight in a RRDRP. There is no legal basis for the RDDS disclosure of the data of innocent and good faith registrants in a PDDRP or RRDRP proceeding. Further, the gaming implications of such massive and unwarranted disclosures of innocent and good faith registrants in a PDDRP, and especially RRDRP proceeding - are enormous. Under the rules as posited above, the very act of bringing and RRDRP, for example, could then result in a massive disclosure of registrants within an endangered or sensitive community, e.g., .GAY, regardless of who brought the allegation, how valid it was or whether the vast majority of registrants are innocent and good faith. Such a result would be shocking and unwarranted, not to mention prohibited by the GDPR. Note: Registrar-Registrant agreements expressly agree to the cooperation of the registrant in an UDRP or URS action -- an individual action against his/her/its domain name. It would be extraordinary to have such agreement extended to the disclosure for an action against 3rd party, namely Registries! As such, “PDDRP, RRDRP, AND FUTURE DEVELOPED DOMAIN NAME REGISTRATION RELATED DISPUTE PROCEDURES” must be stricken from Purpose 6 above as overbroad and out of scope and inconsistent with the protections accorded under the GDPR. Overall, 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 of UDRP or URS only, with further limitations on their publication and use, DNRC can support Purpose 6.	Purpose should be deleted	full deletion	Data required for validation could include a wide range of sensitive personal data enabling the identification of individuals or protected groups such as religious, political, ethnic, gender and sexual orientation organizations. 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 openings the door to potentially hundreds of new data elements. Furthermore, it is dangerous and inappropriate for this data to be placed in a global directory which 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. We note the extremely high level of protections that the GDPR provides to sensitive data (Article 9) and to protecting the “fundamental rights and freedoms of the data subject” (which override virtually all other lawful bases for processing) (Article 6(f)). The addition of new data elements to the RDDS is clearly beyond the scope of this EPDP. The EPDP Team was chartered to determine if the Temporary Specification for gTLD Registration Data should become an ICANN Consensus Policy, as is or with modifications, while complying with the GDPR and other relevant privacy and data protection law. The EPDP Team was not chartered to create new features and purposes for processing gTLD Registration Data. This issue is best taken up on 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 are outside of the scope of this EPDP.		No additional purposes are required.		No, I wish to continue to the next section	Intent and wording of this recommendation requires amendment	DNRC strongly recommends replacing the term “Standardized Access to nonpublic Registration Data” with the term “Lawful disclosure of nonpublic registration data to third parties with legitimate interests.”	In essence, Recommendation 2 is simply a restatement of one aspect of the EPDP’s charter. Later in this report, the wording change proposed above was accepted.		Delete recommendation	full deletion	This recommendation is unnecessary; Policies regarding accuracy are not within the remit of the nothing in the temporary specification, and should not be a part of or the current set of recommendations affects policies regarding accuracy in any way. While DNRC understands that accuracy is important to specific stakeholder groups, and to the registrants, unreasonable fears about impact on existing accuracy policies should not be legitimized by a recommendation such as this one.		No, I wish to continue to the next section	No	DNRC opposes the inclusion of “Additional optional data elements as identified by Registry Operator in its registration policy.” Street [address] must also be deleted.	DNRC strongly opposes the collection of street [address] as completely unnecessary for any ICANN or DNS technical and operational needs of a domain name. Like credit card data, it is a piece of information collected by the registrar for the purpose of processing the electronic payment of a domain name registration or renewal. It, however, serves no other purpose in the lifecycle and technical administration of the domain name and need not be collected and maintained in any form of centralized or shared database WHOIS database -- street address is simply not needed in any way by the larger DNS. Further, transmitting this most dangerous of personal/sensitive data - the address of a person and/or the address of a battered women's shelter, girl's school, religious organization, health, gender, and sexual orientation group is highly protected by the GDRP, especially in the balancing of interests of the requestor and domain name registrant. The street field is predates the existence of registrars. This street field is the most dangerous by far to the groups and individuals registering their domain names for and engaged in the sensitive activities online and this sensitive data is expressly protected and its processing prohibited by the GDPR, Section 9: “Art. 9 GDPR Processing of special categories of personal data Processing of personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, and the processing of genetic data, biometric data for the purpose of uniquely identifying a natural person, data concerning health or data concerning a natural person’s sex life or sexual orientation shall be prohibited.” https://gdpr-info.eu/art-9-gdpr/ We note further that given the danger to life and liberty to many organizations and individuals from street address -- the exact location where to find targeted minorities exposed to danger in virtually every country -- the protections of GDPR under Article 6 are so high as to provide virtually no “lawful processing” not “overridden by the interests or fundamental rights and freedoms of the data subject…” See Article 6: 1. “Processing shall be lawful only if and to the extent that at least one of the following applies:” * * * * * “(f) processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child.” The street address is simply not a required data element. Further, we strongly oppose the expansion of RDDS/Whois data to include a potentially unlimited numbers of new data elements reflecting individual policies of different registry operators.			Optional	The technical field must not be required of registries and registrars who feel it violates the principles of data minimization. The technical contact field is a legacy element that predates the existence of registrars.	No		Yes	Yes, we strongly agree that this data should not be collected. It is legacy data and largely duplicative of registrant contact data.		No	No personal or sensitive data elements should be transmitted from registrar to registry.	No, these data elements should not be transferred from gTLD registrar to gTLD registry. The registries of ICANN are expressly not required to be in countries of the EU or countries declared “adequate” by the Data Protection Commissioners, and we have seen many new gTLD registries incorporated in countries which do not have comprehensive data protection laws (and do have strong laws requiring shared of data with law enforcement), including the US. 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 elements that will endanger registrants (protected under the GDPR) in countries to which their personal data and sensitive data, are transmitted. Such power over registrant freedoms cannot be delegated to ICANN or ICANN registries who are not bound by the GDPR laws, and cannot (even by contract) waive their local obligations to respond to law enforcement demands. Accordingly, 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. Transfer of these personal and sensitive data elements, only as edited in our comments above, to the registry is appropriate and legal under the GDPR.		Support recommendation as written				Intent and wording of this recommendation requires amendment	No	only those data elements needed on a case-by-case to a valid and non-frivolous and non-harassing complaint should be transferred from the registrar/y to ICANN Compliance.	Requests by ICANN compliance must be limited to those elements required to accommodate satisfy issues at that time. In principle, this could mean that all data elements may be needed for one complaint, but not for another. We wish to underline the principle that compliance requests must not be open-ended fishing expeditions. We note that ICANN Compliance rules should be subject to more 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.		Yes			Yes	yes, yes, a thousand times yes. Organization should not be visible. Many people operate small organizations, home-based businesses. Mom-owned business, and hobby, research and educational groups from their homes, and the contact data in their domain registration is indistinguishable from that of an individual residence (because it is an individual resident!). Also, some organizations that are not doing anything illegal might be targeted merely because of their legal political, religious, or social affiliations (and these groups, as noted below, and those who work for them), are specially protected by the GDPR as noted in other parts of this comment. Combining the “Organization” field with others fields, including state or city would certainly make a domain name registrant more identifiable and more targetable.		Delete recommendation		“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. Further, organizational fields are expressly protected by the GDPR. Organizations for sensitive religious, philosophical, racial, ethnic, political, trade union, health, gender, sexual orientation are specifically, protected as sensitive data under the GDPR, Article 9. As noted above, we certify that the vast majority of noncommercial organizations we encounter fall within GDPR Article 9 protection -- making this a huge issue for ICANN and a huge reason not to reveal the organization field to the public. In many parts of the world, the names of organizations are removed from the outside signs of buildings, public directories, and even maps of cities. These include mosques, synagogues, churches (all now targeted in different areas of the world today), Planned Parenthood centers, battered women shelters worldwide, schools educating girls in regions of the world where some dislike that activity (and shoot its proponents), and of course, the range of sensitive religious, philosophical, racial, ethnic, political, trade union, health, gender, sexual orientation expressly listed and protected as sensitive data under the GDPR, Article 9 --- every organization above falls within these wide, critical, GDPR-protected categories. Requiring the mandatory listing of such organizational names -- and thus publishing publicly out publicly what no public map, directory or listing would ever require such organizations to publish (regardless of the organization’s legal structure) -- is completely counter to the GDPR as well as fundamental human rights protections under numerous other laws. It should not be required.		Support intent of recommendation with edits		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. We note further that many domains and email address provide personal and sensitive data. Far better to use a temporary, registrar-assigned and/or web form to facilitate email communication with the relevant content without inadvertently revealing personal and sensitive data.		Support recommendation as written				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 DNS. One of the main reasons for creating ICANN was to ensure that the DNS would have a globally consistent set of rules. We strongly oppose 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 DNS. This helps maintain the global compatibility of the Internet.			DNRC 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 to data protection and impose major cost burdens and risks on the contracted parties. Many registrants will not understand the distinction and will end up being misclassified as organizations and thus lose their 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 a registrant’s email address, which would belong to an employee or representative of the legal person, typically being name@domain.TLD.				Intent and wording of this recommendation requires amendment	DNRC strongly supports replacing “Standardized Access to Non-Public Registration Data” with “parameters for requesting lawful disclosure requests,” as that more accurately describes the objective.	It will simply be insufficient to state a mere category of request for data, e.g., “intellectual property allegation” or “law enforcement need.” The requirements of GDPR dictate that prior to revealing the personal and sensitive data of registrants, there is an evaluation that must take place. For law enforcement, for example, given the wide differences of law across the jurisdiction, an allegation of “criminal illegality of content,” for example, would have to be followed up with discussion of the jurisdiction of the registrant, registrar, and registry. For the disclosure of personal and sensitive individual and organizational data from countries in which the registrant is protected by national law, e.g., US First Amendment, to law enforcement in countries that seek to ban that type of speech, e.g., pro-democracy speech (China and other countries), pro-gay speech (Nigeria and other countries that make this speech a criminal and even capital offense), and even views of history not endorsed or told by certain governments. GDPR Article 6-1(f) requires an evaluation, even of law enforcement and intellectual property requests, that is not standard, but rather sufficiently detailed and targeted to show that “processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child.” That is not a standard form or request, but could be a pre-defined set of “parameters for requesting lawful disclosure requests By way of background: Art. 6 GDPR Lawfulness of processing Processing shall be lawful only if and to the extent that at least one of the following applies: the data subject has given consent to the processing of his or her personal data for one or more specific purposes; processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract; processing is necessary for compliance with a legal obligation to which the controller is subject; processing is necessary in order to protect the vital interests of the data subject or of another natural person; processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller; processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child.		Support recommendation as written					No, I wish to continue to the next section
45	12/21/2018 19:03:47	Stephanie Perrin	NCSG	No		No, I would like to continue to the next section
46	12/22/2018 11:41:55	Brian King	IPC	Yes	This is the official comment of the IPC.	No, I would like to continue to the next section	Support Purpose intent with wording change	AS SUBJECT TO REGISTRY AND REGISTRAR TERMS, CONDITIONS AND POLICIES, AND ICANN CONSENSUS POLICIES: (IV) TO ESTABLISH THE RIGHTS AND OBLIGATIONS, SUCH AS THEY MAY BE, , such as they may be, OF A REGISTERED NAME HOLDER IN A REGISTERED NAME; (V) TO ENSURE THAT A REGISTERED NAME HOLDER MAY EXERCISE ITS RIGHTS AND FULFILL ITS OBLIGATIONS IN THE USE AND DISPOSITION OF THE REGISTERED NAME; AND (VI) TO ACTIVATE A REGISTERED NAME AND ALLOCATE IT TO THE REGISTERED NAME HOLDER	The collection of data from the domain name registrant serves not only the purpose of establishing rights of the registrant in a registered name, but also for establishing obligations. This includes the obligation for the registrant to comply with the various terms and conditions established in the contract between the registrar and the registrant. Rights and obligations go hand-in-hand, and therefore the purpose of obtaining the data from the registrant to establish the rights in the name cannot be separated from the purpose of obtaining the data to fulfill the obligations that go along with domain name ownership. Article 6(1)(b) of the GDPR establishes the legality of collecting and processing personal data "for the performance of a contract to which the data subject is party . . . ." The performance of any contract involves OBLIGATIONS in addition to rights. Therefore, adding the language suggested concerning obligations makes this proposed purpose more compliant with the GDPR.	Significant change required: changing intent and wording	ENSURING THE SECURITY, STABILITY, AND RESILIENCY OF THE DOMAIN NAME SYSTEM IN ACCORDANCE WITH ICANN'S MISSION, COMMITMENTS AND CORE VALUES THROUGH THE ENABLING OF LAWFUL ACCESS FOR LEGITIMATE THIRD-PARTY INTERESTS OF LAW ENFORCEMENT, CYBERSECURITY, COMBATTING DOMAIN NAME SYSTEM ABUSE, CONSUMER PROTECTION AND INTELLECTUAL PROPERTY RIGHTS PROTECTION TO DATA ELEMENTS COLLECTED FOR THE OTHER PURPOSES IDENTIFIED HEREIN	Although we do not object in principle to the Purpose 2 statement, the IPC hopes to clarify that the purpose includes as a component the recognition of protection of intellectual property rights (as the universally, legally defined recognized rights of: trademark, copyright and patent) and by extension consumer protection and consumer trust within the meaning of “maintaining the security, stability, and resiliency of the Domain Name System in accordance with ICANN’s Mission” particularly given that part of ICANN’s Mission includes: “resolution of disputes regarding the registration of domain names (as opposed to the use of such domain names, but including where such policies take into account use of the domain names); … reservation of registered names in a TLD that may not be registered initially or that may not be renewed due to reasons reasonably related to (i) avoidance of confusion among or misleading of users, (ii) intellectual property….” Accordingly, assuming this is the case, we hope to confirm that “lawful access for legitimate third-party interests” as used in this purpose statement includes the implicit recognition that intellectual property enforcement related investigations and actual enforcement measures conducted by intellectual property owners and their agents would therefore be considered “legitimate third-party interests” and thus permitted “lawful access” to the requisite data elements collected for other purposes as outlined elsewhere in the Initial Report. Note that while we suggest the addition of “Commitments and Core Values” to the purpose statement, these additions may not be necessary if the above can otherwise be clarified and confirmed. In addition, Article 13(1) of the GDPR states “Where personal data relating to a data subject are collected from the data subject, the controller shall, at the time when personal data are obtained, provide the data subject with all of the following information: . . . (c) the purposes of the processing for which the personal data are intended as well as the legal basis for the processing; (d) where the processing is based on point (f) of Article 6(1), the legitimate interests pursued by the controller or by a third party;” (emphasis added) The current list of purposes would benefit by greater specificity as embodied in the proposed new purpose. ICANN’s purposes with respect to WHOIS data and registry directory services include, according to ICANN’S Bylaws “whether its implementation meets the legitimate needs of law enforcement, promoting consumer trust, security, stability and resiliency, malicious abuse issues, sovereignty concerns and rights protection.” (ICANN Bylaws Section 4.6). Purpose #2 from the Initial Report only addresses “security, stability and resiliency” and does not address the other ICANN purposes and concerns as articulated in Section 4.6 of the Bylaws. Article 13(1) of the GDPR requires that at the time personal data are collected, data subjects be given information about both the purposes for the processing and legal basis for the processing AND the legitimate interest pursed by the controller or by a third party. The proposed new purpose seeks to address both of these requirements by enumerating more specific purposes as well as identifying the legitimate interests of ICANN (as a joint controller) and as pursued by third parties that may seek access to the personal data. In its letter of 11 April 2018, to Goran Marby, the Article 29 Data Protection Working Party stated that “purposes specified by the controller must be detailed enough to determine what kind of processing is and is not included . . . .” The letter also stated that the WP29 “stresses the importance of explicitly defining legitimate purposes in a way which comports with the requirements of the GDPR.” The new proposed Purpose seeks to do just that.	Support Purpose intent with wording change	ENABLE COMMUNICATION WITH AND/OR NOTIFICATION TO THE REGISTERED NAME HOLDER AND/OR THEIR DELEGATED AGENTS OF TECHNICAL, LEGAL, AND/OR ADMINISTRATIVE ISSUES WITH A REGISTERED NAME	The proposed wording change is intended as a mere clarification that communication should be enabled for legal issues involving a domain name, to the extent legal issues are not specifically within the “administrative” issues category. Enabling communication for legal issues is aimed at ensuring proper notice and due process where a domain name might implicate certain legal matters. Alternatively, “administrative issues” should be defined to include resolving claims that a domain name is being used to facilitate unlawful conduct, or to infringe on the legitimate rights of others. Under pre-GDPR Whois, third parties often addressed complaints regarding these issues to the administrative contact (a label that ICANN has never defined). Additionally, these uses are already forbidden under the RAA and/or registry agreements. In cases when third parties address their complaints of violations of the RAA to the registrar (or of RA to the registry), these contracted parties need to know who is the “delegated agent for administrative issues” such as these.	Support Purpose as written			Support Purpose as written			Significant change required: changing intent and wording	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, BUT INCLUDING WHERE SUCH POLICIES TAKE INTO ACCOUNT USE OF THE DOMAIN NAMES), NAMELY, THE UDRP, URS, PDDRP, RRDRP, AND ANY FUTURE DEVELOPED DOMAIN NAME REGISTRATION-RELATED DISPUTE PROCEDURES FOR WHICH IT IS ESTABLISHED THAT THE PROCESSING OF PERSONAL DATA IS NECESSARY. THIS PURPOSE SHOULD NOT BE READ TO LIMIT ANY OTHER PURPOSE WHERE PROCESSING OF DATA HAS BEEN RECOGNIZED AS LEGITIMATE IN CONNECTION WITH FACILITATING INVESTIGATION AND ACTION CONCERNING ANY OTHER LEGAL ISSUES INVOLVING A DOMAIN NAME, INCLUDING HOW A DOMAIN NAME IS USED.	The distinction between “registration” and “use” is inconsistent with the intent and substance of existing procedures for resolution of domain name disputes, including specifically the procedures which are mentioned in the purpose statement itself. For example, to prevail in a domain name dispute under the UDRP, the complainant must prove that the disputed domain name "has been registered and is being used in bad faith. Limiting this purpose to disputes related to registration and specifically excluding “use” would result in a purpose which is narrower than the policies to which it refers. Furthermore, it may be possible that in future, further policies are defined which similarly refer to “use” within the context of ICANN’s mission and mandate. The proposed language appears to draw a distinction that flows from a specific view about the scope of ICANN’s mandate, and in doing so, falls outside the mandate of the EPDP. It would be inappropriate to attempt to narrow the implementation of existing policies for resolution of domain name disputes by drawing an artificial line through such policies based on the “use” versus “registration” distinction. The correct forum for that debate is in the context of such policies themselves, not here. The scope of such policies should be the guide for definition of this purpose, and the recommendation should be neutral in relation to that scope, unless there is a compelling reason based in compliance with privacy laws - which is absent here. This purpose must include resolution of disputes pertaining to uses of domain names, because this falls within the mission of ICANN in connection with security, stability, and resiliency of the DNS, and as expressly stated in Annexes G-1 and G-2 of the ICANN Bylaws. The first proposed addition to the purpose statement quotes verbatim the language from the Bylaws. Indeed, domain names can be used to perpetrate threats to SSR, including through leveraging of IP assets to harm consumers/Internet users, and this must be taken into account in this purpose statement. While ICANN is not directly responsible for online content (per Bylaws, art. 1.1(c)), access to registration data to address content-related issues must still be a valid purpose for processing registration data, within the broader SSR related component of ICANN’s mission, as expressed in purpose #2, and in connection with the purpose of facilitating communication with registered name holders to resolve technical, legal, and/or administrative issues per the proposed amended version of the purpose #3.	Support Purpose as written			We are concerned that the list of purposes is neither sufficiently complete, nor sufficiently detailed. We have attempted to address these concerns by suggesting edits to some of the recommended 7 purposes as well as suggesting additional purposes below.	The IPC supports the addition of purposes related to research - covering research performed by ICANN Org (as currently described in “Purpose O”) but extending to any ICANN group also research performed by relevant and legitimate 3rd parties. 1. [Current Purpose O] - “Research and publish reports on threats to the operational stability, reliability, security, global interoperability, resilience, and openness of the DNS.” The IPC believes this purpose should encompass and enable all ICANN groups and divisions (OCTO, GDD, Compliance) to conduct operations, facilitation activities, and implement consensus policies (adopted in accordance with the ICANN Bylaws) consistent with its mission of furthering the operational stability, reliability, global interoperability, resilience and openness of the DNS. 2. ENABLE [RELEVANT AND LEGITIMATE 3RD PARTY] RESEARCH OF DNS ABUSE AND THE SECURITY, STABILITY AND RESILIENCY OF THE DOMAIN NAME SYSTEM	1. Research is a legitimate basis for processing per GDPR Article 6(1)f, with specific safeguards defined in Article 5(1)(e) and Article 89. It is also squarely within ICANN’s mission and mandate, as the requirement for research derives from Section 1.2a (Commitments) of the ICANN bylaws: (i) Preserve and enhance the administration of the DNS and the operational stability, reliability, security, global interoperability, resilience, and openness of the DNS and the Internet; (ii) Maintain the capacity and ability to coordinate the DNS at the overall level and work for the maintenance of a single, interoperable Internet; This purpose exists to ensure that ICANN may continue to use registration data in support of its mission, whilst maintaining the privacy of data subjects through appropriate safeguards such as pseudonymisation. In addition, this purpose enables ICANN to continue to operate its Accuracy Reporting System (ARS), which publishes periodic reports on accuracy, using full WHOIS contact fields. The ARS is an important program approved by the ICANN Board in response to the recommendations from the 1st WHOIS Review Team. 2. Research conducted by relevant and legitimate third parties with respect to DNS Abuse and the security, stability and resiliency of the Domain Name System is a fundamental and legitimate purpose consistent with ICANN’s Bylaws and critical for ICANN to fulfill its mission. Since such research can and often does involve analysis of data associated with Registered Name Holders, this purpose is directly related to the collection and processing of such data.	No, I wish to continue to the next section	Intent and wording of this recommendation requires amendment	The IPC requests that the general comment in Recommendation #2 be edited to read as follows: “In this context, amongst others, the ePDP Team will develop a policy that prescribes the method for disclosing non-public registrant data to third parties that have established legitimate interest in accessing registrant data including intellectual property rights holders, cybersecurity firms, organizations that mitigate DNS abuse, and law enforcement agencies.” Per the EPDP Team Charter, EPDP Team is committed to answering the additional gating questions in the charter and recommending a system for Standardized Access to nonPublic Registration Data no later than submission of its Final Report. In this context, amongst others, disclosure in the course of intellectual property infringement and DNS abuse cases will be considered.	The charter calls for the EPDP team to deliver an Initial Report outlining a proposed model of a system for providing accredited access to non-public Registration Data, not to “consider” doing so. The EPDP fails to fulfill its charter if it does not deliver a model for a system for standardized access to non-public data. At a bare minimum the team should commit to a time certain to complete this work, and no consensus policy superseding the Temporary Specification should be adopted without it. The IPC strongly supports this recommendation for the EPDP Team to develop a standardized, or “unified,” system for access to non-public registration data after the gating questions have been answered. The IPC proposes edits to this recommendation to reflect that the protection of intellectual property rights is expressly recognized as a legitimate interest under GDPR and therefore understood to be within scope of the final policy. In the Article 29 Working Party’s letter to ICANN dated April 11, 2018, the A29WP “welcome[d] the decision of ICANN to propose an interim model which involves layered access, as well as an “accreditation program” for access to non-public WHOIS data.” This communication signaled A29WP’s support for a standardized access program. This support is further echoed, in a May 27 communication to ICANN, in which the EPDB reiterated that it expects ICANN “to develop and implement a WHOIS model which will enable legitimate uses by relevant stakeholders, such as law enforcement, of personal data concerning registrants in compliance with the GDPR, without leading to an unlimited publication of those data.” With respect to the reference to “relevant stakeholders,” ICANN has identified “intellectual property rights holders as being such stakeholders with a legitimate interest in having access to registrant data. For the reasons expressed above and in deference to the statements provided, the IPC recommends the edits provided above.		Intent and wording of this recommendation requires amendment	The EPDP Team recommends that no consensus policy adopted to address registration data interfere with accuracy requirements under current ICANN contracts and consensus policies nor interfere with ICANN’s ability to enforce accuracy requirements, including by being able to access full registration data (including any data elements that are redacted from publication in any registration directory) in order to assess data accuracy and enforce accuracy contractual requirements. This includes full access to registration data to enable the operation of the ICANN WHOIS Accuracy Reporting System (“ARS”) and all validation functions under the ARS. In addition, because of the data accuracy requirements imposed by the GDPR, the EPDP Team recommends that requirements be developed to increase the accuracy of registration data.	According to Article 5.1(d) of the GDPR, personal data shall be "accurate and, where necessary, kept up to date; every reasonable step must be taken to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay." The ico. (Information Commissioner’s Office in the UK) points out in its writings on “Principle (d): Accuracy” that one of the new features of GDPR as compared to the principles under its predecessor is that there is now a “clearer proactive obligation to take reasonable steps to delete or correct inaccurate personal data.” In addition,the European Commission’s technical input on ICANN's proposed GDPR-compliant WHOIS models underscored the GDPR's "Accuracy" principle and made clear that “reasonable steps should be taken to ensure the accuracy of any personal data obtained” for WHOIS databases and that ICANN should be sure to incorporate this requirement in whatever model it adopts. Accuracy of domain name ownership is paramount to collection of WHOIS/Registered Name Holder data in the first instance. In addition, since this data will be used by others (with a lawful interest), ensuring that it is accurate for them is also relevant. Moreover, as demonstrated by the .dk ccTLD, when accuracy and validation of registration data is taken seriously, it leads to dramatic decreases in abuse and illegal activity on the top level domain. See: https://ccnso.icann.org/sites/default/files/field-attached/presentation-difo-increase-trust-25jun18-en.pdf Prior to the adoption of the Temporary Specification, accuracy of WHOIS data was problematic. When the ARS was running, we know that almost 40% of randomly sampled registrations had a problem that warranted opening a compliance ticket on them. Therefore, even prior to ICANN seeking to modify its policies to comply with GDPR, a serious problem with accuracy existed. Now with the adoption of the Temporary Specification, the ARS is not even operational. Without improved accuracy, it is likely that the quality of WHOIS data will decline, and the important policies being discussed by the EPDP will increasingly apply to a large amount of data the accuracy of which is questionable, and would be contrary to the public interest rationale for the collection of WHOIS data. With the accuracy requirements that the GDPR imposes, accuracy is an issue fully within scope of the EPDP so that ICANN and contracted parties proactively address how they will ensure the accuracy of data in the first place, not just how they rectify inaccurate data brought to their attention after collection.		No, I wish to continue to the next section	Yes			1) Registrars should be required to provide an option for registered name holders to indicate that they are either a Legal or Natural Person. 2) Registrar should also generate a data element of the date on which registrant contact data was last verified/validated in accordance with the RAA, and the method used to do so.	1) GDPR does not apply to Legal Persons, therefore allowing registered name holders to indicate they are such Persons creates the opportunity and possibly the legal basis needed to publish the full Whois record or at least more fields therein. Recital 14 of the GDPR - The protection afforded by this Regulation should apply to natural persons, whatever their nationality or place of residence, in relation to the processing of their personal data. This Regulation does not cover the processing of personal data which concerns legal persons and in particular undertakings established as legal persons, including the name and the form of the legal person and the contact details of the legal person. 2) Currentness is a critical element of accuracy as required by the GDPR. Anyone obtaining access to this data for any of the authorized purposes will need to know how fresh it is. This includes but is not limited to ICANN compliance, which otherwise will not be able to enforce the data quality requirements of RAA.	Optional	The IPC does not believe that collection of Technical Contact information should be “Mandatory”, however registrars should be required to offer the OPTION for registrants to provide this information. Many registrants wish to provide secondary contact information, including large corporate registrants who need to route the appropriate communications within their organization, and technically-novice registrants who need to enlist the help of an organization with greater technical expertise to manage their web presence. Even more registrants may simply want to list a backup contact for estate or succession planning or mere peace of mind of having a backup. If this were to be made optional for registrars, many registrants would, in effect, be deprived of their ability to choose to list a second contact, especially if they lack the sophistication to know they could choose a different registrar that allows them to do so. Further, registrants who have already designated a different technical contact could be deprived of the choice they have already made if their registrar is permitted to discontinue the service. Therefore, the IPC believes that Registrars should be required to provide registrants with the “OPTION” to provide Technical Contact information, although provision of this alternative contact information by registrants should not be mandatory. Moreover, if the registrant opts to enter this data, the registrar should be required to publish it.	Yes	Registrars should be required to offer this OPTION for registrants to provide this information, since some registrants desire or need to provide this information for the purposes listed above. Many domain registrants will want to be contacted swiftly if anyone discovers a technical issue with their domain name.	No	The IPC agrees that billing contact data should not be collected for any ICANN purposes as issues related to billing are firmly in the realm of the Registrar. We do believe however that in addition to the optional collection of the technical contact (See Question 47) that Registrants should be given the option to provide an Administrative contact. Both the Technical and Administrative contact fields allow for the Registrant to designate additional suitable points of contact for these functions, adequate to facilitate timely resolution of any problems that arise in connection with his/her/its domain name. A mechanism to specify a separate Administrative Contact ensures the proper delegation of requests associated with domain name management, such as registration renewals or cancellations, purchase or sale-related inquiries or efforts, and other similar kinds of issues relating to the status, disposition, or control of the domain name. The Security and Stability Advisory Committee (SSAC), which “advises the ICANN community and Board on matters relating to the security and integrity of the Internet’s naming and address allocation systems” addressed the importance of administrative and technical contact roles for maintaining control of a domain registration in its advisory, “SAC044: A Registrant’s Guide to Protecting Domain Name Registration Accounts.” SAC044 (https://www.icann.org/en/system/files/files/sac-044-en.pdf) specifically noted, among other things, that maintaining administrative and technical contacts plays a role in reducing single points of failure or attack.8 This report was adopted by the ICANN Board and provides justification for mandating collection of this data from ICANN’s perspective and from a Registrant perspective – in line with ICANN’s purpose of ensuring contacts adequate to facilitate timely resolution of any problems that arise in connection with a domain name. Administrative and Technical Contacts are also vitally important to a number of ICANN consensus policies developed by the global multi-stakeholder community over the last two decades that aim to protect the Registrant, and facilitate the efficient resolution of domain name disputes. Those policies are: ICANN Transfer Policy, which supports robust competition in the domain name industry. Confirmation of a request to transfer a domain name from one registrar to another prevents domain name “hijacking” or unauthorized theft of the domain name. ICANN’s Transfer Dispute Resolution Policy grants administrative contacts the right to contest an unauthorized transfer of the domain name. This serves a similarly important “consumer protection” safeguards for the registrant. ICANN’s Expired Domain Name Recovery Policy specifies that notice of expiration can be sent to the administrative contact for a domain name. ICANN’s WHOIS Data Reminder Policy is sent to administrative contacts annually to ensure that the domain name registrant’s contact data is up to date and accurate. ICANN’s Uniform Domain Name Dispute Resolution Policy (UDRP) and Uniform Rapid Suspension (URS) system are domain name dispute resolution mechanisms to resolve cyber-squatting, and which require that service of process of the complaint be made on the administrative contact and the technical contact in WHOIS, in addition to the registrant. By requiring service on all of the contacts in the WHOIS, registrants are better protected in terms of due process and notice of service, and are less likely to fail to receive a complaint or ignore the complaint, which could result in a default judgment that could cause them to lose their domain name.		Yes		Contractual compliance is a critical and necessary function of ICANN, and part of its obligations to ensure that registrars/registries comply with their commitments in their contracts with ICANN. As such, the proper lawful basis for contractual compliance should be Art. 6(1)(b), and ICANN should receive all information it deems reasonably necessary to satisfy its compliance function. This means that Annex D, Workbook 5, to the extent incorporated by reference into the recommendation, should be modified to ensure the best legal basis is used (i.e. Art. 6(1)(b)) or it should be revised to state that the lawful basis includes both Art. 6(1)(b) and Art. 6(1)(f). ICANN shouldn’t be subject to the risk that a rogue registrar decides to not provide personal information about a registrant to ICANN for compliance purposes under Art. 6(1)(f) because the registrar claims that the interests of the registrant outweigh the interests of ICANN just so that registrar can avoid a compliance audit. In addition, Workbook 5, again to the extent incorporated by reference into the recommendation, should be modified to clarify that ICANN should receive all information that it deems reasonably necessary for compliance, not just the “minimum”, to ensure that ICANN can satisfy this important function. This is particularly important for contractual compliance complaints, such as false whois concerns. The only way ICANN can investigate these complaints is to receive or have access to all of the relevant registrant information so that it can check for compliance. We disagree with the comment in Workbook 5 that suggests that transmission of registration data is not technically necessary to perform the registration contract (which we assume means to perform a compliance audit or compliance check). We believe that ICANN should receive or have as much access to the data as it deems necessary for the compliance function, and that it should not be unduly limited in a manner that makes it difficult or overly burdensome for ICANN to perform this function.	All data should be transferred to the registry, including data for the .com,.net and .jobs TLDs, the only remaining “thin” registries. Thick Whois Policy development concluded, several years ago, that we should transition data from thin to thick for the remaining thin registries. GDPR should not affect the agreed upon policy. Data transfer from registrar to registry can be completed in a manner that is compliant with GDPR.	Support recommendation as written				Support intent of recommendation with edits	Yes			Please see response to question 64. We also note that our members have submitted several contractual compliance complaints to ICANN about registrars’ failure to provide registrant information to them in accordance with the requirements of the temporary specification. Those complaints have been pending for over 5 months with no response from ICANN. This inability of ICANN to investigate and respond to contractual compliance complaints is very troubling and points to a potential breakdown in the ICANN model.	No	City should not be redacted	City needed in order to serve legal process and city not a sensitive personal data element Email has been recognized as most important data element for law enforcement as well as DNS abuse, consumer protection and IP rights violation investigations. In the balance of privacy and other rights and interests, it is appropriate that this data element remain unredacted and publicly accessible. This is particularly the case because a registrant has the ability to create, at no cost, an email address that contains no personal data, such as the registrant’s name. We recommend that in addition to the registrant’s e-mail address remaining unredacted, that registrars inform registrants that their e-mail address will not be redacted, will be publicly accessible and that the registrant may create a valid e-mail address for purposes of registering the relevant domain name which e-mail address contains no personal data. Email: The disclosure of a registrant's email address in a public WHOIS system is essential for the legitimate purpose of expeditiously contacting the registrant in case of possible infringements or illegal actions. The email address serves as a prime data point for both notifying a potential victim and communicating with a potential infringer in an objective manner without necessarily identifying the domain name holder. The legal basis of article 6.1 (f) GDPR and the corresponding balancing exercise favour the rights and interests of several third parties, including law enforcement, commercial entities and intellectual property rights holders. The publication of the email address has a limited impact on the registrant. A registrant always retains the ability to register a domain name with an unidentifiable email address (example: info@organisation.com). There are numerous free email address providers available and a registrant may even opt to use a privacy or proxy service when registering the domain name. Additionally, at the registration of a domain name, a registrant is (and can always be) sufficiently informed about the publication and possible further use of essential “personal” information. In this regard, the data subject will have reasonable expectations that this information will be accessible in relation to the registered domain name. The risk for the registrant receiving unsolicited emails cannot outweigh the accountability and transparency necessary when operating a website or email address related to a domain name. Masking the email address of registrants unduly restricts the protection of consumers, and enforcement of intellectual property and commercial rights and prevents parties from amicably settling disputes related to potential online infringements. Should it be considered that the registrant’s privacy interest in keeping his (freely chosen) email address hidden overrides the provided legitimate third party interests, than at least an effective and standardised policy for replacing the email address with a pseudonymised email must be implemented. A pseudonymised email address would redact any information potentially identifying the registrant by providing a unique registrant-specific replacement email address which is non-identifiable. Taking into account the balancing exercise of article 6.1 (f) GDPR, such pseudonymisation, together with the limited impact on the data subject, would tilt the balance sufficiently in favour of the legitimate third party interests for having a reliable measure of contact which can be associated to multiple domain names belonging to the same owner. [Please refer to Opinion 06/2014 on the notion of legitimate interests of the data controller under Article 7 of Directive 95/46/EC of the Article 29 Working Party (currently the European Data Protection Board), p. 42-43.] Further, pseudonymising consistently across registrars in such a way that enables connecting registrants for research and dispute resolution expediency would prove prohibitively difficult. Web forms do not provide the same evidence of delivery as can be established by sending an email in the absence of subsequently receiving a “bounceback,” and web forms can impose unreasonable and unrealistic character limits. Finally, the IPC notes the letter from Dave Jevans to Göran Marby, Cherine Chalaby, and Rod Rasmussen sent on June 4, 2018 [https://www.icann.org/en/system/files/correspondence/jevans-to-marby-et-al-04jun18-en.pdf] that recommends “replacing plain text point of contact details with consistently hashed values, rather than redacting those POC details altogether. Consistently hashed values would allow an investigator or research to search registration data sets and to associate multiple domains that use the same POC details, while not disclosing the original POC data of a potential GDPR data subject.” We believe this, and similar mechanisms, should be explored more thoroughly and encourages SSAC to review and comment on the viability and utility of the proposal as a replacement for redaction. City is needed to serve legal process, identify proper venue for litigation, and understand which controlling law and procedure applies. For example, “San Francisco” would indicate that controlling precedent and procedure from the Northern District of California might apply to litigation concerning the domain name, where “San Diego” would indicate that completely different law and procedure from the Southern District of California would control.	No	The GDPR is only to be applied as written to natural persons, not legal persons. To redact an organization name is not at all required or supported through application of the GDPR. This is extremely valuable information to identify or get in touch with the legal owner of the domain or to track abusive behavior by or against persons and entities, including against the RNH. When, in rare instances, and organization name includes personal data, such as a natural person’s name, the person, in securing a license to do business under that name has provided clear consent in the use of that organization as a non-personal identifier. This is clearly stated in Recital 14 of the GDPR. Redacting the “organisation” field in the public WHOIS would not only go beyond the GDPR remit, it would go against other important EU regulatory frameworks related to (online) accountability and transparency of businesses and e-commerce in the EU. Article 5 of Directive 2000/31/EC on electronic commerce for example requires that online service providers shall render easily and permanently accessible the following information: (i) their name, (ii) their geographic address, (iii) their contact details, including their electronic email address , (iv) their trade or commercial register number, etc. According to article 46 of Directive 2017/1132/EU relating to certain aspects of company law, Member States are also required to disclose the particulars of company officers in central national company registers. This personal data is specifically considered to be of public interest and may be accessed by any third party. The organisation field normally does not contain any personal information as it pertains to legal entities to which the GDPR is not applicable. In the rare cases that the organisation reflects the name of an identifiable natural person, this person is required by EU law to disclose his (personal identifying) company information anyway. Redacting the organisation field would therefore go against other EU regulatory frameworks while not being necessary under the principles and obligations of the GDPR.		Support recommendation as written		The IPC supports the maintenance of the Organization field as this is not personal data and the GDPR does not cover legal entities. The IPC submits that, if an Organization name includes personal data, the individual whose name is included as part of the Organization name has filed the name as part of a license to bo business and therein has provided implicit and explicit consent of use of the name within the context of the Organization name and identity. Thus, the RHN should be provided with educational text around this and asked to provide the Organization name, if applicable.		Intent and wording of this recommendation requires amendment	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. 2.5.1.1. The email address MUST be unique and uniform across domain name registrations of the registrant at a given Registrar. 2.5.1.2. The email address and the URL to the web form MUST provide functionality to forward communications received to the email address of the applicable contact and MUST describe the methods used to forward communications and confirm their receipt. 2.5.1.3. Registrar MAY implement commercially reasonable safeguards to filter out spam and other form of abusive communications. 2.5.1.4. It MUST NOT be feasible to extract or derive the email address of the contact from the email address and the URL to the web form provided to facilitate email communication with the relevant contact.	At least an effective and standardised policy for replacing the email address with a pseudonymised email must be implemented. A pseudonymised email address would redact any information potentially identifying the registrant by providing a unique registrant-specific replacement email address which is non-identifiable. Taking into account the balancing exercise of article 6.1 (f) GDPR, such pseudonymisation, together with the limited impact on the data subject, would tilt the balance sufficiently in favour of the legitimate third party interests for having a reliable measure of contact which can be associated to multiple domain names belonging to the same owner. [Please refer to Opinion 06/2014 on the notion of legitimate interests of the data controller under Article 7 of Directive 95/46/EC of the Article 29 Working Party (currently the European Data Protection Board), p. 42-43.’		Support intent of recommendation with edits	The EPDP Team recommends that Registrars are required to retain the herein specified data elements for a period of three years following the life of the registration.	ICANN itself recommends a longer period of 2 years. Cybersecurity incidents have dwell time that can go years, as the recent Marriott/Starwood breach news proves. Attack indicators can be discovered long after the attack itself, and after DNS resources are deleted. Investigation, particularly when it involves law enforcement, can be lengthy. It’s important that information on previously registered domains is retained for a useful period for security and law enforcement needs. One year is simply not enough time for lookback needs. The consistent utilization, by security and LEA personnel, of historic data from various 3rd party Whois services is testament to the need.		On November 16, 2018, The EPDB issued Guidelines 3/2018 on the Territorial Scope of the GDPR. These Guidelines address the factors mentioned above. The Guidelines should be consulted by the EPDP Team as it considers the question of differentiating between registrants on a geographic basis. The Guidelines were issued following the expression of positions from contracted parties that it would not be feasible to distinguish between registrants on a geographic basis for the purposes of determining whether the GDPR should be applied. These positions should be reevaluated and further justified in light of the Guidelines, which suggest that it would be possible to agree that redactions to the data of registrants for the purposes of compliance with the GDPR should only be applied where: (a) the contracted party is collecting such data within the context of an establishment of the contracted party in an EU member state, or (b) the contracted party is targeting domain registration services to EU data subjects. The EPDP Team should continue to consider means to practically implement this principle, but the IPC submits that the principle itself should guide discussions, and not the purported impracticality of geographic differentiation.	The IPC is concerned that some have sought to globalize the application of the GDPR through the application of a policy that does not oblige contracted parties to apply a geographically limited law in a geographically limited manner. ICANN (and its policies) should not serve as a means to achieve global application of a law that has limited territorial application. ICANN should be primarily concerned with the the objectives set forth in its mission, which has from the inception of the WHOIS framework included the practice of collecting and displaying the information of domain registrants for the purposes of ensuring the security and stability and resiliency of the DNS. To the extent exceptions are required to accommodate national laws, the WHOIS Conflicts Policy was agreed. The purpose of this exercise is to determine how to accommodate exceptions to the collection and processing of data, as it existed prior to the GDPR, to accommodate the GDPR. The purpose should not be to maximize and globalize the application of the GDPR. While doing so may suit the objectives of some stakeholders, it would also raise the risk that some countries may seek to enact counterbalancing rules or laws to oblige disclosure of registrant data for what it considers to be legitimate purposes, leading to a more fractured and complex compliance landscape.	The question should also be posed, what are the risks of not differentiating on a geographic basis. Longer term, the risks to the status of ICANN as an independent multistakeholder organization are greater where the geographic limitations of laws are not practically acknowledged in the implementation of its policies.	The other factors to consider are the practicalities of application and looking to live examples of other businesses and entities that are differentiating between legal and natural persons because that is how the GDPR is set-up and it needs to be applied as intended, if not immediately, eventually. Therefore, if not required immediately, it should be required to be implemented within a reasonable timeframe when the technical set-up is commercially feasible. It is possible to set-up a self-identification system, with supportive educational language, alerting RNH to the definitions of legal and natural persons and to specify that any information provided is attested to be true, accurate and submitted to the best knowledge of the RNH. We note that in the GDPR Domain Industry Playbook v. 1.0 issued by eco it was recommended that “input from DPAs should be sought as to whether a distinction could be made based on a self-identification by the registrant.” Due account should be taken of existing registers (ccTLD, company, trademarks, etc.) to which the GDPR applies. Based on existing processes with various ccTLD registry operators, such as EURid, the distinction can be made based on the self-identification of the registrant together with clear information on the implications of each choice. The registrant must be made aware that the name and contact information of a legal person will be published and that he is responsible for providing non-identifiable contact information. With regard to natural persons designated as admin or technical contact, an option can be provided to redact the name of that person in case he/she is a natural person.	The distinction would prevent the over-application of the GDPR and allow for the required transparency and accountability online. The information of legal persons must be made available by default for law enforcement, consumer protection, anti-counterfeiting and cybersecurity purposes. In this regard, the EU E-Commerce Directive also requires legal entities who provide services to Internet users to be transparent and provide their identification and contact information in a direct and easily accessible manner (Art. 5 E-Commerce Directive 2000/31/EC). An incorrect self-identification could serve as an indication of bad faith and a legitimate reason for the registrar or registry to immediately disclose the identity and contact information of the underlying registrant upon request. The risks of making the above distinction would be minimal. Registrars would only be required to provide clear information so to avoid unnoticed or unintended publication of personal data. A person registering a domain name for a legal person is not required to provide contact information which are related to an identified or identifiable natural person as this contact information can easily be anonymized (i.e. domainadmin@company.com). In situations where it is difficult to separate the data of natural persons from that of legal persons, such as if the legal person is a sole proprietorship, if the name of a person appears in the company’s name, or if the business address is a natural person’s residence, this relevant (personal) information is also made public on a mandatory basis in the national company register where the legal entity is registered (see art. 30 and onwards of Directive 2017/1132). Registrars would not face an increased liability unless related to their transparency requirements. Sufficiently clear information must be provided to prevent a registrant from unwillingly disclosing personal data. With regard to the provision / collection of information, it is not required to discharge the registrant of all responsibility for providing non-identifiable information, as long as the registrant is properly informed.	The IPC supports a study showing live examples of the application of the natural and legal persons differentiation.	The .TEL gTLD has been making this distinction since at least 2006. See ICAA, TEL Registry Agreement, Appendix S, Part VI, Section B, (May 2016). Generally, in ccTLDS and certain gTLDs, a system of self-identification is implemented where a potential registrant must indicate whether it is a natural or legal person (most notably EURid for .eu, also DNS Belgium for .be, FICORA for .fi, AFNIC for .fr, SIDN for .nl, etc.). The registrant is informed of the implications of this choice (such as the publication of the legal person’s name and contact information) before registering. A registrant which is a legal person must then evaluate whether his contact information refers to an identified or identifiable natural person and adjust accordingly (or not). EURid’s Domain Name Whois Policy v. 4.0, Sections 2.3 - 2.4 provides that “those requesting to register a .eu Domain Name in one of the available scripts are required to provide certain information through an accredited Registrar. In respect of the name of the Registrant there are two fields: The first is 'Name' and the second is 'Company'. Both fields may be completed or just the 'Name' field. If only the first field is completed, it is assumed that the registration is in the name of a private individual (natural person). If the 'Company' field is completed, it is assumed that the company is the Registrant. … All Registrants are required to accept the Terms and Conditions in which the Registrant authorises the Registry to publish certain personal data. (i) When the Registrant is a legal person or another form of organisation the Registry generally publishes the following information in its WHOIS: a) name, address and telephone and fax number of the Registrant; b) technical contact person; c) e-mail address …”. [ Domain Name Whois Policy v. 4.0, EURid, available at https://eurid.eu/d/22380/whois_policy_en.pdf] The CENTR Report on WHOIS Status and Impacts from GDPR determined that “to differentiate between private and organisations as registrants, 68% of registries allow the registrant to self-select. In several cases, the registry uses social security number, business number or even tax file number. 18% make no distinction.” [CENTR Survey - Whois status and impacts from GDPR, June-July 2018, available at https://centr.org/library/library/survey-report/centr-report-whois-status-and-impacts-from-gdpr.html.] For trademark applications in the EU or national trademark registers, an applicant is asked whether he is a natural or a legal person. Irrespective of the distinction, the name and address of the applicant is always made publicly available, as this information is considered to be of public interest (article 111(9) Regulation 2017/1001). Finally Many ccTld registries differentiate between natural and legal person in the registration process. The extensive list below demonstrates that this differentiation is both practical and workable: .AT legal person data is publicly available in the whois and provides the organization, Street address, Postal code,City, Country, Phone , Email,Nic-hdl .BE legal person data is publicly available in the whois and provides the Organization, language, street address, city, country and phone. Contact form available .CZ legal person data is publicly available in the whois and provides registrant organization, street address, city, country and nic-handle. Also provides the same data fields for admin and tech contact. .DK treats natural and legal person data the same in the publicly available whois and provides registrant organization, street address, city, country and nic-handle. See .dk statement - https://www.dk-hostmaster.dk/en/gdpr .ES legal person data is publicly available in the whois and provides registrant org, admin contact name and name of technical contact .EU differentiates in the publicly available WHOIS record and provides the registrant name, language, city, country and email address. .FI legal person data is publicly available in the whois and provides the registrant name, street address, city, country and phone. Technical contact name and email address. .FR legal person data is publicly available in the whois and provides the registrant org, street address, city, country, phone and email address. Technical contact name, registrant org, street address, city, country, phone and email address. Admin contact, name, registrant org, street address, city, country, phone and email address. .IE legal person data is publicly available in the the whois and provides the registrant org, admin and tech nic-handles .IT legal person data is publicly available in the the whois and provides the registrant org, street address, city, country postal code, phone number and email address. Same data fields are available for admin and tech contact and includes individual names. .LT legal person data is publicly available in the the whois and provides the registrant org, street address, city, country postal code, phone number and email address. Same data fields are available for tech contact. .LV distinguishes between natural and legal person. Legal person data is publicly available in the the whois and provides the registrant org, street address, city, country postal code, phone number and email address. Same data fields are available for admin and tech contact and includes individual names. .LU legal person data is publicly available in the the whois and provides the registrant org, street address, city, country and postal code Admin and Tech contacts are masked. .MT legal person data is publicly available in the the whois and provides the registrant org, street address, city, country postal code, phone number and email address. Same data fields are available for admin and tech contact. .NL legal person data is publicly available in the the whois and provides the registrant org and admin email address. .PL legal person data is publicly available in the the whois and provides the registrant org, street address, city, country postal code. Indicates Organization in the record. .PT legal person data is publicly available in the the whois and provides the registrant org, street address, city, country postal code. Same data fields are available for managing body role. .SI legal person data is publicly available in the the whois and provides the registrant org, street address, city, country postal code, phone number and email address. Also provides Tech contact email address. .SE legal person data is publicly available in the the whois and provides the registrant org, street address, city, country postal code, phone number and Contact ID. Same data fields are available for admin and tech contact and includes individual names.	Support intent of recommendation with edits	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 NonPublic Registration Data has been completed AND INCORPORATED IN THE TEAM’S FINAL REPORT, noting that the term should be modified to refer to “parameters for responding to lawful disclosure requests.”	The Team’s work is incomplete until the issue of setting parameters for responding to lawful disclosure requests to redacted data has been resolved. A recommendation that lacks any deadline for achieving this resolution is equally defective. As noted above, the Temp Spec should not be superseded by a consensus policy that lacks a strong model for access to redacted data by legitimate third parties. In order to kick start the process, IPC proposes starting from and building upon the consensus policy already adopted (though not yet implemented) for privacy/proxy disclosures.		Support intent of recommendation with edits	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 or the appropriate Controller-Processor agreement with the Contracted Parties and the needed Data Processing Addendums.	The IPC believes that based on the factual and legal analysis conducted to date by the EPDP of the data elements processed by the respective parties (ICANN, the Registrars and Registries) that a joint controller relationship exists. It therefore supports this recommendation as the application, negotiation and installation of a Joint Controller Agreement and the needed Data Processing Addendums will proportionality make clear the roles and responsibilities of each party and the attributable respective liability of each party. It will therefore in sum lay out the needed legal framework and working solution for the update ICANN ecosystem in line with GDPR and data protection laws. If further findings on this topic result in a different determination of roles and responsibilities, the IPC ultimately supports the appropriate controller/processor arrangement that can enable ICANN to assume sufficient legal responsibility such that ICANN can compel relevant contracted parties to respond to Whois queries from accredited requestors, most likely as part of a Unified Access Model currently being explored by ICANN.			No, I wish to continue to the next section
47	12/22/2018 13:37:30	Brian King	MarkMonitor, Inc., a Clarivate Analytics company	Yes	I am submitting this comment on behalf of MarkMonitor, Inc.	No, I would like to continue to the next section	Support Purpose intent with wording change	(I) TO ESTABLISH THE RIGHTS AND OBLIGATIONS OF A REGISTERED NAME HOLDER IN A REGISTERED NAME;	MarkMonitor believes that limiting this purpose to establishing the “rights” of a registrant in the registered name is overly narrow. Referring to both the rights “and obligations” of the registrant more accurately reflects the practical and legal context in which a name is registered. For example, a registrant provides their contact details not only to establish their claim to a specific domain, but also for the purposes of the registrar and third parties being on notice that such domain is subject to the claim of the registrant. The registrant also agrees to certain obligations in connection with their registration, and the provision of their data is integral to establishing the identity of the registrant so that the registrar, registry operators and (potentially) third parties are able to identify the party which has undertaken such obligations, even beyond Purpose 3 which deals with communication.	Support Purpose intent with wording change	“ENSURING 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.”	ICANN’s mission is to ensure the stable and secure operation of the Internet’s unique identifier systems, which is a stronger imperative than “maintaining,” and requires that ICANN ensure access to domain registration data for law enforcement, cybersecurity, consumer protection, and intellectual property protection. Some parties contributing to this EPDP have argued that ICANN’s mission does not extend to matters concerning “the use of such domain names,” and that therefore ensuring third-party access is beyond ICANN’s remit. We do not find that argument persuasive in this context, and we do not ask for ICANN’s active involvement in any such investigation, dispute, or litigation. Rather, we submit that ICANN’s role should remain as has always been, as supported by its bylaws: to ensure that mechanisms exist which enable domain registration data to be made available for those who need it for legitimate purposes.	Support Purpose intent with wording change	“ENABLE COMMUNICATION WITH AND/OR NOTIFICATION TO THE REGISTERED NAME HOLDER AND/OR THEIR DELEGATED AGENTS OF TECHNICAL, LEGAL, AND/OR ADMINISTRATIVE ISSUES WITH A REGISTERED NAME.”	MarkMonitor believes that adding “legal” clarifies that communication should be enabled for legal issues involving a domain name, to the extent legal issues are not specifically within the “administrative” issues category. Enabling communication for legal issues ensures proper notice and due process where a domain name might implicate certain legal matters. Alternatively, “administrative issues” should be defined to include resolving claims that a domain name is being used to facilitate unlawful conduct, to infringe on the legitimate rights of others, and other legal matters involving a domain name. MarkMonitor also recommends that the EPDP team further define “administrative” (a term that never has been fully defined in this context) as inclusive of matters such as rights infringement or resolution of claims of unlawful conduct. These clarifications will further assist third parties reporting contractual violations, who will be able to discern a “delegated agent” for administrative issues.	Support Purpose as written			Support Purpose as written			Significant change required: changing intent and wording	“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, BUT INCLUDING WHERE SUCH POLICIES TAKE INTO ACCOUNT USE OF THE DOMAIN NAMES), NAMELY, THE UDRP, URS, PDDRP, RRDRP, AND ANY FUTURE DEVELOPED DOMAIN NAME REGISTRATION-RELATED DISPUTE PROCEDURES FOR WHICH IT IS ESTABLISHED THAT THE PROCESSING OF PERSONAL DATA IS NECESSARY. THIS PURPOSE SHOULD NOT BE READ TO LIMIT ANY OTHER PURPOSE WHERE PROCESSING OF DATA HAS BEEN RECOGNIZED AS LEGITIMATE IN CONNECTION WITH FACILITATING INVESTIGATION AND ACTION CONCERNING ANY OTHER LEGAL ISSUES INVOLVING A DOMAIN NAME, INCLUDING HOW A DOMAIN NAME IS USED.”	The language of the recommendation as currently written is not a full and accurate quotation from the ICANN Bylaws, which state, in pertinent part: The topics, issues, policies, procedures and principles referenced in Section 1.1(a)(i) with respect to gTLD [registrars/registries] are:…”resolution of disputes regarding the registration of domain names (as opposed to the use of such domain names, but including where such policies take into account use of the domain names)…” The most commonly-used dispute resolution mechanisms listed above (UDRP and URS) both take into account the use of domain names, so the exclusion of this language as drafted is problematic and must be corrected.	Support Purpose as written				A. A new purpose to address the needs and benefits provided by DNS security and stability research conducted through publication of reports on threats to the operational stability, reliability, security, global interoperability, resilience, and openness of the DNS, and on the accuracy of WHOIS. B. A new purpose to enable ICANN to conduct operations, facilitation activities, and implement consensus policies (adopted in accordance with the ICANN Bylaws) consistent with its mission of furthering the operational stability, reliability, global interoperability, resilience and openness of the DNS.	A. Research is a legitimate basis for processing per GDPR Article 6(1)f, with specific safeguards defined in Article 89. It is also squarely within ICANN’s mission and mandate, as the requirement for research derives from Section 1.2a (Commitments) of the ICANN bylaws: (i) Preserve and enhance the administration of the DNS and the operational stability, reliability, security, global interoperability, resilience, and openness of the DNS and the Internet; (ii) Maintain the capacity and ability to coordinate the DNS at the overall level and work for the maintenance of a single, interoperable Internet; This purpose exists to ensure that ICANN may continue to use registration data in support of its mission, while maintaining data subject privacy through appropriate safeguards such as pseudonymisation. In addition, this purpose enables ICANN to continue to operate its Accuracy Reporting System (ARS), which publishes periodic reports on accuracy, using full WHOIS contact fields. The ARS is an important program approved by the ICANN Board in response to the recommendations from the 1st WHOIS Review Team. B. Prior to the adoption of May 25th, and consistent with its mission and mandate under the Bylaws, ICANN used full WHOIS data as part of op/sec related activities of the Office of the CTO to collaborate with public/private sector investigators, to train law enforcement agencies in techniques for mitigating cybersecurity threats such as CONFLICKER, or to work with a compliance related complaint. It also used WHOIS as it implemented consensus policies that involve the use of WHOIS data fields (such as in transfer policy processes or Thick WHOIS). It is important that ICANN continue to provide these services to enhance the DNS.	No, I wish to continue to the next section	Support intent of recommendation with edits	Per the EPDP Team Charter, the EPDP Team is committed to answering the additional gating questions in the charter and recommending a system for Standardized Access to nonPublic Registration Data no later than submission of its Final Report. “In this context, amongst others, the EPDP Team will develop a policy that prescribes the method for disclosing non-public registrant data to third parties that have established legitimate interest in accessing registrant data including intellectual property rights holders, cybersecurity firms, organizations that mitigate DNS abuse, and law enforcement agencies.”	These additions reflect that the protection of intellectual property rights is expressly recognized as a legitimate interest under GDPR and therefore understood to be within scope of the final policy. The charter calls for the EPDP team to deliver an Initial Report outlining a proposed model of a system for providing accredited access to non-public Registration Data, not to “consider” doing so. The EPDP fails to fulfill its charter if it does deliver a model for a system for standardized access to non-public data. At a bare minimum the team should commit to a time certain to complete this work, and no consensus policy superseding the Temporary Specification should be adopted without it.	In the Article 29 Working Party’s letter to ICANN dated April 11, 2018, the A29WP “welcome[d] the decision of ICANN to propose an interim model which involves layered access, as well as an “accreditation program” for access to non-public WHOIS data.” This communication signaled A29WP’s support for a standardized access program. This support is further echoed, in a May 27 communication to ICANN, in which the EPDB reiterated that it expects ICANN “to develop and implement a WHOIS model which will enable legitimate uses by relevant stakeholders, such as law enforcement, of personal data concerning registrants in compliance with the GDPR, without leading to an unlimited publication of those data.” With respect to the reference to “relevant stakeholders,” ICANN has identified “intellectual property rights holders” as being such stakeholders with a legitimate interest in having access to registrant data. For the reasons expressed above and in deference to the statements provided, MarkMonitor recommends the edits provided above.	Intent and wording of this recommendation requires amendment	The EPDP Team recommends that this policy shall not interfere with accuracy requirements under current ICANN contracts and consensus policies nor interfere with ICANN’s ability to enforce accuracy requirements, including by being able to access full registration data (including any data elements that are redacted from publication in any registration directory) in order to assess data accuracy and enforce accuracy contractual requirements. This includes full access to registration data to enable the operation of the ICANN WHOIS Accuracy Reporting System (“ARS”) and all validation functions under the ARS. In addition, because of the data accuracy requirements imposed by the GDPR, the EPDP Team recommends that requirements be developed to increase the accuracy of registration data.	The accuracy requirements under the current contracts must at a minimum be maintained. According to Article 5.1(d) of the GDPR, personal data shall be "accurate and, where necessary, kept up to date; every reasonable step must be taken to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay." The ICO (Information Commissioner’s Office in the UK) points out in its writings on “Principle (d): Accuracy” that one of the new features of GDPR as compared to the principles under its predecessor is that there is now a “clearer proactive obligation to take reasonable steps to delete or correct inaccurate personal data.” In addition,the European Commission’s technical input on ICANN's proposed GDPR-compliant WHOIS models underscored the GDPR's "Accuracy" principle and made clear that “reasonable steps should be taken to ensure the accuracy of any personal data obtained” for WHOIS databases and that ICANN should be sure to incorporate this requirement in whatever model it adopts. Accuracy of domain name ownership is paramount to collection of WHOIS/Registered Name Holder data in the first instance. In addition, since this data will be used by others (with a lawful interest), ensuring that it is accurate for them is also relevant. Moreover, as demonstrated by the .dk ccTLD, when accuracy and validation of registration data is taken seriously, it leads to dramatic decreases in abuse and illegal activity on the top level domain. See: https://ccnso.icann.org/sites/default/files/field-attached/presentation-difo-increase-trust-25jun18-en.pdf Prior to the adoption of the Temporary Specification, accuracy of WHOIS data was problematic. When the ARS was running, we saw that almost 40% of randomly sampled registrations had a problem that warranted opening a compliance ticket. Without improved accuracy policy, it is likely that the quality of WHOIS data will decline further. Especially considering GDPR’s accuracy requirements, accuracy is an issue fully within scope of the EPDP, and should be included so that ICANN and contracted parties proactively address how they will ensure the accuracy of data in the first place, as well as how to rectify inaccurate data brought to their attention later.		No, I wish to continue to the next section	Yes		These data elements are required by ICANN to fulfill its Mission and are in line with ICANN’s pursuit of a legitimate interest in this data as well as the performance of the domain name registration contract to which the data subject is party. Therefore these data elements align to GDPR Article 6(1)b and 6(1)f.	Registrars should be required to provide an option for registered name holders to indicate they are either a Legal or Natural Person.	GDPR does not apply to Legal Persons. Allowing registered name holders to indicate they are such Persons creates the opportunity and legal basis needed to publish the appropriate data fields. Recital 14 of the GDPR - The protection afforded by this Regulation should apply to natural persons, whatever their nationality or place of residence, in relation to the processing of their personal data. This Regulation does not cover the processing of personal data which concerns legal persons and in particular undertakings established as legal persons, including the name and the form of the legal person and the contact details of the legal person.	Optional	MarkMonitor does not believe that collection of Technical Contact information should be “Mandatory”, however registrars should be required to offer the OPTION for registrants to provide this information. Many registrants wish to provide secondary contact information, including large corporate registrants who need to route the appropriate communications within their organization, and technically-novice registrants who need to enlist the help of an organization with greater technical expertise to manage their web presence. Even more registrants may simply want to list a backup contact for estate or succession planning or mere peace of mind of having a backup. If this were to be made optional for registrars, many registrants would, in effect, be deprived of their ability to choose to list a second contact, especially if they lack the sophistication to know they could choose a different registrar that allows them to do so. Further, registrants who have already designated a different technical contact could be deprived of the choice they have already made if their registrar is permitted to discontinue the service. Therefore, MarkMonitor believes that Registrars should be required to provide registrants with the “OPTION” to provide Technical Contact information, although provision of this alternative contact information by registrants should not be mandatory.	Yes	Registrars should be required to offer this OPTION for registrants to provide this information, since some registrants desire or need to provide this information for the purposes listed above. Many domain registrants will want to be contacted swiftly if anyone discovers a technical issue with their domain name.	Yes	Registrants have always been afforded the ability to enter different points of contact for different needs regarding the performance of their contract with the Registrar. ICANN’s stated goal with Whois is to keep it the same as much as possible. Therefore these fields should still be collected.		Yes		All data should be transferred to the registry including .com,.net and .jobs the only outstanding registries that continue to be “thin” registries. Policy development was completed on transitioning data from thin to thick for the remaining thin registries several years ago and GDPR should not affect the agreed upon policy. Transferring the data to the registry can be completed in a manner that is compliant with GDPR.		Support recommendation as written		In the interest of RNH protection, all data collected should be transferred to the data escrow provider.		Intent and wording of this recommendation requires amendment	Yes	MarkMonitor agrees that all the data elements listed in Workbook 5 be transferred from the registrar/registry to ICANN, and we also recommend that all RNH data collected by registrar/registry be transferred to ICANN.	If a registrar/registry collects registrant data it should be transferred to ICANN.		No	Registrant email address should not be redacted. City should not be redacted.	Email has been recognized as most important data element for law enforcement as well as DNS abuse, consumer protection, and IP rights violation investigations. In the balance of privacy and other rights and interests, it is appropriate that this data element remain unredacted and publicly accessible. This is particularly the case because a registrant has the ability to create, at no cost, an email address that contains no personal data, such as the registrant’s name. We recommend that in addition to the registrant’s email address remaining unredacted, that registrars inform registrants that their email address will not be redacted, will be publicly accessible and that the registrant may create a valid e-mail address for purposes of registering the relevant domain name which email address contains no personal data. The disclosure of a registrant's email address in a public WHOIS system is essential for the legitimate purpose of expeditiously contacting the registrant in case of possible infringements or illegal actions. The email address serves as a prime data point for both notifying a potential victim and communicating with a potential infringer in an objective manner without necessarily identifying the domain name holder. The legal basis of article 6.1 (f) GDPR and the corresponding balancing exercise favour the rights and interests of several third parties, including law enforcement, commercial entities and intellectual property rights holders. The publication of the email address has a limited impact on the registrant. A registrant always retains the ability to register a domain name with an unidentifiable email address (example: info@organisation.com). There are numerous free email address providers available and a registrant may even opt to use a privacy or proxy service when registering the domain name. Additionally, at the registration of a domain name, a registrant is (and can always be) sufficiently informed about the publication and possible further use of essential “personal” information. In this regard, the data subject will have reasonable expectations that this information will be accessible in relation to the registered domain name. The risk for the registrant receiving unsolicited emails cannot outweigh the accountability and transparency necessary when operating a website or email address related to a domain name. Masking the email address of registrants unduly restricts the protection of consumers, and enforcement of intellectual property and commercial rights and prevents parties from amicably settling disputes related to potential online infringements. Should it be considered that the registrant’s privacy interest in keeping his (freely chosen) email address hidden overrides the provided legitimate third party interests, than at least an effective and standardised policy for replacing the email address with a pseudonymised email must be implemented. A pseudonymised email address would redact any information potentially identifying the registrant by providing a unique registrant-specific replacement email address which is non-identifiable. Taking into account the balancing exercise of article 6.1 (f) GDPR, such pseudonymisation, together with the limited impact on the data subject, would tilt the balance sufficiently in favour of the legitimate third party interests for having a reliable measure of contact which can be associated to multiple domain names belonging to the same owner. [Please refer to Opinion 06/2014 on the notion of legitimate interests of the data controller under Article 7 of Directive 95/46/EC of the Article 29 Working Party (currently the European Data Protection Board), p. 42-43.] Further, pseudonymising consistently across registrars in such a way that enables connecting registrants for research and dispute resolution expediency would prove prohibitively difficult. Web forms do not provide the same evidence of delivery as can be established by sending an email in the absence of subsequently receiving a “bounceback,” and web forms can impose unreasonable and unrealistic character limits. City is needed to serve legal process, identify proper venue for litigation, and understand which controlling law and procedure applies. For example, “San Francisco” would indicate that controlling precedent and procedure from the Northern District of California might apply to litigation concerning the domain name, where “San Diego” would indicate that completely different law and procedure from the Southern District of California would control.	No	GDPR is only to be applied as written to natural persons, not legal persons. To redact an organization name is not at all required or supported through application fo the GDPR. This is extremely valuable information to identify or contact the legal owner of the domain or to track abusive behavior by or against persons and entities, including against the RNH. When, in rare instances, and organization name includes personal data, such as a natural person’s name, the person, in securing a license to do business under that name has provided clear consent in the use of that organization as a non-personal identifier. Redacting the “organisation” field in the public WHOIS would not only go beyond the GDPR remit, it would go against other important EU regulatory frameworks related to (online) accountability and transparency of businesses and e-commerce in the EU. Article 5 of Directive 2000/31/EC on electronic commerce for example requires that online service providers shall render easily and permanently accessible the following information: (i) their name, (ii) their geographic address, (iii) their contact details, including their electronic email address, (iv) their trade or commercial register number, etc. According to article 46 of Directive 2017/1132/EU relating to certain aspects of company law, Member States are also required to disclose the particulars of company officers in central national company registers. This personal data is specifically considered to be of public interest and may be accessed by any third party. The organisation field normally does not contain any personal information as it pertains to legal entities to which the GDPR is not applicable. In the rare cases that the organisation reflects the name of an identifiable natural person, this person is required by EU law to disclose his (personal identifying) company information anyway according to EU law. Redacting the organisation field would therefore go against other EU regulatory frameworks while not being necessary under the principles and obligations of the GDPR.		Support recommendation as written				Intent and wording of this recommendation requires amendment	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.	The number of domains listed per UDRP filing is down over 10% since May 25, 2018, evidencing increased difficulty in connecting infringing domain names in UDRP filings. Pseudonymising consistently across registrars in such a way that enables connecting registrants for research and dispute resolution expediency would prove prohibitively difficult, so the email address must be identified in its true form. Web forms do not function as a unique identifier as an email address does, and do not provide the same evidence of delivery as can be established by sending an email in the absence of subsequently receiving a “bounceback,” and web forms can impose unreasonable and unrealistic character limits.		Support intent of recommendation with edits			ICANN recommends a longer period, 2 years. Cybersecurity incidents have dwell time that can go years, as recent breach news proves. Attack indicators can be discovered long after the attack itself, and after DNS resources are deleted. Investigation, particularly when it involves law enforcement, can be lengthy. It’s important that information on previously registered domains is retained for a useful period for security and law enforcement needs. One year is not enough time for lookback needs. The consistent utilization, by security and LEA personnel, of historic data from various 3rd party WHOIS services is testament to the need.	On November 16, 2018, the EPDB issued Guidelines 3/2018 on the Territorial Scope of the GDPR. The Guidelines should be consulted by the EPDP Team as it considers the question of differentiating between registrants on a geographic basis. The Guidelines were issued following the expression of positions from contracted parties that it would not be feasible to distinguish between registrants on a geographic basis for the purposes of determining whether the GDPR should be applied. These positions should be reevaluated and further justified in light of the Guidelines, which suggest that it would be possible to agree that redactions to the data of registrants for the purposes of compliance with the GDPR should only be applied where: (a) the contracted party is collecting such data within the context of an establishment of the contracted party in an EU member state, or (b) the contracted party is targeting domain registration services to EU data subjects. The EPDP Team should continue to consider means to practically implement this principle, but the IPC submits that the principle itself should guide discussions, and not the purported impracticality of geographic differentiation.	MarkMonitor is concerned that some have sought to globalize the application of the GDPR through the application of a policy that does not oblige contracted parties to apply a geographically limited law in a geographically limited manner. ICANN (and its policies) should not serve as a means to achieve global application of a law that has limited territorial application. ICANN should be primarily concerned with the the objectives set forth in its mission, which has from the inception of the WHOIS framework included the practice of collecting and displaying the information of domain registrants for the purposes of ensuring the security and stability and resiliency of the DNS. To the extent exceptions are required to accommodate national laws, the WHOIS Conflicts Policy was agreed. The purpose of this exercise it to determine how to accommodate exceptions to the collection and processing of data, as it existed prior to the GDPR, to accommodate the GDPR. The purpose should not be to maximize and globalize the application of the GDPR, which would also raise the risk that some countries may seek to enact counterbalancing rules or laws to oblige disclosure of registrant data for what it considers to be legitimate purposes, leading to a more fractured and complex compliance landscape.	The question should also be posed, what are the risks of not differentiating on a geographic basis. Longer term, the risks to the status of ICANN as an independent multistakeholder organization are greater where the geographic limitations of laws are not practically acknowledged in the implementation of its policies.	The other factors to consider are the practicalities of application and looking to live examples of other businesses and entities that are differentiating between legal and natural persons because that is how the GDPR is set-up and it needs to be applied as intended, if not immediately, eventually. Therefore, if not required immediately, it should be required to be implemented within a reasonable timeframe when the technical set-up is commercially feasible. It is possible to set-up a self-identification system, with supportive educational language, alerting RNH to the definitions of legal and natural persons and to specify that any information provided is attested to be true, accurate and submitted to the best knowledge of the RNH. We note that in the GDPR Domain Industry Playbook v. 1.0 issued by eco it was recommended that “input from DPAs should be sought as to whether a distinction could be made based on a self-identification by the registrant.” Due account should be taken of existing registers (ccTLD, company, trademarks, etc.) to which the GDPR applies. Based on existing processes with various ccTLD registry operators, such as EURid, the distinction can be made based on the self-identification of the registrant together with clear information on the implications of each choice. The registrant must be made aware that the name and contact information of a legal person will be published and that he is responsible for providing non-identifiable contact information. With regard to natural persons designated as admin or technical contact, an option can be provided to redact the name of that person in case he/she is a natural person.	The distinction would prevent the over-application of the GDPR and allow for the required transparency and accountability online. The information of legal persons must be made available by default for law enforcement, consumer protection, anti-counterfeiting and cybersecurity purposes. In this regard, the EU E-Commerce Directive also requires legal entities who provide services to Internet users to be transparent and provide their identification and contact information in a direct and easily accessible manner (Art. 5 E-Commerce Directive 2000/31/EC). An incorrect self-identification could serve as an indication of bad faith and a legitimate reason for the registrar or registry to immediately disclose the identity and contact information of the underlying registrant upon request. The risks of making the above distinction would be minimal. Registrars would only be required to provide clear information so to avoid unnoticed or unintended publication of personal data. A person registering a domain name for a legal person is not required to provide contact information which are related to an identified or identifiable natural person as this contact information can easily be anonymized (i.e. domainadmin@company.com). In situations where it is difficult to separate the data of natural persons from that of legal persons, such as if the legal person is a sole proprietorship, if the name of a person appears in the company’s name, or if the business address is a natural person’s residence, this relevant (personal) information is also made public on a mandatory basis in the national company register where the legal entity is registered (see art. 30 and onwards of Directive 2017/1132). Registrars would not face an increased liability unless related to their transparency requirements. Sufficiently clear information must be provided to prevent a registrant from unwillingly disclosing personal data. With regard to the provision / collection of information, it is not required to discharge the registrant of all responsibility for providing non-identifiable information, as long as the registrant is properly informed.	This appears to be feasible but impractical. It does not appear that the outcome of this study would be useful; instead MarkMonitor supports a study showing live examples of the application of the natural and legal persons differentiation.	The .TEL gTLD has been making this distinction since at least 2006. See TEL Registry Agreement, Appendix S, Part VI, Section B, (May 2016). Generally, in ccTLDS and certain gTLDs, a system of self-identification is implemented where a potential registrant must indicate whether it is a natural or legal person (most notably EURid for .eu, and others below). The registrant is informed of the implications of this choice (such as the publication of the legal person’s name and contact information) before registering. A registrant which is a legal person must then evaluate whether his contact information refers to an identified or identifiable natural person and adjust accordingly (or not). EURid’s Domain Name Whois Policy v. 4.0, Sections 2.3 - 2.4 provides that “those requesting to register a .eu Domain Name in one of the available scripts are required to provide certain information through an accredited Registrar. In respect of the name of the Registrant there are two fields: The first is 'Name' and the second is 'Company'. Both fields may be completed or just the 'Name' field. If only the first field is completed, it is assumed that the registration is in the name of a private individual (natural person). If the 'Company' field is completed, it is assumed that the company is the Registrant. … All Registrants are required to accept the Terms and Conditions in which the Registrant authorises the Registry to publish certain personal data. (i) When the Registrant is a legal person or another form of organisation the Registry generally publishes the following information in its WHOIS: a) name, address and telephone and fax number of the Registrant; b) technical contact person; c) e-mail address …”. [ Domain Name Whois Policy v. 4.0, EURid, available at https://eurid.eu/d/22380/whois_policy_en.pdf] The CENTR Report on WHOIS Status and Impacts from GDPR determined that “to differentiate between private and organisations as registrants, 68% of registries allow the registrant to self-select. In several cases, the registry uses social security number, business number or even tax file number. 18% make no distinction.” [CENTR Survey - Whois status and impacts from GDPR, June-July 2018, available at https://centr.org/library/library/survey-report/centr-report-whois-status-and-impacts-from-gdpr.html.] For trademark applications in the EU or national trademark registers, an applicant is asked whether he is a natural or a legal person. Irrespective of the distinction, the name and address of the applicant is always made publicly available, as this information is considered to be of public interest (article 111(9) Regulation 2017/1001). .AT legal person data is publicly available in the whois and provides the organization, Street address, Postal code,City, Country, Phone , Email,Nic-hdl .BE legal person data is publicly available in the whois and provides the Organization, language, street address, city, country and phone. Contact form available .CZ legal person data is publicly available in the whois and provides registrant organization, street address, city, country and nic-handle. Also provides the same data fields for admin and tech contact. .DK treats natural and legal person data the same in the publicly available whois and provides registrant organization, street address, city, country and nic-handle. See .dk statement - https://www.dk-hostmaster.dk/en/gdpr .ES legal person data is publicly available in the whois and provides registrant org, admin contact name and name of technical contact .EU differentiates in the publicly available WHOIS record and provides the registrant name, language, city, country and email address. .FI legal person data is publicly available in the whois and provides the registrant name, street address, city, country and phone. Technical contact name and email address. .FR legal person data is publicly available in the whois and provides the registrant org, street address, city, country, phone and email address. Technical contact name, registrant org, street address, city, country, phone and email address. Admin contact, name, registrant org, street address, city, country, phone and email address. .IE legal person data is publicly available in the the whois and provides the registrant org, admin and tech nic-handles .IT legal person data is publicly available in the the whois and provides the registrant org, street address, city, country postal code, phone number and email address. Same data fields are available for admin and tech contact and includes individual names. .LT legal person data is publicly available in the the whois and provides the registrant org, street address, city, country postal code, phone number and email address. Same data fields are available for tech contact. .LV distinguishes between natural and legal person. Legal person data is publicly available in the the whois and provides the registrant org, street address, city, country postal code, phone number and email address. Same data fields are available for admin and tech contact and includes individual names. .LU legal person data is publicly available in the the whois and provides the registrant org, street address, city, country and postal code Admin and Tech contacts are masked. .MT legal person data is publicly available in the the whois and provides the registrant org, street address, city, country postal code, phone number and email address. Same data fields are available for admin and tech contact. .NL legal person data is publicly available in the the whois and provides the registrant org and admin email address. .PL legal person data is publicly available in the the whois and provides the registrant org, street address, city, country postal code. Indicates Organization in the record. .PT legal person data is publicly available in the the whois and provides the registrant org, street address, city, country postal code. Same data fields are available for managing body role. .SI legal person data is publicly available in the the whois and provides the registrant org, street address, city, country postal code, phone number and email address. Also provides Tech contact email address. .SE legal person data is publicly available in the the whois and provides the registrant org, street address, city, country postal code, phone number and Contact ID. Same data fields are available for admin and tech contact and includes individual names.	Intent and wording of this recommendation requires amendment	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 NonPublic Registration Data has been completed and incorporated in the Team’s Final Report, noting that the term should be modified to refer to “parameters for responding to lawful disclosure requests.”	Third parties that currently have a legitimate interest and lawful purpose for gaining access to non-public registrant data face a confusing array of different registrar and registry requirements and processes to access this data making such access extremely difficult, inefficient and, in many cases, non-existent. According to a survey conducted by INTA, the redaction of registrant data has made enforcement of intellectual property rights more difficult. MarkMonitor recently published data revealing that nearly 80% of the requests for registrant data made to registrars have been either ignored or denied. While the EPDP Team works on a future policy regarding standardized access as referenced in Recommendation #2, the EPDP Team should now also define and develop simple processes around “reasonable access” and make sure that implementation details of these processes are completed within this EPDP and not delayed until future discussions regarding implementation. The Team’s work is incomplete until the issue of setting parameters for responding to lawful disclosure requests to redacted data has been resolved. A recommendation that lacks any deadline for achieving this resolution is equally defective. As noted above, the Temp Spec should not be superseded by a consensus policy that lacks a strong model for access to redacted data by legitimate third parties. In order to kick start the process, MarkMonitor supports starting from and building upon the consensus policy already adopted (though not yet implemented) for privacy/proxy disclosures.		Support intent of recommendation with edits	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 or the appropriate Controller-Processor agreement with the Contracted Parties and the needed Data Processing Addendums.	MarkMonitor believes that based on the factual and legal analysis conducted by the EPDP Team of the data elements processed by the respective parties (ICANN, the Registrars and Registries) that a joint controller relationship should exist. While we are open-minded as to the controllership scenario, we support formalizing a legal relationship that allows ICANN to enforce data disclosure requests made under reasonable access requirements and future accredited access requirements. Accordingly, we support this recommendation as to installing a Joint Controller Agreement and Data Processing Addendums, as necessary, to clarify the roles, responsibilities, and liabilities of the parties, thereby establishing the required legal framework and working solution to bring the ICANN ecosystem in line with GDPR.			No, I wish to continue to the next section
48	12/22/2018 13:59:08	Neil Fried	The Motion Picture Association of America	Yes	The Motion Picture Association of America	No, I would like to continue to the next section	Support Purpose intent with wording change	AS SUBJECT TO REGISTRY AND REGISTRAR TERMS, CONDITIONS AND POLICIES, AND ICANN CONSENSUS POLICIES: (I) TO ESTABLISH THE RIGHTS AND OBLIGATIONS OF A REGISTERED NAME HOLDER IN A REGISTERED NAME; (II) TO ENSURE THAT A REGISTERED NAME HOLDER MAY EXERCISE ITS RIGHTS AND FULFILL ITS OBLIGATIONS IN THE USE AND DISPOSITION OF THE REGISTERED NAME; AND (III) TO ACTIVATE A REGISTERED NAME AND ALLOCATE IT TO THE REGISTERED NAME HOLDER	ICANN, registrars, registry operators, and registered domain name holders have long been subject to certain requirements regarding registration of a domain name. For example, the Registrar Accreditation Agreement requires that “[t]he Registered Name Holder shall represent that, to the best of the Registered Name Holder's knowledge and belief, neither the registration of the Registered Name nor the manner in which it is directly or indirectly used infringes the legal rights of any third party,” RAA, sec. 3.7.7.9 (emphasis added), https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en#raa. Similarly, the Registry Agreement provides that the “Registry Operator will include a provision in its Registry-Registrar Agreement that requires Registrars to include in their Registration Agreements a provision prohibiting Registered Name Holders from distributing malware, abusively operating botnets, phishing, piracy, trademark or copyright infringement, fraudulent or deceptive practices, counterfeiting or otherwise engaging in activity contrary to applicable law, and providing (consistent with applicable law and any related procedures) consequences for such activities including suspension of the domain name,” Registry Agreement, Specification 11, sec. 3(a) (emphasis added), https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-31jul17-en.html#specification11. Ensuring compliance with obligations such as these will require collection and processing of data as part of the WHOIS system, including providing access to third parties.	Support Purpose intent with wording change	ENSURING THE SECURITY, STABILITY, AND RESILIENCY OF THE DOMAIN NAME SYSTEM IN ACCORDANCE WITH ICANN'S MISSION, COMMITMENTS, AND CORE VALUES THROUGH THE ENABLING OF LAWFUL ACCESS TO DATA ELEMENTS FOR LEGITIMATE THIRDPARTY INTERESTS OF LAW ENFORCEMENT, CYBERSECURITY, CONSUMER PROTECTION, INTELLECTUAL PROPERTY RIGHTS PROTECTION, COMBATTING DOMAIN NAME SYSTEM ABUSE, COLLECTED AND FOR THE OTHER PURPOSES IDENTIFIED HEREIN	For the sake of clarity and notice, this purpose should specifically identify as permissible the collection and processing of data for the long acknowledged legitimate interests of law enforcement, cybersecurity, consumer protection, and combatting intellectual property infringement and domain name abuse, including for investigations and enforcement actions related to those interests. Providing this added is consistent with Article 13(1) of the GDPR and the April 2018 letter from the Article 29 Data Protection Working Party to Göran Marby, both of which indicate that notice should be provided regarding the purposes for processing data. See GDPR, art. 13(1), https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679&from=EN; Letter from ARTICLE 29 Data Protection Working Party to Göran Marby, President and CEO, ICANN, April 11, 2018, https://www.icann.org/en/system/files/correspondence/jelinek-to-marby-11apr18-en.pdf.	Support Purpose intent with wording change	ENABLE COMMUNICATION WITH AND/OR NOTIFICATION TO THE REGISTERED NAME HOLDER AND/OR THEIR DELEGATED AGENTS OF TECHNICAL, LEGAL, AND/OR ADMINISTRATIVE ISSUES WITH A REGISTERED NAME, or for other purposes identified herein.	Communication with a registrant may be necessary to fulfill purposes identified herein that go beyond technical and administrative issues, and such communication will require the collection and processing of data as part of the WHOIS system, including sharing with third parties.				Support Purpose as written		ICANN, registry operators, registrars, and registered domain name holders are subject to a variety of contractual and other obligations. See, e.g., Registrar Accreditation Agreement, sec. 3.7.7.9 (requiring the registered name holder to refrain from using the domain name in a manner that infringes the legal rights of any third party), https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en#raa; Registry Agreement, Specification 11, sec. 3(a) (providing that the registry operator will require registrars to prohibit registered name holders from engaging in illicit activity, such as “distributing malware, abusively operating botnets, phishing, piracy, trademark or copyright infringement, fraudulent or deceptive practices, [and] counterfeiting), https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-31jul17-en.html#specification11. Ensuring compliance with obligations such as these will require the collection and processing of WHOIS data, including providing access to third parties.	Significant change required: changing intent and wording	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, but including where such policies take into account use of the domain names), NAMELY, THE UDRP, URS, PDDRP, RRDRP, AND FUTURE DEVELOPED DOMAIN NAME REGISTRATIONRELATED DISPUTE PROCEDURES FOR WHICH IT IS ESTABLISHED THAT THE PROCESSING OF PERSONAL DATA IS NECESSARY.	Eligibility for grant or renewal of a domain name is subject to certain conditions on use. See, e.g., Registrar Accreditation Agreement, sec. 3.7.7.9 (requiring the registered name holder to refrain from using the domain name in a manner that infringes the legal rights of any third party), https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en#raa; Registry Agreement, Specification 11, sec. 3(a) (providing that the registry operator will require registrars to prohibit registered name holders from engaging in illicit activity, such as “distributing malware, abusively operating botnets, phishing, piracy, trademark or copyright infringement, fraudulent or deceptive practices, [and] counterfeiting), https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-31jul17-en.html#specification11. Section 1.1 of the ICANN bylaws provides that ICANN’s mission includes coordinating the development and implementation of policies with respect to gTLD registrars and registries in the areas described by annexes G-1 and G-2. See ICANN Bylaws, Sec. 1.1(i)(a), https://www.icann.org/resources/pages/governance/bylaws-en/. Annexes G-1, in turn, state that “[t]he topics, issues, policies, procedures and principles referenced in Section 1.1(a)(i) with respect to gTLD registrars” include “resolution of disputes regarding the registration of domain names (as opposed to the use of such domain names, but including where such policies take into account use of the domain names).” Id., Annex G-1 (emphasis added). Purpose #6 should thus reflect the fact that misuse of a domain name is relevant to domain name eligibility, and that collection and processing of data as part of the WHOIS system, including sharing with third parties, is necessary to coordinate, operationalize, and facilitate policies on such eligibility and resolution of disputes.	Support Purpose as written		Eligibility for a domain name can turn on policies regarding misuse of domain names. See, e.g., Registrar Accreditation Agreement, sec. 3.7.7.9 (requiring the registered name holder to refrain from using the domain name in a manner that infringes the legal rights of any third party), https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en#raa; Registry Agreement, Specification 11, sec. 3(a) (providing that the registry operator will require registrars to prohibit registered name holders from engaging in illicit activity, such as “distributing malware, abusively operating botnets, phishing, piracy, trademark or copyright infringement, fraudulent or deceptive practices, [and] counterfeiting), https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-31jul17-en.html#specification11.The collection and processing of data as part of the WHOIS system, including access by third parties, is necessary to determine whether such misuse has occurred.		Additional Purpose 1: Promoting the transparency, accountability, and trust necessary to ensure a safe, secure, and supportive environment online for communication, commerce, innovation, and creativity—such as by combating illicit online conduct and ensuring public safety, consumer protection, law enforcement, dispute resolution, protection of intellectual property, prevention of domain name abuse, and enforcement of rights—as well as to provide access to third-parties and law enforcement authorities for such purposes. Additional Purpose 2: To facilitate analysis regarding misuse of domain names in deciding whether to create additional gTLDs, as well as to create or amend policies regarding the misuse of gTLDs.	Rationale for Additional Purpose 1: Since before the dawn of the commercial internet, access to WHOIS data has been a cornerstone of the transparency, accountability, and trust necessary to ensure a safe, secure, and supportive online environment for communication, commerce, innovation, and creativity. As ICANN itself notes, the Internet Engineering Task Force began publishing a protocol for a directory service in 1982 that listed the contact information of anyone transmitting data across the ARPANET. See History of WHOIS, ICANN WHOIS, https://whois.icann.org/en/history-whois (last visited Dec. 11, 2018). “As the Internet grew,” that system “began to serve the needs of different stakeholders such as domain name registrants, law enforcement agents, intellectual property and trademark owners, businesses and individual users.” Id. Access to WHOIS information is critical to creating the transparency, accountability, and trust that is fundamental to the multistakeholder model of internet governance, and that all internet users need to be comfortable interacting online. Without reliable and timely access to WHOIS data, individuals and businesses will have difficulty determining—when necessary—whom they are engaging with online, whether to verify the identity of the entity; to find a contact for purposes of conveying information, preferences, questions, and concerns; or to seek redress for mistakes and harms. Moreover, law enforcement and other entities will have a harder time investigating, preventing, and mitigating illicit behavior online. Promoting a safe and secure online environment—as well as the collection, processing, and sharing of registration data to accomplish that purpose—is perfectly consistent with the European Union’s General Data Protection Regulation. WHOIS data had been publicly available prior to the May 2018 adoption of the Temporary Specification, and domain name registrants have long been on notice that they must provide certain information that will be publicly disclosed, including for matters of public safety, consumer protection, law enforcement, dispute resolution, protection of intellectual property, and enforcement of rights—reducing expectations of privacy. Moreover, the GDPR acknowledges that a variety of interests can warrant collection and disclosure, such as public safety, law enforcement and investigation, enforcement of rights or a contract, fulfillment of a legal obligation, cybersecurity, and preventing fraud. See GDPR, arts. 2(2)(d), 5(1)(b), 6, 23, https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679&from=EN. See also ICANN, GOVERNMENTAL ADVISORY COMMITTEE, Communiqué—San Juan, Puerto Rico (Mar. 15, 2018) (stating that the GDPR allows for access to data for legitimate purposes), https://gac.icann.org/advice/communiques/20180315_icann61%20gac%20communique_finall.pdf. Promoting a safe and secure online environment is also consistent with ICANN’s Bylaws. Section 1.1, for example, provides that ICANN’s mission includes coordinating the development and implementation of policies with respect to gTLD registrars and registries in the areas described by annexes G-1 and G-2. See ICANN Bylaws, Sec. 1.1(i)(a), https://www.icann.org/resources/pages/governance/bylaws-en/. Annexes G-1 and G2, in turn, include “issues for which uniform or coordinated resolution is reasonably necessary to facilitate interoperability, security and/or stability of the Internet”; “resolution of disputes regarding the registration of domain names (as opposed to the use of such domain names, but including where such policies take into account use of the domain names)”; and “reservation of registered names in a TLD … that may not be renewed due to reasons reasonably related to … intellectual property” (emphasis added). Similarly, Section 4.6(e)(ii) provides that ICANN will periodically “assess the effectiveness of the then current gTLD registry directory service and whether its implementation meets the legitimate needs of law enforcement, promoting consumer trust and safeguarding registrant data” (emphasis added). Thus, it is in ICANN’s remit to ensure WHOIS data remains accessible to promote the safety and the security of the internet itself, not just the safety and security of the domain name system, as well as to protect intellectual property. To be clear, these purposes have nothing to do with curbing or discriminating against particular internet expression, but rather are related to combatting illegal conduct, including unauthorized dissemination of copyrighted material. Detailing these purposes is consistent with Article 13(1) of the GDPR and the April 2018 letter from the Article 29 Data Protection Working Party to Göran Marby, both of which indicate that notice should be provided regarding the purposes for processing data. See GDPR, art. 13(1), https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679&from=EN; Letter from ARTICLE 29 Data Protection Working Party to Göran Marby, President and CEO, ICANN, April 11, 2018, https://www.icann.org/en/system/files/correspondence/jelinek-to-marby-11apr18-en.pdf. Rationale for Additional Purpose 2: ICANN’s mission includes adopting policies regarding the creation of additional gTLDs. Misuse of gTLDs’s is relevant in determining whether to create such additional gTLDs, and whether to expand existing policies or create new ones regarding misuse. Analysis of misuse will require collection and processing of data as part of the WHOIS system, including sharing with third parties.	No, I wish to continue to the next section	Support intent of recommendation with edits	Per the EPDP Team Charter, the EPDP Team is committed to developing a system for Standardized Access to non-public Registration Data once the gating questions in the charter have been answered, such as the proposal from ICANN for a unified access model, or through other means that ICANN has suggested exploring, including ICANN assuming legal responsibility for providing access as a sole controller. See Göran Marby, ICANN President and CEO, ICANN GDPR and Data Protection/Privacy Update, ICANN (Sept. 24, 2018), https://www.icann.org/news/blog/icann-gdpr-and-data-protection-privacy-update. In this context, amongst others, this will include disclosure to law enforcement authorities and third parties in the course of intellectual property infringement and DNS abuse cases will be considered.	The two instances of the word “considering” suggests the ePDP might conclude that no such standardized model should be created, and that disclosure is not necessary in intellectual property infringement cases. Failure to adopt a standardized model is contrary to the ePDP Charter, which states that work on a standardized model “shall begin once the gating questions above have been answered and finalized in preparation for the Temporary Specification initial report.” ePDP Charter at 7 (emphasis added), https://gnso.icann.org/sites/default/files/file/field-file-attach/temp-spec-gtld-rd-epdp-19jul18-en.pdf. Similarly, failure to disclose to law enforcement authorities and third parties in intellectual property infringement cases would be contrary to the longstanding purpose of the WHOIS system to thwart such infringement. As ICANN itself notes, the Internet Engineering Task Force began publishing a protocol for a directory service in 1982 that listed the contact information of anyone transmitting data across the ARPANET. See History of WHOIS, ICANN WHOIS, https://whois.icann.org/en/history-whois (last visited Dec. 11, 2018). “As the Internet grew,” that system “began to serve the needs of different stakeholders such as domain name registrants, law enforcement agents, intellectual property and trademark owners, businesses and individual users.” Id. (emphasis added).		Intent and wording of this recommendation requires amendment	Current ICANN contracts and consensus policies may need to be revised—and registration data may need to be collected, processed and shared with third parties—to ensure the accuracy of registration data.	The WHOIS system can only be as successful in meeting its purposes as it is accurate. Entities providing data, as well as those entities relying on such data for legitimate purposes, have legitimate expectations that such data will be kept up to date and accurate. If that were not enough, the GDPR creates obligations to ensure data that is collected, processed, and shared is accurate. See GDPR art. 5(1)(d), https://eur-lex.europa.eu/legal-content/EN/TXT/?qid=1528874672298&uri=CELEX%3A32016R0679. For both reasons, and in light of the fact that substantial data inaccuracies continue to persist within the WHOIS system, it stands to reason that current policies may be insufficient and require revision, and that data may need to be shared with third parties for purposes of verification, updating, and correction.		No, I wish to continue to the next section	Yes																				Support recommendation as written	Yes			ICANN, registrars, registry operators, and registered domain name holders have long been subject to certain requirements. See, e.g., Registrar Accreditation Agreement, sec. 3.7.7.9 (requiring the registered name holder to refrain from using the domain name in a manner that infringes the legal rights of any third party), https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en#raa; Registry Agreement, Specification 11, sec. 3(a) (providing that the registry operator will require registrars to prohibit registered name holders from engaging in illicit activity, such as “distributing malware, abusively operating botnets, phishing, piracy, trademark or copyright infringement, fraudulent or deceptive practices, [and] counterfeiting), https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-31jul17-en.html#specification11. Ensuring compliance with those obligations will require collection and processing of data as part of the WHOIS system, including providing access to third parties.	No	City and Email should not be redacted.	City of residence is not sensitive personal information. Email addresses are critical data points for combatting illicit activity and DNS abuse—including intellectual property infringement—as well as for purposes of consumer protection and public safety. Combatting the harm to consumers and businesses posed by illicit use of domain names outweighs the slight privacy interest in an email address of a domain name holder, especially since the domain name holder is willingly engaging in public-facing activity. Significantly, a registrant can easily select an email address that does not disclose sensitive information, if he or she chooses. For purposes of notice, registrars should inform registrants that their email address will not be redacted.	No	The GDPR applies only to information about “natural persons.” See GDPR, art. 1 (describing the subject matter and objectives of the regulation as relating to the protection of natural persons), https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679&from=EN. The GDPR thus imposes no obligation to obfuscate information about businesses or other legal entities. Because access to such information is necessary to promote the transparency, accountability, and trust that is critical to promote commerce, communications, and creativity online, as well as for purposes of consumer protection, law enforcement, and enforcement of intellectual property and other rights, such information should remain available. This is also consistent with ICANN President and CEO Göran Marby’s comments making “it a high priority to find a path forward to ensure compliance with the GDPR while maintaining WHOIS to the greatest extent possible.” Data Protection and Privacy Update—Plans for the New Year, ICANN Blog (Dec. 21, 2017), https://www.icann.org/news/blog/data-protection-and-privacy-update-plans-for-the-new-year.														The EPDP team should recognize: 1) that the GDPR has no legal force outside the EU’s jurisdiction, and so does not bind parties or services that do not have a significant EU nexus. 2) that ICANN President and CEO Göran Marby has made “it a high priority to find a path forward to ensure compliance with the GDPR while maintaining WHOIS to the greatest extent possible.” Data Protection and Privacy Update—Plans for the New Year, ICANN Blog (Dec. 21, 2017), https://www.icann.org/news/blog/data-protection-and-privacy-update-plans-for-the-new-year. 3) that an ICANN policy that globalizes EU privacy law in such a way will put strains on the credibility and legitimacy of the multistakeholder governance model and independence of ICANN, increase the odds that nations enact WHOIS or ICANN-specific laws, and lead to fragmentation that creates added complexity in developing and enforcing ICANN policy as well as jeopardizes the security, stability, and resiliency of the DNS system. 4) that geographic differentiation is possible, as evidenced by the policies of certain country code TLDs and geography specific gTLDs to require a geographic nexus to be eligible to register for a domain name. Taken together, these points suggest that contracted parties should be required to differentiate between registrants on a geographic basis and that no redaction of data should occur regarding the collection, processing and sharing of data outside the E.U. in the provision of non-E.U. services.	It would be inappropriate for an ICANN policy decision to give the GDPR effect beyond the EU’s jurisdiction. Such an ICANN policy decision would impinge on the policy prerogatives of other nations and the welfare of their citizens by unnecessarily and inappropriately extending EU privacy policy in a way that limits access to WHOIS data, which serves important law enforcement, consumer protection, public safety, cybersecurity, and intellectual property purposes that ICANN has itself recognized. It is one thing for ICANN policy to require contracted parties to abide by local laws that apply to them; it is another to require the contracted parties to abide by laws that would not otherwise apply, either geographically or in substance, and to do so in a way that contradicts longstanding WHOIS policies regarding the availability of data. In addition, requiring differentiation will lead to more consistent application than a permissive policy, which would likely result in a hodgepodge of different decisions by contracted parties. While prohibiting differentiation would result in a consistent approach, that approach would go beyond the requirements of the GDPR and contradict Göran Marby’s statements regarding preserving WHOIS access to the greatest extent possible.		The EPDP team should recognize: 1) that the GDPR applies only to natural persons, see GDPR, art. 1, https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679&from=EN), and so does not require redaction of any data regarding businesses or other legal persons. 2) that ICANN President and CEO Göran Marby has made “it a high priority to find a path forward to ensure compliance with the GDPR while maintaining WHOIS to the greatest extent possible.” Data Protection and Privacy Update—Plans for the New Year, ICANN Blog (Dec. 21, 2017), https://www.icann.org/news/blog/data-protection-and-privacy-update-plans-for-the-new-year. 3) that an ICANN policy that overbroadly applies the GDPR will put strains on the legitimacy of the multistakeholder governance model, increase the odds that nations enact WHOIS or ICANN-specific laws, and lead to fragmentation that creates added complexity in developing and enforcing ICANN policy as well as jeopardizes the security, stability, and resiliency of the DNS system. 4) that differentiation between natural and legal persons is possible, as evidenced by the practices of certain country code TLDs and gTLDs to do precisely that. Taken together, these points suggest that contracted parties should be required to differentiate between natural and legal persons and that no redaction of data should occur regarding the collection, processing, or sharing of data related to legal persons.	It would be inappropriate for an ICANN policy to apply GDPR beyond its scope. Such a decision would unnecessarily and inappropriately limit access to WHOIS data, which serves important law enforcement, consumer protection, public safety, cybersecurity, and intellectual property purposes that ICANN has itself recognized. In addition, requiring differentiation will lead to more consistent application than a permissive policy, which would likely result in a hodgepodge of different decisions by contracted parties. While prohibiting differentiation would result in a consistent approach, that approach would go beyond the requirements of the GDPR and contradict Göran Marby’s statements regarding preserving WHOIS access to the greatest extent possible.			Support intent of recommendation with edits	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 NonPublic Registration Data has been completed and incorporated in the team’s final report, 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: …	The Temporary Specification was meant to be just that: temporary. Absent a completed recommendation in the final report specifically delineating how contracted parties will provide access to redacted data to parties with a legitimate interest, as well as a deadline for creating that system, the EPDP runs the risk of unreasonably prolonging the Temp Spec. The result would be merely a redaction policy, rather than the standardized access model to non-public registration data that the EPDP is tasked with formulating. Nonetheless, if the May 25th deadline for expiration of the Temp Spec arrives without formulation of a standardized access model completed, the Temp Spec should be extended. To do otherwise might suggest that contracted parties are no longer under any obligations, resulting in a hodgepodge of access policies. This would put strains on the credibility and legitimacy of the multistakeholder governance model, increase the odds that nations enact WHOIS or ICANN-specific laws, and lead to fragmentation that creates added complexity in developing and enforcing ICANN policy as well as jeopardizes the security, stability, and resiliency of the DNS system.							No, I wish to continue to the next section
49	12/22/2018 14:32:05	Wim Degezelle	RySG	Yes	RySG	No, I would like to continue to the next section	Support Purpose intent with wording change	The RySG recommends separating Purpose 1 as currently written into two separate purposes and amending the language as follows: “IN ACCORDANCE WITH THE RELEVANT REGISTRY AGREEMENTS AND REGISTRAR ACCREDITATION AGREEMENTS, ACTIVATE A REGISTERED NAME AND ALLOCATE IT TO THE REGISTERED NAME HOLDER.” and “AS SUBJECT TO REGISTRY AND REGISTRAR TERMS, CONDITIONS AND POLICIES, AND ICANN CONSENSUS POLICIES: (i) ESTABLISH THE RIGHTS OF A REGISTERED NAME HOLDER IN A REGISTERED NAME, AND (ii) ENSURE THAT A REGISTERED NAME HOLDER MAY EXERCISE ITS RIGHTS IN THE USE AND DISPOSITION OF THE REGISTERED NAME.”	The RySG believes that Purpose 1 encompasses the fundamental and primary reasons for which gTLD registration data is processed in the domain name registration ecosystem. However, as written, the Purpose 1 text captures two separate and distinct purposes: one is the technical provisioning of a domain name registration and the second is the establishment of the Registered Name Holder’s rights in that domain. The latter of these two purposes may be conditioned by (or subject to) registry or registrar terms, conditions or policies at the option of the registry or registrar, but the former is not. Furthermore, these two purposes may require different processing and/or different data elements to achieve them, with the data elements necessary to achieve the establishment of the rights to the domain dependent on the specific terms, conditions and policies implemented by the registry or registrar.	Purpose should be deleted		The core of this recommendation is a suggestion that Contracted Parties collect registration data for the purpose of disclosure. Contracted Parties do not and it is submitted that this is not a shared purpose of ICANN and Contracted Parties. Furthermore, the text of the recommendation simply mirrors that of article 6(1)f of the GDPR. This amounts to a legal obligation on all data controllers i.e. the controller shall consider a disclosure request regarding the data processed by them; insofar as the disclosing controller is satisfied, as per under article 6(1)f, that the requesting 3rd party holds a legitimate purpose for such disclosure and such a disclosure is weighed appropriately against the data subject’s rights. This is entirely separate from a ‘purpose’, and in fact is applicable regardless of purpose. it is our belief that Purpose 2, at most is mere restatement of a legal basis for processing, and not a valid “purpose” for either ICANN or the Contracted Parties. It is submitted that the inclusion of Purpose 2 is therefore a fundamental misunderstanding and misinterpretation of Art. 6(1)f, and absent affirmative confirmation as to the legality of this purpose, it should be deleted in its entirety, as it does not add anything to the data processing review.	Support Purpose intent with wording change	The RySG supports the principle of this comment, but recommends the following wording: “ENABLE LAWFUL COMMUNICATION WITH AND/OR NOTIFICATION, OF RELEVANT DOMAIN-RELATED MATTERS, TO THE REGISTERED NAME HOLDER.”	It remains unclear as to whether or not Registered Name Holders can designate third party contact information in the Tech and Admin field, or indeed whether or not the Admin or Tech fields should be retained as part of the minimum data set. The RySG submits that the proposed wording change is closer to the true purpose, and provides more clarity that the current draft wording. Furthermore the RySG submits, regardless of whether or not the wording change is accepted, that the question of the Registered Name Holder being able to designate third parties as contacts requires further deliberation in both this and other contexts.	Support Purpose as written		The RySG supports this purpose as written. Provided that the requisite data protection mechanisms and agreements are in place between contracted parties and escrow agents, mechanisms for safeguarding registered name holder registration data is in the registrants' best interest in allowing contracted parties to provide a stable and secure service with reasonable expectations of continuity. The RySG, noting the discussions of the ePDP team surrounding legal basis for such processing, would also like to emphasise that any processing of data for such a purpose is based on a balanced application of Article 6(1)f and NOT article 6(1)b,	Support Purpose intent with wording change	The RySG proposes that Purpose #5 be divided into two separate purposes as follows: “HANDLE CONTRACTUAL COMPLIANCE MONITORING REQUESTS AND AUDIT ACTIVITIES CONSISTENT WITH THE TERMS OF THE REGISTRY AGREEMENT AND THE REGISTRAR ACCREDITATION AGREEMENTS.” and “HANDLE COMPLIANCE COMPLAINTS INITIATED BY ICANN, REGISTRY OPERATORS, REGISTRARS, REGISTERED NAME HOLDERS, AND OTHER INTERNET USERS CONSISTENT WITH THE TERMS OF THE REGISTRY AGREEMENT AND THE REGISTRAR ACCREDITATION AGREEMENTS.”	The purpose as written is ambiguous and open to conflicting interpretations regarding whether the scope includes compliance actions initiated by ICANN. We understand that “Registry Operators, Registrars, Registered Name Holders, and other internet users” is intended to only modify the clause regarding complaints, but the language could be reasonably understood as limiting “monitoring requests” and “audits” to those parties as well. The purpose should be revised to address this ambiguity. Moreover, the EPDP should consider two separate purposes related to Compliance activities: the first for the administration of complaints submitted to ICANN, and the second for monitoring and audit activities. These are separate and appreciably different actions and, as a result, should rely on distinct and explicit purposes. The RySG emphasizes that the inclusion of this purpose in no way expands the scope of ICANN Compliance’s narrowly defined audit rights and related ability to require information from contracted parties. Under Section 2.11 of the new gTLD Registry Agreement (Section 3 and Articles II and III of the legacy gTLD Registry Agreement), ICANN audits are limited to “assess[ing] compliance by Registry Operator” with Article 1 and Article 2 of the Registry Agreement, and must be “tailored to achieve the purpose of assessing compliance.” Our understanding is that the language of this purpose in no way enlarges that very limited role for ICANN Compliance. In addition, the RySG emphasizes that this purpose alone is not sufficient to justify the processing of data under GDPR. ICANN Compliance ensure and demonstrate to contracted parties that any processing that flows from this purpose is compliant with the requirements of GDPR. The RySG notes that appropriate data processing and protection terms need to be incorporated into appropriate agreements. In addition, appropriate legal bases for processing must be identified for each ICANN purpose. The EPDP should ensure that ICANN Compliance is again engaged to provide a ‘Record of Processing Activities’ and equally provide assurances that data processing, and data sharing within ICANN is on a strictly limited and need to know basis.	Support Purpose intent with wording change	The RySG recommends the following edit to Purpose #6: “COORDINATE, OPERATIONALIZE, AND FACILITATE THE IMPLEMENTATION OF CONSENSUS 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, AND RRDRP.”	The Article 29 Working Party advised ICANN of the importance of “explicitly defining legitimate purposes” and cautioned that “use of the word ‘include’ suggests that not all purposes are made explicit, which would also be incompatible with article 5(1)b GDPR.” The inclusion of “future developed domain name registration dispute procedures” should not be included in this purpose under the same rationale. Undefined future procedures are by definition not explicitly defined and should be omitted from this purpose. The Article 29 Working Party and EDPB have stated on several occasions that purposes can not be speculative and must apply to an existing processing purpose. We recognize that there is a legitimate interest in attempting to “future-proof” this policy, but implementation of a new dispute resolution procedure would undoubtedly require policy amendments and additional notice for registrants, such that the inclusion of this language here likely does not save the community from future requirements to update this policy. To that end, referencing “consensus policy” may keep the scope of the purpose limited but also allow reasonable inclusion of any dispute resolution processes that are developed as consensus policies in the future.	Support Purpose as written		The RySG supports this purpose as written. Registries operate under diverse and innovative business models, and inclusion of this purpose is important in order to allow those registries that rely on validation of registration eligibility criteria to continue to operate in a GDPR compliant manner. Possible examples of validation (as noted in the initial report) include: (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]. The RySG understands that this purpose is not, or will not be, applicable to all Registries, however, for those Registries requiring this purpose it is appropriate.	The EPDP Team must revisit each of the workbooks and conduct a proper and thorough analysis of all processing activities and each data element identified as being required to fulfill every purpose. Because of the extensive interrelationship among issues and data elements, it will be important for the EPDP Team to conduct consistency reviews to ensure that any changes arising from the public comment period are applied consistently. In addition, the RySG continues to advocate for a data audit and mapping approach to determining purposes and the roles and responsibilities of involved parties. This important analysis is still absent.	Echoing the explanation found on page 89 of the Initial Report, the RySG urges the EPDP team to ensure clarification as to the definition of ‘ICANN purposes’ as it applies to the report, as it remains unclear, and should not be relegated to a footnote. The RySG urges further clarification that the purposes as stated, are notwithstanding any established purposes of either ICANN or individual registries or registrars, who may design and establish their own additional purposes, in which they would be acting as sole controller.		No, I wish to continue to the next section	Delete recommendation		The RySG doesn’t believe that the purpose of recommendations is to reiterate that work in the Charter will be done. Unless the recommendation is to 1) amend the Charter, or 2) alter the implementation of the Charter, then it should be assumed that the ePDP will address all in scope issues during its period of work. The RySG is committed to continuing to work with the EPDP Team on the topic of how to provide access to non-public registration data, including the consideration of the questions included in the text of Recommendation #2, once the Phase 1 work and completion of answers to the gating questions in the Charter, is complete. Should the EPDP see fit not to accept our recommendation to delete, then we remind the Team that the proper terminology that should be used, and as discussed by the EPDP team, is “request for disclosure” and not “access.”		Support recommendation as written			Accuracy, insofar as the GDPR requires, primarily relates to the requirement that the data provided to the Data Controller / Processor is recorded accurately and is kept up to date, with the data subject’s reasonable instructions. (e.g. where the data subject notifies you of an inaccuracy, the data must be changed without undue delay). Whereas, it is accepted that data controllers must make reasonable efforts to ensure the accuracy of the data they process; however, such reasonable efforts must be linked to practical matters such as: the likelihood of harm or damage to the DATA SUBJECT of an inaccuracy the use of the data by the controller (and whether the decisions made, by the controller, as a result of the data significantly affect the individual concerned, or others) the nature of the data processed the ability of the controller to verify accuracy with due regard to practical matters such as ability, technology and the cost of implementation (again all balanced against the potential impact to the rights of the data subject) It is submitted therefore that the current regime for accuracy, especially considering the most recent ARS report on WHOIS accuracy (Cycle 6) (June 2018) noted postal address operability is 99% and postal address syntax accuracy is 88% (up from 80% three years earlier). ICANN’s own key findings include that “nearly all WHOIS records contained information that could be used to establish immediate contact: In 98 percent of records, at least one email or phone number met all operability requirements of the 2009 RAA.. In light of this report, it would appear that the accuracy requirements as contained in the RAA are objectively sufficient and reasonable, for the purpose to which the data is put. We submit, therefore, that no change to the recommendation is currently necessary.	No, I wish to continue to the next section	No	The RySG notes that the EPDP Team did not engage in a thorough discussion about the individual data elements that are required to be collected by the registrar to fulfill the identified Purposes. The RySG defers comment on this recommendation, pending EPDP WG discussion and analysis of all individual data elements identified in Preliminary Recommendation 4. In addition, the publication system (RDDS) matters as it impacts the answer for specific data elements. For example, consider “Registrar Abuse Email”. If the registrar is going to participate in the RDDS, then the registry does not need this information and it does not need to be collected since the registrar may simply generate it and publish as appropriate. On the other hand, if the registrar does not participate in the RDDS, then this needs to be generated by the registrar, passed to the registry, and then published by the registry as appropriate.	The EPDP Team did not specifically discuss and analyze each of the individual data elements identified in Preliminary Recommendation 4. It must do so, and revise the recommendation as appropriate. The RySG is willing and available to contribute to this analysis as the EPDP Team needs. Further, the EPDP Team should explain why the automatically generated data elements are included. Finally, in cases where registry operators identify additional data elements in their registration policies, it is those registries - not registrars - that either collect or require the collection and processing of the “additional optional data elements as identified by Registry Operator in its registration policy.” The wording of the recommendation should be revised accordingly.	The RySG does not believe the consensus policy should require additional elements to be collected/generated	The scope of this EPDP is not to contemplate adding additional data elements, but rather to consider the Temporary Specification and either approve the requirements contained therein, or make necessary modifications to bring the RDDS requirements into compliance with GDPR.	Optional	The RySG views this issue through the lens of Purpose 1. That Purpose references the Registered Name Holder (not the technical contact) and the existence of a technical contact is not necessary to complete the activities encompassed by Purpose 1.	No	RySG comment: The consensus policy should bear in mind the GDPR principle of data minimization. While there may be cases where registrars wish to provide their customers with the ability to designate a technical contact in addition to the registrant, and can provide a legal basis or justification for doing so, the RySG believes that registrars should not be universally required to collect additional contact fields. As such, it should be optional for the registrar to offer technical contact fields.	Yes	The RySG understands that registrars do not generally rely upon the contact information provided for the billing and administrative contacts to handle billing and administrative matters. Accordingly, these contacts appear to have outlived their usefulness and no longer merit collection under GDPR. Additionally, refer to the response to Question 49. The consensus policy should respect the principle of data minimization. Registrars should not be required by the policy to collect contact information for additional contacts, especially where the policy itself considers the data to be optional (i.e., not necessary for the purpose).		No	The RySG notes that the EPDP Team did not engage in a thorough discussion about the individual data elements that are required to be transferred from the registrar to the registry to fulfill the identified Purposes. The RySG defers comment on this recommendation, pending EPDP WG discussion and analysis of all individual data elements identified in Preliminary Recommendation 5.	The EPDP Team did not specifically discuss and analyze each of the individual data elements identified in Preliminary Recommendation 5. It must do so, and revise the recommendation as appropriate. The RySG is willing and available to contribute to this analysis as the EPDP Team needs.	In conducting its analysis of the data elements required to be transferred from the registrar to the registry, the RySG urges the EPDP Team to bear in mind that gTLDs are operated in diverse and varied ways. The ultimate recommendation that becomes part of the consensus policy should focus on establishing minimum requirements that are flexible enough to account for those different business and operating models.	Support intent of recommendation with edits	The EPDP Team did not specifically discuss and analyze each of the individual data elements identified in Preliminary Recommendation 6. It must do so, and revise the recommendation as appropriate. The RySG is willing and available to contribute to this analysis as the EPDP Team needs. In conducting this analysis, the EPDP Team should bear in mind that no additional data elements should be required to be collected by the registrar or transferred from the registrar to the registry solely to achieve this purpose. Rather, the data elements required to be transferred to the data escrow agents should be derived ONLY from the set of data elements required to be collected by the registrar and transferred from the registrar to the registry in fulfillment of Purposes 1, 3, 6 or 7. Further, in the Final Report, the recommendation should not reference the workbook but should be worded as a standalone recommendation that describes what data elements Contracted Parties are required to transfer to the data escrow providers.	While the RySG acknowledges that safeguarding the registration data may be a legitimate processing activity, it does not in and of itself justify the collection or transferring of any additional data elements that are not already collected and transferred for more primary purposes. It is critical for the data elements workbooks to reflect this and for the entire policy to be consistent.	The RySG understands that at least one data escrow provider submitted several months ago to ICANN for ICANN’s required approval a template data processing amendment to that provider’s Registry Operator escrow agreements. Such an amendment could fulfill part 2 of Recommendation 6 once ICANN approves it.	Support intent of recommendation with edits	No	The EPDP Team did not specifically discuss and analyze each of the individual data elements identified in Preliminary Recommendation 7. It must do so, and revise the recommendation as appropriate. The RySG is willing and available to contribute to this analysis as the EPDP Team needs. In conducting this analysis, the EPDP Team should bear in mind that no additional data elements should be required to be collected by the registrar or transferred from the registrar to the registry solely to achieve this purpose. Rather, the data elements required to be transferred to the data escrow agents should be derived ONLY from the set of data elements required to be collected by the registrar and transferred from the registrar to the registry in fulfillment of Purposes 1, 3, 6 or 7. Further, in the Final Report, the recommendation should not reference the workbook but should be worded as a standalone recommendation that describes what data elements Contracted Parties are required to transfer to the data escrow providers.	While the RySG acknowledges that ICANN’s compliance activities may be legitimate processing activities, it does not in and of itself justify the collection or transferring of any additional data elements that are not already collected and transferred for more primary purposes. It is critical for the data elements workbooks to reflect this and for the entire policy to be consistent.		Yes		The RySG supports the recommendation that the fields designated in Recommendation 8 should be redacted in the registration data directories that Contracted Parties are required to operate. However, the requirement to publish the remaining data elements in a “freely accessible directory” raises concerns for the RySG given the open-ended and imprecise nature of the language. The RySG proposes changing this language to “appear via free public based query access.” Further, the RySG recommends refining Recommendation 8 to include a provision that, in the event a Contracted Party collects additional data elements not included in the list enumerated in the recommendation, the Contracted Party should be permitted to redact those data elements, at its discretion	Yes	The RySG notes that there are a great many instances where the Organization field of a domain registration record contains personal data of natural persons, such as the name of registrant. There is no way for Contracted Parties to understand the Registered Name Holder’s intention or motivation behind inputting this type of data in such cases. Given the hundreds of millions of existing domain registrations, requiring contracted parties to publish the Organization field in publicly accessible domain registration databases would inevitably result in the publication of personal data that could result in violations of the GDPR. At this point in time, Contracted Parties cannot rely on domain registrants to only provide the names of legal organizations, rather than personal data, in the Organization field. The RySG understands that the EPDP is seeking additional legal guidance on this topic, and once that guidance is received, we may be willing to revisit this position. However, at this time, the RySG believes that the policy should allow registries to take a conservative approach to compliance by allowing the Organization field to be redacted.	While the RySG supports the substance of Recommendation #8, we believe the wording could be more clear by stating upfront which data fields should be redacted in the public registration data output.	Intent and wording of this recommendation requires amendment		The RySG cautions against assuming that the provision of extra educational materials, as being capable of rectifying a defect in the clarity of the process. If the process itself is not capable of being understood by the data subject, then the mere availability of additional, and separate, educational materials will not likely suffice.	The RySG echoes the concern a noted in the Initial Report regarding over reliance on educational resources as a cure to failings in the process. Educational resources should be complementary to a clearly-presented system of data collection and onward processing. They should not be seen as a required supplement, to provide necessary aids to comprehending the system. As such, where additional ‘educational resources’ are considered a necessity to ensure compliance, this may not be considered to be compatible with the concepts of privacy by default or privacy by design, i.e., where additional ‘educational resources’ are deemed necessary, the process itself is likely not established or presented in a sufficiently clear manner.	Support intent of recommendation with edits	The RySG suggests the following edits to Recommendation #10: “The EPDP Team recommends that registrars must provide a mechanism to facilitate email communication with the Registered Name Holder or contact, but must not identify the contact email address or the contact itself.”	The RySG supports the intent of Recommendation #10, but notes that it only reflects two options for registrars to facilitate communication with the relevant contact. There may be instances where registrars choose to offer other methods of contact, and the recommendation should provide registrars with the flexibility to offer such methods. In the Final Report, the RySG believes that policy recommendations should be standalone recommendations and not reference the Temporary Specification.	The RySG will caution against the use of an email relay system, as such a system, without proper controls may have unintended data disclosure (e.g., auto-replies, Out Of Office notifiers). The RySG also, noting the discussions of the EPDP team, would strongly resist any suggestion as to the necessity of the Registrar in ‘confirming’ delivery. Such a ‘service level’ approach is unrealistic, and this recommendation, at its highest must be only taken as a ‘pass on’ requirement and should not give rise to any unreasonable expectations on the registrars to ‘verify’ receipt of such a communication.	Support intent of recommendation with edits	The RySG recommends editing Recommendation #11 as follows: “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.”	The use of the term ‘statute of limitations’ is incorrect. Additionally the retention period should merely be set/stated, and not linked to a specific applicable requirement. The rationale as to why 1 year is set should be documented in full, but should not be included in the recommendation itself. The recommendation should not preclude any registrar from choosing to retain data for a longer period of time than 1 year, in accordance with their specific business needs and applicable laws For the avoidance of doubt, any additional retention periods which a registrar may see fit to implement, will be the sole responsibility of that registrar.	The RySG cautions the over reliance on just identifying the limitation for the TDRP. Note that if a retention period is specifically linked to data retained for a specific purpose, data retained beyond the minimum, may ONLY be used for that purpose. Whereas we completely encourage the identification of the necessity for different limitation periods, thus linking retention to specific and measurable periods, the ePDP should compile all specific grounding limitation periods to ensure the ongoing use for such purposes. Furthermore, the IRTP Policy Status Report is currently out for public comment and could lead to work that changes the TDRP retention period.	RySG comment:The RySG urges the EPDP team to consider the realistic effects of any recommendation that requires a delineation on geographic basis. The RySG reminds the EPDP Team that any recommendations made must ensure: A) that the rights of the data subject are best vindicated and protected; B) that due consideration is given to the state of the art, the nature of the data processed, and the cost of implementation to the contracted parties; C) that the focus of the EPDP recommendations remain in scope, i.e., that recommendations are based on whether the temporary specification, as written, or with modification as necessary, is capable of bringing the contracted parties into compliance with the requirements of the GDPR. The creation of new obligations on the CPH which are not necessary for such compliance, are not in scope for this process. The RySG reminds the EPDP team that there remain numerous considerations which, in our opinion, make a delineation on geographic basis, untenable; to the fore is the inability to adequately identify, with any degree of certainty, whether or not a particular registrant is subject to the GDPR. The ePDP team have provided no clarity as to how geographic delineation would be achieved with current technology and process, merely a suggestion from some quarters, that it MUST occur, or more worryingly, that additional data elements be collected to prop up an untested consent based delineation. The CPH members of the EPDP, are on record as having repeatedly expressed their frustration with such suggested recommendations, in the face of impossible and unrealistic expectations in implementation. For the avoidance of doubt, the RySG does not believe a “rules engine” is an acceptable “solution” and does not support the development of one. Further, the EPDP Team must take into account the widespread use by registry operators of backend providers, which may or may not be in the same jurisdiction as the registry operator and may or may not process data in the EU. This additional processing activity further complicates any potential geographic distinction. To reiterate, under GDPR, it is not sufficient for contracted parties to make this jurisdictional distinction in most cases, or even in nearly all cases. Contracted parties must get this right for all registrants or else the significant sanctions associated with violations of GDPR may apply. As a result, it is the edge cases that matter and until the community can demonstrate that these hard cases can be addressed accurately and reliably, contracted parties should not be required to onboard such significant liability. The RySG notes that the EPDP are not tasked with reinventing the DNS system. The Temporary Specification, as written, permits a registry / registrar to process data in a compliant manner. No change to the Temp Spec is therefore strictly necessary.	See response to Question 84	See response to Question 84	The EPDP team is urged to consider the realistic effects of any recommendation that requires a delineation on natural/legal person basis. The RySG reminds the EPDP Team that any recommendations made must ensure: A) that the rights of the data subject are best vindicated and protected; B) that due consideration is given to the state of the art, the nature of the data processed, and the cost of implementation to the contracted parties; C) that the focus of the ePDP recommendations remain in scope, i.e., that recommendations are based on whether the temporary specification, as written, or with modification as necessary, is capable of bringing the contracted parties into compliance with the requirements of the GDPR. The creation of new obligations on the CPH which are not necessary for such compliance, are not in scope for this process. The RySG reminds the EPDP team that there remain numerous considerations which, in our opinion, make a delineation on legal / natural person, untenable; to the fore is the inability to adequately identify, with any degree of certainty, whether or not a particular registrant is subject to the GDPR or not. The EPDP team have provided no clarity as to how such a delineation would be achieved with current technology and process, merely a suggestion from some quarters, that it MUST occur, or more worryingly, that additional data elements be collected to prop up an untested consent based delineation. The CPH members of the EPDP, are on record as having repeatedly expressed their frustration with such suggested recommendations, in the face of impossible and unrealistic expectations in implementation. To reiterate, under GDPR, it is not sufficient for contracted parties to make this distinction in most cases, or even in nearly all cases. Contracted parties must get this right for all registrants or else the significant sanctions associated with violations of GDPR may apply. As a result, it is the edge cases that matter and until the community can demonstrate that these hard cases can be addressed accurately and reliably, contracted parties should not be required to onboard such significant liability. The RySG notes that the ePDP are not tasked with reinventing the DNS system. The Temporary Specification, as written, permits a registry / registrar to process data in a compliant manner. No change to the Temp Spec is therefore strictly necessary.	See response to Question 87.	The RySG would pose the question as to how research of other, as of yet untested applications, in different industries, or even in domain name registration outside of the ICANN construct, would be beneficial. Review of the deliberations thus far has provided the team with on the record statements as to the current unavailability of the adequate technological means to implement any such mandatory delineation, that may be considered to be expert opinion, based on experience of both day to day implementation concerns as to available technology, implementation difficulties and on the basic feasibility of such a policy recommendation for all members of the CPH, from small scale, to large. We are unsure as to why further delay and expense regarding ‘further research’ is considered to be necessary here.	No.	Intent and wording of this recommendation requires amendment	The RySG recommends the following edits to Recommendation #12: “The EPDP Team recommends that the current requirements in the Temporary Specification in relation to reasonable access remain in place until work on the second phase of the EPDP Charter on data access issues is addressed, noting that the term should be modified to refer to ‘parameters for responding to lawful disclosure requests.’ During the second phase of the ePDP Charter work, the EPDP Team expects that criteria around the term ‘reasonable’ may be further explored.”	The RySG has noted its concern that repeated efforts by some EPDP Team members to focus on access to, and/or disclosure of, data in the initial phases of the EPDP’s work has significantly hampered the group’s ability to make progress on the core issues of defining purposes for data collection and the roles and responsibilities of parties. The Charter explicitly states that data access questions are to be addressed in the second phase of the EPDP. Therefore, inclusion of this recommendation, as written, is premature and serves to predetermine the issue to be discussed. The RySG looks forward to discussing these issues in the second phase of the EPDP’s work.	The RySG has consistently stated its willingness to discuss access to data by third-parties as part of the second phase of the EPDP as outlined in its Charter, including discussion of an access model for lawful data access requests. The RySg looks forward to engaging with EPDP members to identify processes to streamline third-party data access requests and potential disclosure.	Support intent of recommendation with edits	The RySG suggests the following edits to Recommendation #13: “The EPDP Team recommends that ICANN Org negotiates and 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 Contracted Parties. In addition to the legally required components of such agreement, the agreement shall specify the responsibilities of the respective parties for the processing activities as described therein. Indemnification clauses shall ensure that the risk for certain data processing is borne by either one or multiple parties that determine the purpose and means of the processing.”	While the RySG acknowledges the deliberations and work undertaken by the EPDP Team on this matter, we believe that ICANN Org and the Contracted Parties should work together to determine not only the terms of the agreements, but which type of agreement best reflects the realities of the domain name ecosystem and the roles each party plays in the required data processing activities.	Some Registries strongly believe that a Joint Controller Agreement (“JCA”) is the most appropriate form for a data protection agreement between ICANN and Contracted Parties because it (i) specifically allocates factual responsibility for data processing, (ii) defines and controls each party’s liability, and (iii) provides required transparency for data subjects. Under a JCA, ICANN and Contracted Parties can clearly structure their data processing relationship by defining roles and responsibilities where purposes and means of processing are shared. This approach more accurately reflects the complexities of the domain registration process and likely aligns with how DPAs would view the data processing performed by the parties, regardless of whether parties self-designate as sole controllers. The RySG also reiterates that speculation about future models for access should not influence the form of a data processing agreement between the parties. The RySG has previously raised concerns regarding the feasibility of a Unified Access Model (“UAM”). However, setting aside issues with the merits of that proposal, an arrangement where ICANN is solely responsible for decision-making regarding the disclosure of data to third parties is not prohibited merely because ICANN is party to a JCA with Contracted Parties. ICANN retains the flexibility to act as a sole controller outside of the shared purposes with Contracted Parties.		No, I wish to continue to the next section
50	12/22/2018 14:51:48	Dean S. Marks	Coalition for Online Accountability	Yes	The Coalition for Online Accountability ("COA") consists of eight leading copyright industry companies, trade associations and member organizations of copyright owners, all of them deeply engaged in the use of the internet to disseminate creative works protected by copyright law. The COA members are Broadcast Music, Inc. (“BMI”); the Entertainment Software Association (“ESA”); the Motion Picture Association of America (“MPAA”); the Recording Industry Association of America (“RIAA”); NBCUniversal; The Walt Disney Company; Twenty-First Century Fox; and WarnerMedia. The Coalition’s main goal since its founding nearly two decades ago (as the Copyright Coalition on Domain Names) has been to preserve and enhance online transparency and accountability, particularly in the domain name system.	No, I would like to continue to the next section	Support Purpose intent with wording change	(I) TO ESTABLISH THE RIGHTS AND OBLIGATIONS OF A REGISTERED NAME HOLDER IN A REGISTERED NAME; (II) TO ENSURE THAT A REGISTERED NAME HOLDER MAY EXERCISE ITS RIGHTS AND FULFILL ITS OBLIGATIONS IN THE USE AND DISPOSITION OF THE REGISTERED NAME; AND	The collection of data from the domain name registrant serves not only the purpose of establishing rights of the registrant in a registered name, but also for establishing obligations. These include the obligation to pay the registrar the appropriate periodic fee for the registered name and the obligation for the registrant to comply with the various terms and conditions established in the contract between the registrar and the registrant. Rights and obligations go hand-in-hand, and therefore the purpose of obtaining the data from the registrant to establish the rights in the name cannot be separated from the purpose of obtaining the data to fulfill the obligations that go along with domain name ownership. Article 6(1)(b) of the GDPR establishes the legality of collecting and processing personal data "for the performance of a contract to which the data subject is party . . . ." The performance of any contract involves OBLIGATIONS in addition to rights. Therefore, adding the language suggested concerning obligations makes this proposed purpose more compliant with the GDPR.	Support Purpose intent with wording change	ENSURING THE SECURITY, STABILITY AND RESILIENCY OF THE DOMAIN NAME SYSTEM IN ACCORDANCE WITH ICANN'S MISSION, COMMITMENTS AND CORE VALUES THROUGH ENABLING LAWFUL ACCESS FOR LEGITIMATE THIRD PARTY INTEREST OF LAW ENFORCEMENT, CYBERSECURITY, COMBATTING DOMAIN NAME ABUSE, CONSUMER PROTECTION AND INTELLECTUAL RIGHTS PROPERTY PROTECTION TO DATA ELEMENTS COLLECTED FOR THE OTHER PURPOSES IDENTIFIED HEREIN	ICANN's stated mission is to ensure the stable and secure operation of the Internet's unique identifier systems; therefore Purpose #2 should embody the "ensure" language and imperative. Article 13(1) of the GDPR states: “Where personal data relating to a data subject are collected from the data subject, the controller shall, at the time when personal data are obtained, provide the data subject with all of the following information: . . . (d) where the processing is based on point (f) of Article 6(1), the legitimate interests pursued by the controller or by a third party;” (emphasis added)" In order to comply with Article 13(1)(d), it is key that the legitimate interests pursued by the controller or by a third party be spelled out clearly in the Purpose statement and communicated to the data subject AT THE TIME WHEN PERSONAL DATA ARE OBTAINED. As a joint controller, ICANN’s purposes with respect to WHOIS data and registry directory services include, according to ICANN’S Bylaws “whether its implementation meets the legitimate needs of law enforcement, promoting consumer trust, security, stability and resiliency, malicious abuse issues, sovereignty concerns and rights protection.” (ICANN Bylaws Section 4.6). Purpose #2 from the Initial Report only addresses “security, stability and resiliency” and does not address the other ICANN purposes and concerns as articulated in Section 4.6 of the Bylaws. The above suggested edits to Purpose #2 address this deficiency. In addition, the above suggested edits to Purpose #2 seek to ensure compliance with Article 13(1)(d) of the GDPR by: (i) enumerating more specific purposes, and (ii) identifying with greater specificity the legitimate interests of ICANN (as a joint controller) and the legitimate interests pursued by third parties that may seek access to the personal data for processing. Therefore, we believe it is important to spell out explicitly, as we have done in our suggested edits, the legitimate interests of law enforcement, cybersecurity, combatting domain name abuse, consumer protection and intellectual property rights protection. Intellectual property rights protection covers the universally and legally recognized rights of trademark, copyright and patent. In its letter of 11 April 2018, to Goran Marby, the Article 29 Data Protection Working Party stated that “purposes specified by the controller must be detailed enough to determine what kind of processing is and is not included . . . .” The letter also stated that the WP29 “stresses the importance of explicitly defining legitimate purposes in a way which comports with the requirements of the GDPR.” Our proposed edits to Purpose #2 seek to incorporate and comply with this legal guidance that ICANN has received.	Support Purpose intent with wording change	ENABLE COMMUNICATION WITH AND/OR NOTIFICATION TO AND/OR INVESTIGATION OF THE REGISTERED NAME HOLDER AND/OR THEIR DELEGATED AGENTS OF TECHNICAL AND/OR ADMINISTRATIVE AND/OR LEGAL ISSUES WITH A REGISTERED NAME (BOTH WITH RESPECT TO THE REGISTERED NAME ITSELF AND/OR THE USE OF THE REGISTERED NAME).	Adding the words "legal issues" bring greater clarity and specificity to the purpose and understanding by the registered name holder that the personal data collected may be used to contact or notify the registered name holder of legal issues with respect to the registered name. The same holds true for adding the word "investigation," as the personal data collected from the domain name registrant may be used in connection with investigations of technical issues (e.g., domain name "hijacking") as well as legal issues, including those pursued by law enforcement. The parenthetical language "(both with respect to the registered name itself and/or the use of the registered name)" provides clarity and information to the registered name holder that their personal data may be processed for the purpose of resolving claims that the registered name is being used to facilitate unlawful conduct, including by giving the registered name holder appropriate notice of such claims. All of the suggested edits to Purpose #3 seek to bring it into greater compliance with the GDPR, particularly Article 13 and its information requirements.	Support Purpose as written			Support Purpose as written			Support Purpose intent with wording change	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 BUT INCLUDING WHERE SUCH POLICIES TAKE INTO ACCOUNT USE OF THE 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. THIS PURPOSE SHOULD NOT BE READ TO LIMIT ANY OTHER PURPOSE WHERE PROCESSING OF DATA HAS BEEN RECOGNIZED AS LEGITIMATE IN CONNECTION WITH FACILITATING INVESTIGATION AND ACTION CONCERNING ANY OTHER LEGAL ISSUES INVOLVING A DOMAIN NAME, INCLUDING HOW A DOMAIN NAME IS USED.	As set forth in the Initial Report, Purpose #6 does not adequately capture that domain name disputes do, in fact, normally involve the use of the domain name. For example, the UDRP sets forth that the complainant must prove that the disputed domain name "has been registered and is being used in bad faith." The suggested edits seek to correct this deficiency and to comply more closely with the GDPR's requirements set forth in Article 6 and Article 13 concerning the lawfulness of processing and the information to be provided where personal data are collected from the data subject.	Support Purpose as written				COA recommends additional purposes for processing registration data concerning: (i) research, both research conducted by ICANN org and by third parties, and (ii) implementation of consensus policies by ICANN org and the undertaking of validation, facilitation and compliance activities consistent with its mission. Potential wording to capture such additional purposes: A. Enable research undertaken by ICANN and third parties concerning the operational stability, reliability, security, global interoperability, resilience, and openness of the DNS and threats to these criteria and values, and on the accuracy of WHOIS data. B. Enable the operations of ICANN consistent with its mission of furthering the operational stability, reliability, global interoperability, resilience and openness of the DNS via implementation of consensus policies, validation and compliance with policies and contracts, and facilitation activities.	Article 5(1)(b) and (e) of the GDPR recognize research as legitimate and not "incompatible with the initial purposes." Given how important research-- undertaken both by ICANN org itself and by third parties, such as cybersecurity researchers--is to the core mission of ICANN of ensuring and furthering the stability, reliability and resiliency of the domain name system, this research purpose should be set forth explicitly. In addition, adding this explicit purpose furthers compliance with Article 5(1)(a) of the GDPR that personal data is processed "fairly and in a transparent manner in relation to the data subject" because setting forth this purpose clearly and explicitly enhances transparency. Finally, adding a specific reference to the accuracy of WHOIS data fulfills the accuracy requirement of the GDPR as set forth in Article 5(1)(d). This is the rationale that supports new Purpose A suggested above. In order to implement, fulfill and enforce both consensus policies and contractual obligations, as well as pursue operations critical to ICANN's core mission, ICANN will need access to and be able to process personal data of registered name holders in its role as a controller or joint controller. Setting forth this purpose explicitly furthers the accountability principle set forth in Article 5(2) of the GDPR. In addition, it adds greater clarity to the lawful processing activities of ICANN as set forth in Article 6 of the GDPR. Among other functions, this purpose permits ICANN to continue to operate its Accuracy Reporting System ("ARS") concerning WHOIS data. This is the rationale that supports new Purpose B suggested above.	No, I wish to continue to the next section	Intent and wording of this recommendation requires amendment	Per the EPDP Team Charter, the EPDP Team is committed to answering the additional gating questions in the Charter and developing and recommending a system for Standardized Access to non-public Registration Data no later than the submission of its Final Report. 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, the EPDP Team will develop a proposal that sets forth the method and process for disclosing non-public Registration data to third parties that have established legitimate interest in accessing non-public Registration data, including intellectual property rights holders, cybersecurity firms, organizations that mitigate DNS abuse, consumer protection organizations and law enforcement agencies.	In order to fulfill its Charter, the EPDP Team must develop and deliver a proposal to address standardized access to non-public registrant data. The edits to Recommendation #2 submitted here recognize this as a requirement of the Charter that must be fulfilled by the EPDP Team no later than the submission of its Final Report. Moreover, specific guidance from the European Data Protection Board has been received by ICANN in the Board's May 27 communication wherein it stated that it expects ICANN "to develop and implement a WHOIS model which will enable legitimate uses by relevant stakeholders, such as law enforcement, of personal data concerning registrants in compliance with the GDPR . . . " The suggested edits offered above further clarify "relevant stakeholders" by specifically calling out intellectual property rights holders, cybersecurity firms, organizations that mitigate DNS abuse, consumer protection organizations and law enforcement agencies		Intent and wording of this recommendation requires amendment	The EPDP Team recommends that no consensus policy adopted to address registration data interfere with accuracy requirements under current ICANN contracts and consensus policies nor interfere with ICANN’s ability to enforce accuracy requirements, including by being able to access full registration data (including any data elements that are redacted from publication in any registration directory) in order to assess data accuracy and enforce accuracy contractual requirements. This includes full access to registration data to enable the operation of the ICANN WHOIS Accuracy Reporting System (“ARS”) and all validation functions under the ARS. In addition, because of the data accuracy requirements imposed by the GDPR, the EPDP Team recommends that requirements be developed to increase the accuracy of registration data	According to Article 5.1(d) of the GDPR, personal data shall be "accurate and, where necessary, kept up to date; every reasonable step must be taken to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay." The ico. (Information Commissioner’s Office in the UK) points out in its writings on “Principle (d): Accuracy” that one of the new features of GDPR as compared to the principles under its predecessor is that there is now a “clearer proactive obligation to take reasonable steps to delete or correct inaccurate personal data.” In addition, the European Commission’s technical input on ICANN's proposed GDPR-compliant WHOIS models underscored the GDPR's "Accuracy" principle and made clear that “reasonable steps should be taken to ensure the accuracy of any personal data obtained” for WHOIS databases and that ICANN should be sure to incorporate this requirement in whatever model it adopts. Accuracy of domain name ownership is paramount to collection of WHOIS/Registered Name Holder data in the first instance. In addition, since this data will be used by third parties who demonstrate a legitimate interest, ensuring that it is accurate for them and their legitimate interests is also relevant. Moreover, as demonstrated by the .dk ccTLD, when accuracy and validation of registration data is taken seriously, it leads to dramatic decreases in abuse and illegal activity on the top level domain. See: https://ccnso.icann.org/sites/default/files/field-attached/presentation-difo-increase-trust-25jun18-en.pdf Prior to the adoption of the Temporary Specification, accuracy of WHOIS data was problematic. When the ARS was running, we know that almost 40% of randomly sampled registrations had a problem that warranted opening a compliance ticket on them. Therefore, even prior to ICANN seeking to modify its policies to comply with GDPR, a serious problem with accuracy existed. Now with the adoption of the Temporary Specification, the ARS is not even operational. With the accuracy requirements that the GDPR imposes, accuracy is an issue fully within scope of the EPDP so that ICANN and contracted parties proactively address how they will ensure and validate the accuracy of data in the first place, not just how they rectify inaccurate data brought to their attention after collection.		No, I wish to continue to the next section	Yes			Registrars should be required to provide an option for registered name holders to indicate that they are either a Legal or Natural Person. Registrars should be required to generate a data element of the date on which registered name holder contact data was last verified/validated in accordance with the RAA and the method used to do so.	The GDPR does not apply to the data of Legal Persons. Recital 14 of the GDPR makes clear that "[t]his Regulation does not cover the processing of personal data which concerns legal persons and in particular undertakings established as legal persons, including the name and the form of the legal person and the contact details of the legal person." Therefore, in order to fulfill the stated purpose of the GDPR to protect only the data of natural persons and to further ICANN's mission, registrars should be required to give registered name holders the ability to designate themselves as legal or natural persons at the time they enter into a contract with the registrar to acquire a domain name. The generation of an additional data element by the registrar concerning when the registrant contact data was last verified/validated is consistent with and furthers compliance the GDPR's data accuracy requirements as well as the obligations set forth in the RAA concerning data quality.	Optional	COA asserts that Registrars should be required to provide registrants with the “OPTION” to provide Technical Contact information, although provision of this alternative contact information by registrants should not be mandatory. Many registrants may wish to provide secondary contact information, including large corporate registrants who need to route the appropriate communications within their organization, and technically-novice registrants who need to enlist the help of an organization with greater technical expertise to manage their web presence. Requiring that registrars give registrants the option to supply such technical contact information serves ICANN's core mission of ensuring and furthering the stability, security and resiliency of the domain name system because it allows contact to be made with the appropriate technical person or organization (in cases where such a person or organization exists separate from the registrant) to address technical issues more quickly and efficiently.	Yes	See Rationale above. Domain name registrants may well want to supply appropriate technical contact information to resolve more quickly and effectively any technical issue that may arise with respect to their domain names. This serves the interest of both the registrant and the overall mission of ICANN and therefore this should be required of registrars.	No	While COA agrees that administrative contact information should not be required to be collected, we think requiring registrars to give registrants the OPTION to supply this additional data should be the appropriate path forward This gives registrants the flexibility of supplying suitable points of contact if they so choose. Moreover, the SSAC has noted that maintaining administrative and technical contracts plays a role in reducing single points of failure or attack. See: SAC044: A Registrant's Guide to Protecting Domain name Registration Accounts.		Yes		All data should be transferred to the registry in compliance with ICANN consensus policy on transitioning data from thin to thick for the remaining thin registries, including for the .com and .net. top level domains. The GDPR should not impact the remaining transition from thin to thick and transferring data from the registrar to the registry can be readily completed in a manner that is compliant with the GDPR.		Support recommendation as written				Support intent of recommendation with edits	Yes			Contractual compliance is a critical and necessary function of ICANN, and part of its obligations to ensure that registrars/registries comply with their commitments in their contracts with ICANN. As such, the proper lawful basis for contractual compliance should be Art. 6(1)(b), and ICANN should receive all information it deems reasonably necessary to satisfy its compliance function. This means that Annex D, Workbook 5, to the extent incorporated by reference into the recommendation, should be modified to ensure the best legal basis is used (i.e. Art. 6(1)(b)) or it should be revised to state that the lawful basis includes both Art. 6(1)(b) and Art. 6(1)(f). In addition, ICANN should receive all information that it deems reasonably necessary for compliance, not just the “minimum”, to ensure that ICANN can satisfy this important function.	No	Registrant e-mail address should not be redacted. Registrant city should not be redacted.	General consensus across law enforcement, cybersecurity experts, intellectual property rights holders and consumer protection organizations exists that this is the most important WHOIS data element to support investigations and combat a wide range of illegal activity online, including DNS abuse. Registrants should be informed that this data element will remain unredacted and that they have the option of creating an e-mail address for their domain name registrations that contains no personally identifying information. That is a simple thing for any registrant to do and they can do so at no cost. We note that the GAC in its consensus advice issued in its ICANN61 San Juan Communique urged ICANN "to reconsider the proposal to hide the registrant email address as this may not be proportionate in view of the significant negative impact on law enforcement, cybersecurity and rights protection." The city of the registrant is required for serving legal process. If the street address of the registrant is redacted, then the city of the registrant should not be considered personal data warranting redaction.	No	The GDPR only applies natural persons, not legal persons. Therefore to redact an organization name actually runs counter to the GDPR rather than serving as a privacy protection that is either required or supported by the GDPR. Redacting the “organisation” field in the public WHOIS would not only run counter to the GDPR, but it would also go against other important EU regulatory frameworks related to (online) accountability and transparency of businesses and e-commerce in the EU. Article 5 of Directive 2000/31/EC on electronic commerce for example requires that online service providers shall render easily and permanently accessible the following information: (i) their name, (ii) their geographic address, (iii) their contact details, including their electronic email address , (iv) their trade or commercial register number, etc.		Support recommendation as written				Delete recommendation		COA strongly believes that the Registrant's e-mail address should not be redacted and that it be validated by the registrar and made publicly available. Earlier in this document a rationale was supplied as to why keeping the registrant’s e-mail address publicly available is consistent with the GDPR.		Intent and wording of this recommendation requires amendment	The EPDP Team recommends that Registrars are required to retain the herein-specified data elements for a period of three years following the life of the registration.	ICANN itself recommends a longer period of 2 years. Cybersecurity incidents have dwell time that can go years, as the recent Marriott/Starwood breach news proves. Attack indicators can be discovered long after the attack itself, and after DNS resources are deleted. Investigation, particularly when it involves law enforcement, can be lengthy. It’s important that information on previously registered domains is retained for a useful period for security and law enforcement needs. One year is simply not enough time for lookback needs. The consistent utilization, by security and law enforcement personnel, of historic data from various third party Whois services is testament to the need.		On November 16, 2018, the EPDB issued Guidelines 3/2018 on the Territorial Scope of the GDPR. The Guidelines should be consulted by the EPDP Team as it considers the question of differentiating between registrants on a geographic basis. The Guidelines were issued following the expression of positions from contracted parties that it would not be feasible to distinguish between registrants on a geographic basis for the purposes of determining whether the GDPR should be applied. These positions should be reevaluated and further justified in light of the Guidelines, which suggest that it would be possible to agree that redactions to the data of registrants for the purposes of compliance with the GDPR should only be applied where: (a) the contracted party is collecting such data within the context of an establishment of the contracted party in an EU member state, or (b) the contracted party is targeting domain registration services to EU data subjects.	ICANN should be primarily concerned with the the objectives set forth in its mission, which has from the inception of the WHOIS framework included the practice of collecting and displaying the information of domain registrants for the purposes of ensuring the security, stability and resiliency of the DNS as well as transparency and accountability. To the extent exceptions are required to accommodate national laws, the WHOIS Conflicts Policy was agreed. The purpose of this exercise it to determine how to accommodate exceptions to the collection and processing of data to accommodate the GDPR. The purpose should not be to maximize and globalize the application of the GDPR.		The other factors to consider are the practicalities of application and looking to live examples of other businesses and entities--particularly ccTLDs--that are differentiating between legal and natural persons because the GDPR simply does not, by its own explicit terms, apply to legal persons. It is possible to set-up a self-identification system, with supportive educational language, alerting registrants to the definitions of legal and natural persons and to specify that any information provided is attested to be true, accurate and submitted to the best knowledge of the registrant. We note that in the GDPR Domain Industry Playbook v. 1.0 issued by eco it was recommended that “input from DPAs should be sought as to whether a distinction could be made based on a self-identification by the registrant.” Due account should be taken of existing registers (ccTLD, company, trademarks, etc.) to which the GDPR applies. Based on existing processes with various ccTLD registry operators, such as EURid, the distinction can be made based on the self-identification of the registrant together with clear information on the implications of each choice. The registrant must be made aware that the name and contact information of a legal person will be published and that he is responsible for providing non-identifiable contact information.	The distinction would prevent the mis-application of the GDPR and allow for greater transparency and accountability online. The information of legal persons must be made available by default for law enforcement, consumer protection, anti-counterfeiting and cybersecurity purposes. In this regard, the EU E-Commerce Directive also requires legal entities who provide services to Internet users to be transparent and provide their identification and contact information in a direct and easily accessible manner (Art. 5 E-Commerce Directive 2000/31/EC). In situations where it is difficult to separate the data of natural persons from that of legal persons, such as if the legal person is a sole proprietorship, if the name of a person appears in the company’s name, or if the business address is a natural person’s residence, this relevant (personal) information is also already made public on a mandatory basis in the national company register where the legal entity is registered (see art. 30 and onwards of Directive 2017/1132).	With respect to making the distinction between natural and legal persons, COA supports a study or survey that examines current operating examples of the application of the natural and legal person differentiation.	The .TEL gTLD has been making this distinction since at least 2006. See ICAA, TEL Registry Agreement, Appendix S, Part VI, Section B, (May 2016). Generally, in ccTLDS and certain gTLDs, a system of self-identification is implemented where a potential registrant must indicate whether it is a natural or legal person (most notably EURid for .eu, also DNS Belgium for .be, FICORA for .fi, AFNIC for .fr, SIDN for .nl, etc.). The registrant is informed of the implications of this choice (such as the publication of the legal person’s name and contact information) before registering. A registrant which is a legal person must then evaluate whether his contact information refers to an identified or identifiable natural person and adjust accordingly (or not). The CENTR Report on WHOIS Status and Impacts from GDPR determined that “to differentiate between private and organisations as registrants, 68% of registries allow the registrant to self-select. In several cases, the registry uses social security number, business number or even tax file number. 18% make no distinction.” [CENTR Survey - Whois status and impacts from GDPR, June-July 2018, available at https://centr.org/library/library/survey-report/centr-report-whois-status-and-impacts-from-gdpr.html.] Finally Many ccTld registries, included those of European ccTLDs, differentiate between natural and legal person in the registration process. This demonstrates that this differentiation is both practical and workable. Below is a list of examples: .AT legal person data is publicly available in the whois and provides the organization, Street address, Postal code,City, Country, Phone , Email,Nic-hdl .BE legal person data is publicly available in the whois and provides the Organization, language, street address, city, country and phone. Contact form available .CZ legal person data is publicly available in the whois and provides registrant organization, street address, city, country and nic-handle. Also provides the same data fields for admin and tech contact. .DK treats natural and legal person data the same in the publicly available whois and provides registrant organization, street address, city, country and nic-handle. See .dk statement - https://www.dk-hostmaster.dk/en/gdpr .ES legal person data is publicly available in the whois and provides registrant org, admin contact name and name of technical contact .EU differentiates in the publicly available WHOIS record and provides the registrant name, language, city, country and email address. .FI legal person data is publicly available in the whois and provides the registrant name, street address, city, country and phone. Technical contact name and email address. .FR legal person data is publicly available in the whois and provides the registrant org, street address, city, country, phone and email address. Technical contact name, registrant org, street address, city, country, phone and email address. Admin contact, name, registrant org, street address, city, country, phone and email address. .IE legal person data is publicly available in the the whois and provides the registrant org, admin and tech nic-handles .IT legal person data is publicly available in the the whois and provides the registrant org, street address, city, country postal code, phone number and email address. Same data fields are available for admin and tech contact and includes individual names. .LT legal person data is publicly available in the the whois and provides the registrant org, street address, city, country postal code, phone number and email address. Same data fields are available for tech contact. .LV distinguishes between natural and legal person. Legal person data is publicly available in the the whois and provides the registrant org, street address, city, country postal code, phone number and email address. Same data fields are available for admin and tech contact and includes individual names. .LU legal person data is publicly available in the the whois and provides the registrant org, street address, city, country and postal code Admin and Tech contacts are masked. .MT legal person data is publicly available in the the whois and provides the registrant org, street address, city, country postal code, phone number and email address. Same data fields are available for admin and tech contact. .NL legal person data is publicly available in the the whois and provides the registrant org and admin email address. .PL legal person data is publicly available in the the whois and provides the registrant org, street address, city, country postal code. Indicates Organization in the record. .PT legal person data is publicly available in the the whois and provides the registrant org, street address, city, country postal code. Same data fields are available for managing body role. .SI legal person data is publicly available in the the whois and provides the registrant org, street address, city, country postal code, phone number and email address. Also provides Tech contact email address. .SE legal person data is publicly available in the the whois and provides the registrant org, street address, city, country postal code, phone number and Contact ID. Same data fields are available for admin and tech contact and includes individual names.	Support intent of recommendation with edits	Modify the first sentence of the recommendation to read: "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 NonPublic Registration Data has been completed and incorporated in the Team’s Final Report, noting that the term should be modified to refer to “parameters for responding to lawful disclosure requests.”	Third parties that currently have a legitimate interest and lawful purpose for gaining access to non-public registrant data face a confusing array of different registrar and registry requirements and processes to access this data making such access extremely difficult, inefficient and, in many cases, non-existent. The EPDP Team’s work is incomplete until the issue of setting parameters and recommending a process for responding to lawful disclosure requests to redacted data has been resolved.		Support recommendation as written			Based on the factual and legal analysis conducted to date by the EPDP of the data elements processed by the respective parties (ICANN, the Registrars and Registries), it appears that a joint controller relationship exists. COA therefore supports this recommendation. If, however, further findings on this topic result in a different determination of roles and responsibilities, then COA ultimately supports the appropriate controller/processor arrangement that can enable ICANN to assume sufficient legal responsibility such that ICANN can compel relevant contracted parties to respond to WHOIS queries from accredited requestors, most likely as part of a Unified Access Model currently being explored by ICANN.		No, I wish to continue to the next section
51	12/22/2018 15:36:56	Jeremy Dallman, David Ladd – Microsoft Threat Intelligence Center; Amy Hogan-Burney, Richard Boscovich – Digital Crimes Unit; Makalika Naholowaa, Teresa Rodewald, Cam Gatta – Trademark; Mark Svancarek, Ben Wallace, Paul Mitchell – Internet Technology & Governance Policy; Cole Quinn – Domains and Registry; Joanne Charles – Privacy & Regulatory Affairs	Microsoft Corporation	No		No, I would like to continue to the next section	Support Purpose intent with wording change	(I) TO ESTABLISH THE RIGHTS AND OBLIGATIONS OF A REGISTERED NAME HOLDER IN A REGISTERED NAME;	domain, but also in agreement to certain obligations in connection with their registration, and the provision of their data is integral to establishing the identity of the registrant so that the registrar, registry operators and (potentially) third parties are able to identify the party which has undertaken such obligations, even beyond Purpose 3 which deals with communication.	Support Purpose intent with wording change	“Ensuring 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 such as cybersecurity investigations, intellectual property enforcement, consumer protection, DNS abuse mitigation, and law enforcement, to data elements collected for the other purposes identified herein.”	ICANN’s mission is to ensure the stable and secure operation of the Internet’s unique identifier systems, and this requires that ICANN ensure access to domain registration data for criminal law enforcement, cybersecurity investigations, consumer protection, and intellectual property protection. (Note that we do not ask for ICANN’s active involvement in any such investigation, dispute, or litigation. Rather, we submit that ICANN’s role has always been to ensure that the mechanisms exist which enable domain registration data to be made available for those who need it for legitimate purposes.) Microsoft and others are empowered by law in many jurisdictions to protect themselves, and their customers, through the filing of civil cases stemming from cybersecurity investigations. US federal legislation (e.g. the Lanham Act and the Computer Fraud and Abuse Act) has introduced civil causes of actions or claims for private litigants to bring actions. In UK Common Law, the concept of trespass to chattels has been similarly applied. Certain causes of action are specifically tailored for civil cybersecurity cases. In the Rustock investigations, Lanham Act civil seizure warrants were required to take malware servers offline. Brand protection is inextricably linked to consumer protection and the possible harm to consumer is exacerbated by the availability of pirate and counterfeit goods online and the ease with which they can be obtained /purchased. When brand abuse is also used as a mechanism for cybercrime, the consumer risk is increased. Our ability to protect consumers by using these existing statutes and adapt them into the cybersecurity realm has been extremely successful. The original wording does not accurately reflect this. Key to these statutes is the concept of notice. For us to bring any type of case, we must show the court that there has been a legitimate attempt to provide Notice of Process. If we can’t provide this to the court, the case may be dismissed. We will discuss some implications of this elsewhere where publication of email addresses is discussed, but it should be apparent that many types of civil actions and dispute resolutions depend on identifying and contacting registrants. Therefore, we believe that more specificity is required to clarify that legitimate third-party interests play an important role maintaining the security, stability and resiliency of the domain name system, a role which has been impaired since the registrars and registries began making registration data unavailable to these legitimate third parties. In this regard, we are encouraged by the recent opinion of the ICANN Security and Stability Advisory Committee. Microsoft has relied on registration data for many types of investigations, both reactive (identifying bad actors after known attacks) and proactive (using registration data to prevent future attacks by these same actors), and our work provides important support to law enforcement. A few Microsoft investigative efforts using registration data are documented here: • Anti-Phishing Working Group’s study • Cybersecurity Tech Accord study Finally, in cases where Microsoft trademarks and intellectual property have been abused, and related cybersecurity issues have not been identified, it is often the case that a letter or email from Microsoft informing a registrant of the problem is enough to resolve the issue. This desirable outcome benefits all parties and depends on access to accurate data.	Support Purpose intent with wording change	“ENABLE COMMUNICATION WITH AND/OR NOTIFICATION TO THE REGISTERED NAME HOLDER AND/OR THEIR DELEGATED AGENTS OF TECHNICAL, LEGAL, AND/OR ADMINISTRATIVE ISSUES WITH A REGISTERED NAME.”	In addition to administrative issues, communication should be enabled for legal issues involving a domain name. Enabling communication for legal issues ensures proper notice and due process where a domain name might implicate certain legal matters.	Support Purpose as written			Support Purpose as written		Our support for the statement as written is based on the assumption that existing accuracy obligations will continue to be contractually maintained and effectively enforced by ICANN. Our cyber research and digital crimes investigations benefit when the registration data is accurate. Often registrants are unaware that they have been compromised and being able to contact them when anomalous behavior is detected can be helpful. This is one way that accurate registration data allows us to protect registrants, Internet users, and general consumers. Likewise, in cases where Microsoft trademarks and intellectual property have been abused, it is often the case that a letter or email from Microsoft informing a registrant of the problem is enough to resolve the issue. This desirable outcome benefits all parties and depends on accurate data. To the extent that the data is not accurate, we require the compliance functions to be in place and enforced by ICANN to hold registrars accountable to their accuracy obligations.	Support Purpose intent with wording change	“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, BUT INCLUDING WHERE SUCH POLICIES TAKE INTO ACCOUNT USE OF THE DOMAIN NAMES), NAMELY, THE UDRP, URS, PDDRP, RRDRP, AND ANY FUTURE DEVELOPED DOMAIN NAME REGISTRATION¬-RELATED DISPUTE PROCEDURES FOR WHICH IT IS ESTABLISHED THAT THE PROCESSING OF PERSONAL DATA IS NECESSARY. THIS PURPOSE SHOULD NOT BE READ TO LIMIT ANY OTHER PURPOSE WHERE PROCESSING OF DATA HAS BEEN RECOGNIZED AS LEGITIMATE IN CONNECTION WITH FACILITATING INVESTIGATION AND ACTION CONCERNING ANY OTHER LEGAL ISSUES INVOLVING A DOMAIN NAME, INCLUDING HOW A DOMAIN NAME IS USED.”	The language of the recommendation as currently written is not a full and accurate quotation from the ICANN Bylaws, and seems to conflict with the provisions of the UDRP and URS policies. The amended text above rectifies this. We also note that investigations into trademark disputes often detect serious Internet threats. For example, a domain name which mimics a Microsoft trademark may in fact be the endpoint for a phishing attack leading to credential harvesting or malware infection.	Support Purpose as written				A. A new purpose to address the needs and benefits provided by DNS security and stability research conducted through publication of reports on threats to the operational stability, reliability, security, global interoperability, resilience, and openness of the DNS, and on the accuracy of WHOIS. B. A new purpose to enable ICANN to conduct operations, facilitation activities, and implement consensus policies (adopted in accordance with the ICANN Bylaws) consistent with its mission of furthering the operational stability, reliability, global interoperability, resilience and openness of the DNS.	A. Research is a legitimate basis for processing per GDPR Article 6(1)f, with specific safeguards defined in Article 89. It is also squarely within ICANN’s mission and mandate, as the requirement for research derives from Section 1.2a (Commitments) of the ICANN bylaws: (i) Preserve and enhance the administration of the DNS and the operational stability, reliability, security, global interoperability, resilience, and openness of the DNS and the Internet; (ii) Maintain the capacity and ability to coordinate the DNS at the overall level and work for the maintenance of a single, interoperable Internet; This purpose exists to ensure that ICANN may continue to use registration data in support of its mission, while maintaining data subject privacy through appropriate safeguards such as pseudonymization. In addition, this purpose enables ICANN to continue to operate its Accuracy Reporting System (ARS), which publishes periodic reports on accuracy, using full WHOIS contact fields. The ARS is an important program approved by the ICANN Board in response to the recommendations from the 1st WHOIS Review Team. B. Prior to the May 25th adoption of the Temporary Spec, and consistent with its mission and mandate under the Bylaws, ICANN used full WHOIS data as part of op/sec related activities of the Office of the CTO to collaborate with public/private sector investigators, to train law enforcement agencies in techniques for mitigating cybersecurity threats such as CONFLICKER, or to work with a compliance related complaint. It also used WHOIS as it implemented consensus policies that involve the use of WHOIS data fields (such as in transfer policy processes or Thick WHOIS). It is important that ICANN continue to provide these services to enhance the DNS.	No, I wish to continue to the next section	Support intent of recommendation with edits	“In this context, a method for promptly and predictably disclosing non-public registrant data to third parties who have demonstrated legitimate interest in viewing registrant data such as those that perform cybersecurity investigations, intellectual property enforcement, consumer protection, DNS abuse mitigation, and law enforcement will be developed.”	The existing text seems to imply that intellectual property infringement and DNS abuse cases are only worth being “considered” and are not first-class legitimate purposes for performing disclosure. We disagree with this assertion and suggest the edits above to clarify any ambiguity about this. As stated elsewhere, brand abuse is increasingly an enabling mechanism for cyber abuse. It should be clear that consumers can be harmed when what seems to be a branded pharmaceutical good is actually a low-quality counterfeit, but many are not aware that fake branded digital goods may actually contain malware or connect to phishing sites which are used to harvest credentials or drop malicious payloads. We are seriously in need a standardized and dependable method for requesting nonpublic registration data during an investigation with reasonable expectation that our request will be swiftly reviewed on its merits and the data disclosed appropriately. The EPDP team is obliged by charter to deliver a proposed model of a system for providing access to non-public Registration Data, not to “consider” doing so. Now that the gating questions have been addressed, it is time for the EPDP team to proceed to this next required activity.		Support intent of recommendation with edits	The EPDP Team recommends that accuracy requirements under the current contracts must be maintained.	We notice that the registration data set frequently contains many inaccuracies. Although even the inaccurate data is of use in cybersecurity investigations, it is much less useful for issue resolution processes such as UDRP. If the accuracy of the data can somehow be improved by changes to ICANN processes and policies, we would support such improvements.		No, I wish to continue to the next section	Yes		These data elements, which are all of use in cybersecurity investigations, are required by ICANN to fulfill its Mission and are in line with ICANN’s pursuit of a legitimate interest in this data.	Registrars should be required to provide an option for registered name holders to indicate they are either a Legal or Natural Person.	GDPR does not apply to Legal Persons. Allowing registered name holders to indicate they are such Persons clarifies the legal basis to publish the appropriate data fields.	Optional	Question 46, as written, does not offer support for our position, which is that (1) all registrars must provide the option (2) the registrant may elect not to take the option (3) if the registrant elects to submit the data, the registrar must publish it. As a good practice, registrants should provide Technical Contact information (at least a phone number or email address). For many registrants technical support is best managed by someone else, and for organizations, it often makes sense to create a distinct role for performing this technical support task. If this were made optional for registrars, registrants may not realize that they have recourse to select a different registrar; even if they realize this, they may not discover the need to select a different provider until far into the purchase process. And registrants with existing technical contacts may discover too late that their registrar has elected to no longer support that feature. Registrants should be protected from such situations, and our policy must reflect the need to offer such consumer protection.	Yes	As a good practice, registrants should provide Technical Contact information (at least a phone number or email address). Thus, it should be mandatory for registrars to offer this capability. See further discussion in #47, above.	No	As a good practice, registrants should provide Administrative Contact information (at least a phone number or email address). This contact information is not as important in actual practice as the Technical contact information, but we see no reason to stop collecting it if the registrant wants to submit it.		Yes		Sometimes in the course of an investigation it is more effective, or even required, to work with a registry than the registrar. For example, registrars manage only subsets under a given extension. If the legitimate purpose involves large numbers of domains, then it is more logical to work with a Thick registry. In another example, a registrar may be nonresponsive to lawful requests from a third party. In those cases, it is better if the registry holds a copy of the data.		Support intent of recommendation with edits	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 provide mechanisms for safeguarding Registered Name Holders' Registration Data. 3. In addition to 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 and the administrative contact, technical contact and any specialized data required by the registry should also be collected by the Registrar and transmitted to escrow providers (see Annex D, Workbook 4).	In the interest of registrant protection, all data collected should be transferred to the data escrow provider. Note that not all of the data collected is in the workbooks – some registries hold special data specific to a particular TLD.		Intent and wording of this recommendation requires amendment	Yes		When a registrar/registry collects registrant data it should be transferred to ICANN. All the data elements listed in Workbook 5 should be transferred from the registrar/registry to ICANN, and any other applicable registrar/registry-specific registrant data collected by registrar/registry should be also transferred to ICANN. We notice that the registration data set frequently contains many inaccuracies. Although even the inaccurate data is of use in cybersecurity investigations, it is less useful for dispute resolution, and if the accuracy of the data can be improved by the ICANN compliance processes and policies, we support them.		No	Email fields should not be redacted. Organization Field should not be redacted. City should not be redacted. Privacy / Proxy data should not be redacted. The registration of a legal person registrant should not be redacted.	Please note that our responses assume that processing shall be lawfully disclosed to the registrant at the time of data collection. Email addresses are important for both identifying and contacting registrants in the normal course of business, and not only during investigations. Registrants have the easy ability to create a new email address at no cost for the purpose of registrant communication which does not reference the registrant’s name (if a natural person) or other personal identifiers. Organization names provide additional means for identifying and contacting registrants when the other fields are unreliable and is also indicative that the registrant is a legal person. Since organizations are not covered by GDPR, Organization fields should not be redacted anyway. The City field is used in resolution cases where determination of jurisdiction is needed to identify proper venue for litigation and understand which controlling law and procedure applies. Several states contain multiple districts with differing law and procedure. Proxy data is the data of a legal person (the proxy provider) and should never be redacted. Data which is redacted requires requests for disclosure. This impedes the normal course of business, and adds delay to investigations where time may be of the essence. In some cases, contact for Notice of Process is required; in some other investigations (and not just collaborations with law enforcement), it is sometimes best not to disclose to the registrant that they are being investigated, and over-redaction impedes this. Web forms are not an effective method to replace email addresses. When using a web form, there is no assurance that mail was transported to the contact, that it was received into the target mailbox, or that it was read. At minimum, a registrar must provide an account-level anonymized email address, consistent for all registrations by that registrant at that registrar, rather than a web form. Account-level anonymized identifiers have been investigated by SSAC and other parties and should be considered. See https://www.icann.org/en/system/files/correspondence/jevans-to-marby-et-al-04jun18-en.pdf for one such example. The effectiveness of email for contactibility cannot be overstated. As mentioned elsewhere, civil action requires proof of Notice. It is often the case that a bad actor will enter various inaccurate registrant data in order to resist detection, yet submit a working email address, if for no other reason than to use the notice presented to that email address as a trip wire alerting them to the need to start deleting accounts or otherwise covering their tracks. Note that an account-level anonymized email specific to a single registry or single registrar, though better than a web form, is still not as effective for contacting or identifying bad actors as a DNS-wide anonymized identifier applicable to all registrations by a registrant across all registrars. Such a DNS-wide anonymized identifier has also been discussed by SSAC and other parties and should be considered. In response to arguments that anonymized email addresses are also personal data which can be used to identify a data subject when combined with other data, and which therefore must also be redacted: GDPR does not require absolute anonymization, and we assert that pseudonymized email addresses satisfy the requirements of the GDPR.	No	Since organizations are not covered by GDPR, Organization fields should not be redacted.		Support recommendation as written	Since organizations are not covered by GDPR, Organization fields should not be redacted. If additional information will be provided to a registrant in order to inform the intended use of the Organization field, we are supportive. In response to arguments that Organization fields should be redacted in case they contain personal data or might identify a data subject in some circumstances: Where natural persons have created corporate entities using their names, those business names do not exist as unique identifiers for natural persons and do not require the protections for natural persons. In these circumstances, the business name with the business information (address, phone, corporate email) is not the personal data of any natural person and the protections for natural persons are not required.			Intent and wording of this recommendation requires amendment	“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 when a registrant’s contact data must be redacted should be changed, to wit: • Registrar MUST provide an email address to facilitate email communication with the relevant contact; this MUST be the original email address of registrant if the registrant is a legal person. • The email address SHOULD be unique and uniform across domain name registrations at a given Registrar. • If the communication mechanism is provided by the registrar (web form or hosted email service) it MUST provide functionality to forward communications received to the email address of the applicable contact and MUST describe the methods used to forward communications and confirm receipt. • If a web form is provided, it MUST also provide functionality to forward communications received to the email address of the applicable contact and MUST describe the methods used to forward communications and confirm receipt. • Registrar MAY implement commercially reasonable safeguards to filter out spam and other form of abusive communications.”	As MarkMonitor has noted elsewhere, “the number of domains listed per UDRP filing is down over 10% since May 25, 2018, evidencing increased difficulty in connecting infringing domain names in UDRP filings.” We note that creating an anonymized DNS-wide identifier (as mentioned in 68, above) has not yet been reduced to practice, and may not be available in the desired timeframe. As a result, the original email addresses remain the best mechanism for contacting and identifying bad actors who operate across several registrars. Web forms do not function as a unique identifier as an email address does, and do not provide the same delivery notices or read notices. When web forms are offered, they must not impose unreasonable and unrealistic character limits.		Support intent of recommendation with edits	“The EPDP Team recommends that Registrars are required to retain the herein specified data elements for a period of 3 years following the life of the registration.”	ICANN recommends a longer period (2 years) in the 2013 RAA. Although ICANN RAA may change as a result of the EPDP process, the point is worth noting. Although many investigations can proceed with data retained only one year after expiration, recent investigations reveal that some adversaries conduct subsequent attacks long after an attack has been concluded and that some attacks are only discovered after the event. Having a longer history of registrant data has also aided in proactive detection of new attacks by these previous attackers.		On November 16, 2018, the EDPB issued Guidelines 3/2018 on the Territorial Scope of the GDPR. “<https://edpb.europa.eu/sites/edpb/files/files/file1/edpb_guidelines_3_2018_territorial_scope_en.pdf>	The Guidelines indicate that redactions to the data of registrants for the purposes of compliance with the GDPR should only be applied where (a) the contracted party is collecting such data within the context of an establishment of the contracted party in an EU member state, or (b) the contracted party is targeting domain registration services to EU data subjects.	Although it is likely that additional privacy laws will be passed outside of the GDPR zone, it is not certain that such laws will be subsets of GDPR (i.e. application of GDPR-like redaction to all geographies may not remove additional legal obligation). History has shown that various compliance requirements are usually overlapping and intersecting rather than super/subsets. It would be short-sighted to create a new policy which is inherently unable to accommodate geographic differences and the local-law variations they represent. There are country-based laws, as well as regional laws and treaties that are important for parties to be aware of in the event that specific business conduct is contemplated.	It is practical to design a user experience which at the time of registration clearly informs the registrant of the data processing which will occur in their geography and how such processing may be impacted by their identification as a legal person or as a natural person. Such a system might include self-attestation, be derived from other data such as use of the Organization field or use of a purchase order, or a combination of several factors. Note that many European country-code registries already apply geography-specific policies, which should demonstrate the practicality of such an approach.	Unnecessary redaction of data makes investigations and dispute resolution unnecessarily difficult. A registrar should clearly inform the registrant of the data processing which will occur in their geography and how such processing may be impacted by their identification as a legal person or as a natural person, then make a distinction between natural and legal persons during registration and publish the registration data of companies separate from natural persons. Note that in situations where it is difficult to separate the data of natural persons from that of legal persons, such as if the legal person is a sole proprietorship, if the name of a person appears in the company’s name, or if the business address is a natural person’s residence, this relevant (personal) information is already made public on a mandatory basis in the national company register where the legal entity is registered (see art. 30 and onwards of Directive 2017/1132).		Many examples from various ccTLDs and gTLDs have been provided by multiple other parties and will not be repeated here. Suffice it to say that there is enough evidence that the distinction is being routinely made by many registries.	Support intent of recommendation with edits	“Furthermore, the EPDP Team recommends that definitions, criteria, and processes around the term ‘reasonable access’ be determined as part of the final policy addressing:”	“Reasonable access” must be defined in a complete and holistic fashion Data recently published by MarkMonitor, a leading brand protection company, revealed that nearly 80% of the disclosure requests for registrant data made to registrars under the current Temp Spec have been either ignored or denied. <https://www.markmonitor.com/mmblog/gdpr-and-whois-adverse-impacts-on-brand-protection> This does not seem “reasonable” and is a consequence of the Temp Spec’s lack of definition for the term. In the absence of a definition, every registrar must define their own standard of reasonableness, and this has generally resulted in no access at all.		Support recommendation as written	Microsoft supports whatever controller/processor arrangement enables ICANN to assume enough legal responsibility such that ICANN can compel its contract parties to respond to WhoIs queries from accredited requestors, most likely as part of a Unified Access Model currently being explored by ICANN. We agree that a joint controller arrangement looks promising and we support the recommendation that ICANN Org negotiates and enters into a Joint Controller Agreement (JCA) with the Contracted Parties.				No, I wish to continue to the next section
52	12/22/2018 16:07:10	Evin Erdoğdu	ICANN	Yes	This set of responses is being submitted by At-Large support staff on behalf of the ALAC	No, I would like to continue to the next section	Support Purpose as written			Support Purpose as written			Support Purpose as written			Support Purpose as written			Support Purpose as written			Support Purpose intent with wording change	The parenthetical phrase “(AS OPPOSED TO THE USE OF SUCH DOMAIN NAMES) effectively nullifies the references the UDRP and the URS since both may use evidence of how a domain is being used. It is also counter to the related ICANN Bylaw provision in Annex G-1 where the wording ls “resolution of disputes regarding the registration of domain names (as opposed to the use of such domain names, but including where such policies take into account use of the domain names)” A possible rewording might be: ”COORDINATE, OPERATIONALIZE, AND FACILITATE POLICIES FOR RESOLUTION OF DISPUTES REGARDING OR RELATING TO THE REGISTRATION OF DOMAIN NAMES, NAMELY, THE UDRP, URS, PDDRP, RRDRP, AND FUTURE DEVELOPED DOMAIN NAME REGISTRATIONRELATED DISPUTE PROCEDURES FOR WHICH IT IS ESTABLISHED THAT THE PROCESSING OF PERSONAL DATA IS NECESSARY. THE USE OF SUCH DOMAIN NAMES MAY NOT BE A CONSIDERATION UNLESS THE POLICY TAKES INTO ACCOUNT USE OF THE DOMAIN NAMES.”	The ALAC has no particular interest in Trade Mark issues per se. However, in many cases the intent of trademark abuse is to confuse or defraud an unsuspecting individual Internet user, and THAT is directly in the remit of At-Large and the ALAC. Therefore it is essential that policies and processes such as the URS and UDRP continue unimpeded by the GDPR implementation, to the utmost extent possible. In relation to the URS, one of the reasons for the request for a rapid suspension of a website is offensive website content. According to section 1.2.4 of the URS the content of the complaint may include a copy of the offending portion of the website content. Section 3-IX of the UDRP says" the complaint should describe the grounds on which the complaint is made including in particular why the domain names should be considered as having been registered and being used in bad faith." and section 3-viii of the UDRP also refers to the usage of the domain name.	Support Purpose as written			The ALAC sees that activities like the WHOIS Accuracy Reporting System (ARS) and the use of the WHOIS registration data by the office of the chief technology officer (OCTO) for training and outreach are not fulfilled through the aforementioned purposes. In addition ICANN needs to continuously advance its operational and administrative role in relation to the stability, reliability, and security of the Internet and to do so research is needed. Therefore ALAC recommends adding additional purposes that can address the aforementioned needs.	1) ARS (Accuracy Reporting System) 2) The Office of the Chief Technology Officer (OCTO) research and threats analysis/prevention	Both of these are topics which are just starting to be discussed in the EPDP, but this will serve as an introduction: ARS: The ARS was instituted in response to a recommendation of the WHOIS Review Team related to the accuracy of registration contact data. Studies had shown that there was a significant issue with data accuracy. Every 6 months (pre the Temp Spec) the ARS samples randomly selected gTLD registrations and tests the contact information for accuracy using a number of criteria. Those failing accuracy tests are passed to Contractual Compliance. In recent cycles, about 40% of all records samples have at least one contact entry that fails validation. Under the 2013 RAA, new registrations, those transferred to a new registrar, or those where there is a voluntary change of contact information must pass specific validation and verification test, but the vast majority of registrations have not been subject to such tests (an estimated 180,000,000). Under GDPR data must be accurate for the purpose under which it is processed. Purpose 2 and 6 both pass contact data to parties who have an expectation of accuracy and there is no way to understand whether this is being done without accuracy monitoring. OCTO Research: ICANN is responsible for the DNS which includes fully understanding all aspects of it. Activities may include addressing DNS threats and potentially developing an evolution of it or a dissimilar replacement. To do that it needs to have access to all aspects of the DNS. If ICANN were a typical controller, it would have access to all of the data to begin with, and this would be covered under Recital 50 (secondary processing provisions), but since ICANN is not in possession of the data, we must make sure that it has suitable access.	No, I wish to continue to the next section	Support recommendation as written				Support recommendation as written				No, I wish to continue to the next section	Yes			The elements that have been deleted related to Admin contacts should be reinstated pending a clear understanding on how the existing data in these fields (when it is unique to those fields) will be handled by registrars and registries. Registrant-provided data must not be unilaterally removed without due consultation with the data provider. Moreover, under the 2009 RAA, which governs a very large number of registrations, there was no requirement to collect Registrant telephone or email. If the Admin field is eliminated, there may be NO contact information in the record (and in the escrowed records). There must be a new field where the registrant must declare whether it is a natural or legal person. This field must be collected regardless of whether it is used at this stage to determine what data is redacted.	Registrants have provided contact data in good faith and that data must be honoured by the Registrar/Registry. If it is to be changed, there must be process developed to ensure that the registrant agrees. To do otherwise is having the controller/processers alter registrant data without their approval and is counter to the intent of the GDPR. A registrant that has chosen to place administrative responsibilities with a specific person or entity must not have that changed unilaterally, and the ability to do so should not be unilaterally removed. Without the Admin fields, there is the potential for a registration record having telephone or email contact details for the entity responsible for the registration. Technical contacts cannot be presumed to have authority over the domain registration. A field identifying the natural/legal status of the registrant must be collected in light of the GDPR’s reliance on this differentiation, and the likelihood that other jurisdictions may also treat the two differently.	Mandatory	The answer depends on how the field will be handled when legitimate requests for the fields are addressed. If in the absence of information being provided by the registrant, some other contact information will be provided, the OPTIONAL is ok. If blank fields will be returned, then the answer here must be MANDATORY To be clear, in version 2 of “optional” it is unclear what value would be returned if there is a lawful query for technical contact fields. That lack of clarity makes this question impossible to answer neatly.	Yes	All registrants should be given the option of providing the data. The concept that if a registrant wants to provide this data, they need to look around for a registrar that allows its entry is ridiculous. Registering a domain name and then taking care of it is a sufficiently complicated task that adding a “search” part of the process, when a potential registrant does not even know that the field exists or may not exist for a given registrar adds a level of complexity that would be difficult to document and deceptive to not ensure that a registrant understands their options.	No	See answer #44 for Admin contacts. Billing contacts are not part of the public WHOIS and the ALAC has no concern what is done with them.		Yes				Support recommendation as written				Intent and wording of this recommendation requires amendment	Yes			It is unclear if the wording needs to be changed, but the ultimate result must be that Compliance has immediate access to registration data without having to make an explicit request and wait for reply. Having to formally request data and then restart the investigation when it arrives needlessly increases the complexity of the costs of Contractual Compliance.	Yes			No	There are a number of reasons it should not be redacted. - For web sites (and other Internet resources) that are nominally commercial, Internet users should have SOME ability to know who is behind it (or if it is being hidden by Privacy/Proxy). Without the Organization field, there is NOTHING. - It is possible that the EPDP recommendations may allow all registrants to be treated as EU Natural Persons with significant redaction. - The Temp Spec has required the Organization filed to be displayed and there has not been any evident major issue about it. - It is an OPTIONAL field to fill in and Registrants can be warned that it will be displayed if filled in. So there is no reason to NOT display it.		Support recommendation as written				Intent and wording of this recommendation requires amendment	…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 remain in place, and that the requirement that Registrar MUST NOT identify the contact email address or the contact itself be subject to the registrant being given an option to consent to the allow the information to be publicly published/displayed.	A registrant that wishes to display their contact information should be allowed to do so.		Support recommendation as written						There are risks associated with NOT differentiating registrants on a geographic basis. Under GDPR a registrar who operated solely outside of the EU and does not explicitly target potential registrants within the EU is not subject to GDPR. Cybersecurity professional have effectively used registration data to combat Internet security issues. The more information that is redacted, the more these cybersecurity professionals are crippled in their efforts. It is known that certain contracted parties have welcomed those who register domains for abusive uses. Allowing those contracted parties outside of the EU to redact all information gives the domain name abusers free reign. Note that a new guidance document from the EDPB makes it clear that an entity wholly external to the EU that does not explicitly target customers within the EU is NOT subject to GDPR, even if some customers in the EU happen to utilize their services.	The ALAC strongly supports differentiation of Legal and Natural Persons. GDPR only applies to Legal Persons. Although a Legal Person’s registration data may contain personal information, as per EDPB recommendations, they should be advised to take care to ensure that they are not doing so without due authorization.	The risks listed in reply to #86 apply here as well. If there are particular risks associated with treating specific classes of legal persons as described here, they need to explicitly enumerated with carve-outs.	The ALAC does not believe that further study is needed, but is willing to consider rationale’s provided by others.		Intent and wording of this recommendation requires amendment	It is unclear what the ALTERNATIVE is to continuing to use the current methodology.								No, I wish to continue to the next section
53	12/23/2018 6:51:15	Sivasubramanian Muthusamy	Internet Society India Chennai Are	No	Comments as an individual	No, I would like to continue to the next section	Significant change required: changing intent and wording	IV) To ensure transparency in the Domain Name Registration process.	It is important to ensure the availability of unregistered names to natural and artificial persons without the availability status being masked in the middle paving way for speculative transactions by intermediaries which may not always be fair. This purpose is added to ensure fairness in the availability of Domain Names to natural and artificial persons; It is acknowledged that some names that are beyond the purview of TradeMarks are desirable names by many, hence have a premium value. To ensure fairness and transparency of opportunities for registering premium names by existing and new processes between ICANN and Registries.	Significant change required: changing intent and wording	MAINTAINING THE SECURITY, STABILITY, AND RESILIENCY OF THE DOMAIN NAME SYSTEM IN ACCORDANCE WITH ICANN'S MISSION THROUGH THE ENABLING OF the necessary degree of transparency for all users of necessary data elements concerning personal Domain Names, relatively more information concerning commercial Domain Names, LAWFUL ACCESS FOR different classes of LEGITIMATE THIRD-PARTY INTERESTS qualifying for different levels of privileges TO pertinent additional / redacted DATA ELEMENTS COLLECTED FOR THE OTHER PURPOSES IDENTIFIED HEREIN	In this section, the Purpose is further clarified by the proposed text which emphasizes the preservation of Registrant Data by the earlier whois process which made data elements largely available for all users. Whois, by any other name, with fewer data elements where necessary, needs to exist for the benefit of all users; Some data fields may be designated as sensitive and redacted, but Lawful Access by Law and Order Agencies for part or all of the redacted data of all or requisitioned domain name registrations is to be defined; Same or lesser level of lawful access by Third Parties to be separately defined. The rationale for distinction between commercial and non-commercial Domain Names is further expanded in response to Question#1 and #87	Support Purpose intent with wording change	ENABLE COMMUNICATION WITH AND/OR NOTIFICATION TO THE REGISTERED NAME HOLDER directly as far as possible AND/OR through THEIR DELEGATED AGENTS OF TECHNICAL AND/OR ADMINISTRATIVE or other important ISSUES WITH A REGISTERED NAME	This is in consideration of the possibility that in the case of some individual users, some small businesses and even some large businesses, the process of designating an agent is sometimes careless, and it is not always that the communication to the designated agent reaches the actual Registrant; The proposed modification to the text is to emphasise that Registries and Registrars have a purpose in reaching the Registrant, directly as far as possible, and "through" the designated Agent where direct communication is not possible.	Support Purpose as written			Support Purpose as written			Support Purpose as written			Support Purpose as written				1. Mitigation of Domain Name Abuse. 2. To improve consumer trust in the Domain Name System	The rationale is the same as provided in answer to the question on differentiation between legal and natural persons	No, I wish to continue to the next section	Support intent of recommendation with edits	Per the EPDP Team Charter, the EPDP Team is committed to considering a system for DIFFERENT CATEGORIES of Standardized Access to non-public Registration Data ....	If not intended already, standardisation needs to be considered as NOT a single standard for access to all non-public data by all legitimate requests, but different standards for access with different privilege levels to different data elements by differentiated legitimate requests; for instance requests by International Law and Order Agencies and a Commercial third party, both making legitimate requests may NOT access data by a single standard of access, NOT by the same level of privileges.		Intent and wording of this recommendation requires amendment	The EPDP Team recommends that requirements related to the accuracy of registration data under the current ICANN contracts and consensus policies shall not be NEGATIVELY affected by this policy.	There is a need for improvements related to the accuracy of registration data. The existing level of registration data accuracy is inadequate.		No, I wish to continue to the next section	Yes			What is shown as "Optional" Data elements need to be "Required" data elements in the case of domain names registered for existing or intended commercial webspaces, perhaps with stipulations for collecting additional data elements. A domain name may be classified as a “Commercial” Name voluntarily by the Registrant during Registration; This determination could also be made post-registration by automated crawling for features of commercial activity, to be agreed as such by ICANN Community, (for instance the presence of a payment interface or pricing or subscription information). ICANN may have to consider ways of making a distinction between individual and commercial domain names based on the web spaces the domain names point to; Such a distinction goes beyond making a distinction between natural and artificial persons to include within the class natural persons using domain names commercial use; For this class of domain registrations, the emphasis needs to be on transparency rather than privacy, on more data elements rather than minimal data elements. This class may not qualify for blanket redactions; This class may also include legally non-commercial entities using web spaces for raising funds in any form, and also include Government Agencies who do not have a need to be anonymous.	The rationale is the same as provided in answer to the question on differentiation between legal and natural persons	Mandatory	Often there is a disconnect between the Registrant and the Technical contact, where the technical contact is a different person or entity. The technical contact is more important to ensure the Security and Stability of the DNS, in various situations.			Yes	Billing and Administrative Contacts are two categories too many; The number of categories could be limited to two, namely Registrant and Technical Contact data, with the stipulation/ understanding that the Registrant is responsible for Billing and that either the Registrant or Technical Contact be designated as Administrative Contact.		Yes		ALL data elements are to automatically transferred or better REPLICATED for the Registry. The Registry is to be deemed the ultimate custodian and broadly accountable for any data collected by the Registrar / Reseller by a system of Data Control agreements initiated by the Registry, binding on the Registrar and through the Registrar on the Reseller. The method of Registrant Data collection could also change. As in credit card transactions, where the card holder submits card information directly to the card company even though the form for card information is in the merchant's website, Domain Name registrations could have system of gathering Registrant Data by a similar Registry's form directly connected to the Registry Database, from where the essential data elements necessary for the Registrar / Reseller's future commercial correspondence be transferred back to the Registrar / Reseller.		Intent and wording of this recommendation requires amendment		ICANN's idea of Data escrow arises from visualizing scenarios of Registries not having adequate storage redundancy or rare scenarios of Top Level Domain Names discontinuing operations so abruptly that they don't even reliably transfer data to the alternate Registry Service Provider mandated by the gTLD agreements. While there is some rationale for data escrow, the escrow stipulation amounts to data replication - This is yet another copy of the database. Whatever be the security standards, whatever be the safeguards, an additional copy of the database increases risk of privacy hazards. If this storage redundancy is indeed required, then ICANN could consider ways of building inhouse capabilities for usually locked redundant storage.		Support intent of recommendation with edits	Yes		The wording could be modified as below 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 (replace "process" with "collect") - delete - "when required/requested" - delete , 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 ( replace "specifically-identified" with "all" ) data elements the EPDP Team recommends be transferred from registries and registrars to ICANN Compliance (see Annex D, Workbook 5)		No	In the case of Registrants registering domain names for commercial webspaces, none of the data elements to be redacted; more data elements may be necessary.		No		This comment submission in various sections emphasises the importance of making a distinction between registrants registering a domain name for individual webspace (for instance a personal blog) and a registrant registering a domain name for commercial use (for instance a website with a payment gateway or bank account details); With such a distinction between personal and commercial domain names the "Organization" field is essential for commercial domain names, but non-essential for personal domain names. What is referred to as "commercial domain name" is usually domain names registered by business entities legally known as artificial persons, but also includes individuals carrying out commercial activity in the webspace linked to the domain name, and non-commercial legal entities raising funds.				The "organization" field needs to appear only in the section for commercial name registrations in the extended Domain Name Registration form	Support recommendation as written				Support recommendation as written				The EPDP may not introduce such a complication for Registrars and Registries, but would rather insist on the non-geographic nature of the Domain Name System.	It would reverse the evolution of the global DNS; Also, it is not practical for Registries and Registrars to differentiate between Registrants on a geographical basis and grant different privileges, apply different rules between Registrants from different Economic Zones, from across 195 countries, some with multiple provincial legal frameworks.		In Data Protection terminology, "Personal data" is more of a generic or 'loose' term that happens to apply indiscriminately both to individual and business data. In DNS, Registration Data does not make any distinction between individual registrants and business registrants whose web space is for some form of (e)commerce activity. While there is a need for privacy of personal data of individual registrants, the opposite, need for greater transparency, may be required in the case of data related to any form of commercial, perhaps even Government and non Government web spaces. The rationale is that the online presence of small and large businesses alike are often short of information pertaining to physical location, names of functionaries, officials or the person in-charge. A Phone company does not have listed phone number, an email company does not have a visible email addresses! This is part of a pattern of multiple players transacting business online from a carefully guarded climate of "do-not-reply" email accounts, phones without a call back number, answering machines, conveniently assisted by BPO intermediaries who keep the consumer at an unapproachable distance. A hotel reservation portal or a small shop online transacts business online without allowing the consumer the ability to reach them for various reasons Limiting access to Registration data without discrimination of whether the data belongs to an individual as personal data or if it is Registration data of a domain name that points to a commercial web space, and limiting access only for 'legitimate uses' may perpetuate this trend of inaccessibility of business entities, widen the disconnect between business and consumer with the effect that multiple commercial registrants would continue to design their online presence to transact business without due accountability. The sections on Lawfulness & Purposes of Processing gTLD Registration Data as written, might have the unintended consequence of perpetuating unhealthy protection for segments that actually require information disclosure and transparency. EPDP team could actively consider this, and persuasively convey to Europe that ICANN as a responsible global multistakeholder organization would make this distinction in global public interest. Also, for this specific purpose, it is not sufficient to fit data into two classes namely "identifiable natural persons" and "artificial persons". The emphasis here is on Domain Names of Web spaces with commercial activity or intent, usually distinguished by the presence of a payment gateway or other forms of payment information; In this context, it is not sufficient if incorporated companies legally known as "artificial persons" are alone classed for additional data elements for transparency. Commercial Activity could also be undertaken by non-commercial entities in the form of subscription plans or donation requests; by individuals who operate businesses as individuals; Registrant Data needs to make a distinction between personal domain names such as the domain name for a personal blog and a commercial domain name which carries out any form of commercial activity.	GDPR is a good start. It is a very good start. It seeks to set right certain imbalances concerning the collection and use of personal data. However the GDPR may have to be more balanced in its next versions. What is legislated to safeguard privacy rights may get distorted to compromise other values, such as transparency. One example from history is from the legislation on Rights. A thoughtful author cites in his book, "Of the ten amendments that make up the US Bill of Rights, corporations have successfully asserted the applicability of five to win protections for themselves. These include the First Amendment right to free speech; the Fourth Amendment freedom from unreasonable search and seizures; the Fifth Amendment prohibition against takings and double jeopardy despite the fact that the Amendment clearly refers to natural persons; and the Sixth and Seventh Amendment rights to jury trials in criminal and Civil matters respectively" The instances cited are: "The concept of property rights, originally developed to preserve an individual’s right to property is used to grant individual rights to entities that are themselves a form of property. As early as 1818, Congressman Daniel Webster used the idea of property rights to limit a state’s influence over a corporation. These were the earliest advances on the road to granting individual rights to fictional persons. This was when real people were still bought and sold as property with fewer protections than corporations." "Corporations aren’t specifically mentioned in America's 14th Amendment, or anywhere else in the Constitution. U.S. corporations have sought many of the same rights guaranteed to individuals, including the rights to own property, enter into contracts, and to sue and be sued just like individuals." "A 1978 Court decision on the Bellotti case granted corporations the right to spend unlimited funds on ballot initiatives as part of their First Amendment right to freedom of speech; In the 2010 case Citizens United v. Federal Election Commission (FEC), the most sweeping expansion of corporate rights yet, the US Supreme Court cited that political speech by corporations is a form of free speech that is also covered under the First Amendment." Irrespective of how Europe may strengthen the GDPR by way of well considered safeguards against limitations and possible abuses of privacy legislation, the EPDP could work though resistant and misdirectinal arguments on the need to differentiate between natural and legal persons (and go beyond this categorization of differences to further differentiate between domain names for personal and commercial use.	No	Even in simple web spaces, such as that of a non-profit organization with a membership form, such a distinction is easily made by a simple form that leads to a different set of questions if the membership is sought by an organization, and often differential membership fee is applied. While technical implementation in the case where Registrants themselves correctly disclose if the domain name is for personal or commercial use, in situations where a commercial domain name Registrant seeks to classify his commercial domain as a personal domain name, certain automated post-domain-registration checks could flag the domain name automatically. These include metadata scanning for commercial keywords, or automated crawling to look for signs of commercial activity such as the presence of a payment gateway or bank account information.	Intent and wording of this recommendation requires amendment	[Practicable]* timelines criteria for responses to be provided by ICANN .	The timeline criteria provided by contracted parties may differ from one contracted party to another based on each party's data infrastructure and overall organizational factors. Instead the timeline criteria could be provided by ICANN which could act as a single contact point for access requests which it could process in accordance with the policy that it is developing by its multi-stakeholder global process. Even the data access could be granted from ICANN Compliance database / escrow , by privilege levels as determined by the class of requester and the nature of request. Such a process may remarkably reduce the burden on Registries and Registrars and would also considerably ease the processes for the Requester who would otherwise have to request access from multiple Registries and Registrars, each in a different geographic location. If ICANN chooses to make lawful access as a single window process, it could design technical safeguards thoroughly, with more layers of security than any independant Registry or Registrar could afford to, while its legal team may have to designate this activity as a Service qualifying for as much legal immunity as could be built in, for its Board, Senior Staff and also with clauses for all legal costs pre-deflected to Requesters.		Support recommendation as written					No, I wish to continue to the next section
54	12/22/2018 16:07:10	Fabien Betremieux	GAC Advisory Committee (GAC)	Yes	Staff submission for GAC representatives					Support Purpose intent with wording change	The GAC is still considering possible edits to clarify this purpose.	The GAC supports the purpose of ICANN to maintain the security, stability and resiliency of the Domain Name System in accordance with ICANN's mission, but would also reference ICANN’s commitments and core values as set forth in the Bylaws. The GAC recognizes that the EPDP spent considerable time trying to take into account the opinion received from the EDPB on the need for ICANN distinguish between its own processing activities and the purposes pursued by other stakeholders. However, the GAC is still considering the wording of this purpose and how to best emphasize that it focuses on ICANN purposes only. Making such a distinction should not exclude processing for legitimate purposes pursued by other stakeholders; as stated in the GAC's recent comments on the Unified Access Model, "the GAC considers the development and implementation of such a unified and reliable access model to be of the utmost importance" and has called on ICANN and the community "to develop a comprehensive, harmonized, reliable, and scalable model that allows access to non public WHOIS data for authenticated users with a legitimate purpose in a manner that is consistent with the EU’s General Data Protection Regulation (GDPR)." The GAC is still considering possible edits to clarify this purpose. The GAC believes that it would then be useful to consider this item as part of the scope of legal guidance that the EPDP would be seeking.																	The GAC supports the intent of “Purpose O” that is being considered by the EPDP but not part of the initial report at this point: Research and publish reports on threats to the operational stability, reliability, security, global interoperability, resilience, and openness of the DNS	As detailed in the related Data Element Workbook (a working document of the EPDP Team last circulated on 15 November 2018), the legal basis for processing data under this purpose would rely on GDPR Article 6.1(f), “with specific safeguards defined in Article 89”. Research might also be considered as a compatible purpose if the criteria in Article 6(4) GDPR are met and appropriate safeguards, which may include encryption or pseudonymisation, are implemented. Research activities by ICANN might provide trusted and verifiable information to the Internet community regarding the Internet’s system of unique identifiers, helping in that way to preserve and enhance the administration of the DNS system, as well as to ensure its resilience, stability, security and openness. In that regard, the EPDP is recommended to explore how to best accommodate ICANN’s research activities in line with EU GDPR requirements. Further, the GAC believes that Purpose O (or something similar) could and should capture the purpose of ICANN to process information associated with its registration data Accuracy Reporting System.						Support intent of recommendation with edits	The EPDP Team recommends that the policy stresses the importance of maintaining accurate and up-to-date registration information as currently required in the registrar contracts and as a legal obligation under data protection rules. The current standard Registrar Accreditation Agreement requires Registrars to investigate claimed WHOIS inaccuracies and take reasonable steps to correct inaccuracies once it learns of them (3.7.8). The Registrar Agreement also provides that Registrars may suspend or cancel a registrant's domain name registration for willful provision of inaccurate or unreliable information or willful failure to update information provided to Registrar within designated timeframes (3.7.7.2). Those requirements need to be carefully observed.	ICANN’s contract provisions (in particular in the 2013 Registrar Accreditation Agreement, Sections 3.2.2, 3.7.7.2 and 3.7.8) obligate registrars to take steps to respond to and correct reports of inaccurate WHOIS data. Consistent with Article 5.1.d of the GDPR, every reasonable step must be taken to ensure the accuracy of personal data, in this case, including data provided by registrants. Article 5 of the GDPR also extends beyond the right of a data subject, “having regard to the purposes for which [the data] are processed”. Therefore, the GAC believes that Recommendation 3 should more explicitly recognize the importance of ensuring information accuracy consistent with GDPR article 5.1(d). This recognition would underscore the data subjects (registrants) rights to the accuracy of their data while also addressing concerns of those who rely on WHOIS information for legitimate purposes (such as maintaining the security and stability of the DNS). The GAC also believes that ICANN’s ARS is critical to supporting data accuracy and should be recognized in the policy and/or supported in a processing Purpose (see previous comments). That being said, the GAC agrees that the EPDP is not in a position to recommend new requirements on contracted parties associated with data accuracy and that such policy enhancements are to be considered separately.									The GAC is concerned that the EPDP is considering making the collection of this data “optional” for registrars without thoroughly and thoughtfully considering what impact this would have in terms of data transfer, registry practices, as well as impact on the consumer. Regarding the latter, the GAC does not think it is appropriate for registrars to unilaterally decide for registrants that they do not need to identify a technical contact. Registrants may see value in providing a technical contact to resolve issues with their domain in a timely and most direct manner, among other reasons. The provision (and therefore collection) of a technical contact should remain an option for the registrant.																			No	Regarding the redacted City field The City field should not be redacted as an individual cannot be identified nor is identifiable either directly or indirectly from this identifier or with all the identifiers otherwise non-redacted. Regarding the redacted Email field The lack of a consistent approach by all Contracted Parties could create a fragmented system. The GDPR allows for anonymisation techniques to protect personal data. Consistent with its previous views shared with the ICANN Community, as well as its previous Advice to the ICANN Board, the GAC believes that email addresses should be anonymized as the preferred path forward (rather than a web form) as it would prevent identification of the data subject via all likely and reasonable means, while providing a special email per registrant that is unique across all domains and TLDs. This unique but anonymized identifier is needed for investigative and other legitimate uses. This view is consistent with the Opinion of the Art. 29 Working Party which recognized “that anonymisation techniques can provide privacy guarantees” so long as there is sufficient regard given to “to all the means ‘likely reasonably’ to be used for identification (either by the controller or by any third party).” See Art. 29 WG Opinion 05/2014 on Anonymisation Techniques. Regarding the redacted “Tech Fields” The GAC is concerned that the EPDP is considering making the collection of this data “optional” for registrars without thoroughly and thoughtfully considering what impact this would have in terms of data transfer, registry practices, as well as impact on the consumer. Regarding the latter, the GAC does not think it is appropriate for registrars to unilaterally decide for registrants that they do not need to identify a technical contact. Registrants may see value in providing a technical contact to resolve issues with their domain in a timely and most direct manner, among other reasons. The provision (and therefore collection) of a technical contact should remain an option for the registrant.		No	Regarding the undecided redaction or non redaction of the Organization field The Organisation field should not be redacted as this is clearly a field whereby any personal data contained within the entry would fall under that of a legal person as defined within rectial 14A. The Contracted Parties have noted there may be historic data in this field which is not an Organisation name as some registrants may have incorrectly provided information. This could be rectified by a number of means, the first to provide clear advice on what this field is for and the implications of entering data into here. Second, to provide the registrant with the ability to rectify this field if it is not correctly filled out and by confirmation at renewal point. The GAC would like to point out that there are many European countries who publicly publish business details (including organization name) and even a network of these national registers (European Business Registrar). Also the European Directive 2000/31/EC states “Member States shall ensure that the service provider shall render easily, directly and permanently accessible to the recipients of the service and competent authorities, at least the following information: (a) the name of the service provider; (b) the geographic address at which the service provider is established; (c) the details of the service provider, including his electronic mail address, which allow him to be contacted rapidly and communicated with in a direct and effective manner;” Where there are concerns over how to handle this information, we recommend that ICANN contracted parties consider these as potential models to inform the decisions made by the EPDP.			The Organisation field should not be redacted as this is clearly a field whereby any personal data contained within the entry would fall under that of a legal person as defined within rectial 14A. The Contracted Parties have noted there may be historic data in this field which is not an Organisation name as some registrants may have incorrectly provided information. This could be rectified by a number of means, the first to provide clear advice on what this field is for and the implications of entering data into here. Second, to provide the registrant with the ability to rectify this field if it is not correctly filled out and by confirmation at renewal point. The GAC would like to point out that there are many European countries who publicly publish business details (including organization name) and even a network of these national registers (European Business Registrar). Also the European Directive 2000/31/EC states “Member States shall ensure that the service provider shall render easily, directly and permanently accessible to the recipients of the service and competent authorities, at least the following information: (a) the name of the service provider; (b) the geographic address at which the service provider is established; (c) the details of the service provider, including his electronic mail address, which allow him to be contacted rapidly and communicated with in a direct and effective manner;” Where there are concerns over how to handle this information, we recommend that ICANN contracted parties consider these as potential models to inform the decisions made by the EPDP.					The lack of a consistent approach by all Contracted Parties could create a fragmented system. The GDPR allows for anonymisation techniques to protect personal data. Consistent with its previous views shared with the ICANN Community, as well as its previous Advice to the ICANN Board, the GAC believes that email addresses should be anonymized as the preferred path forward (rather than a web form) as it would prevent identification of the data subject via all likely and reasonable means, while providing a special email per registrant that is unique across all domains and TLDs. This unique but anonymized identifier is needed for investigative and other legitimate uses. This view is consistent with the Opinion of the Art. 29 Working Party which recognized “that anonymisation techniques can provide privacy guarantees” so long as there is sufficient regard given to “to all the means ‘likely reasonably’ to be used for identification (either by the controller or by any third party).” See Art. 29 WG Opinion 05/2014 on Anonymisation Techniques.		Support intent of recommendation with edits		The GAC notes that a number of Data protection laws call for retention periods to be only long enough as to carry out the lawful purposes. Within the EPDP process the members have noted the TDRP process requirements for at least the life of the domain plus one year to be able to fulfil its purposes. At least one year would typically be necessary to complete formal MLAT processes to request information from outside the requester’s jurisdiction. ICANN’s compliance team also indicated during the Los Angeles face to face meeting that the life of the domain plus one year would meet most of their investigation timeframes but a few requests would fall outside of this time frame. However, certain requests for information take place after the domain had been shut down. These requests may involve serious crimes or relate to significant cyber security risks and a one year data retention period would likely be insufficient under these circumstances as stated in the GAC Feedback on Proposed Interim Models (28 January 2018).	The GAC requests that the EPDP team consider extending the period of retention of data when in receipt of a legitimate request.				The GAC would recommend that the temporary specification require contracted parties to treat legal and natural persons differently because, the GDPR “does not cover processing of personal data which concerns legal persons.” (Recital 14). Hence, as we recognized in our San Juan Communique advice, the personal information of legal persons should be part of the publicly available WHOIS data. We recommend that contracted parties develop mechanisms that ensure a reliable determination of natural or legal person status for registrants going forward (post- implementation of new contract specifications) and for their legacy registrants and recognize that these procedures will likely require a phased approach that allows more time for contracted parties to deal with their legacy customers. However, we recognize that there are challenges in making this distinction in the context of domain name registrations as well as the potential implementation of any new functionality that would apply to pre-existing registrations. Additionally, other jurisdictions may have other categories of protected groups or other requirements that would need to be factored in. Consequently, we recommend that the EPDP WG: • research how ccTLDs and contracted parties currently distinguish between natural and legal persons; • consider which data fields (if any) need to be added to accomplish this distinction (this could require further liaising with the IETF if data fields in RDAP need to be added or changed); • consider the timeline needed to implement this requirement which could follow a phased approach whereby implementation would start immediately after agreement on a satisfactory manner to distinguish between legal and natural persons for new registrations while existing registrations would be phased in upon renewal, transfer, or by other means; • direct registries, registrars and ICANN to each develop (educational) resources available that help registrants understand the distinction between a domain name that is registered by a natural person vs. legal person / entity. These resources and communications should highlight that the name and contact information of legal persons will be disclosed in the public WHOIS and therefore encourage legal persons to provide non-personal information for their email address and other contact information. The GAC would also like to point to, as noted previously, the existence of online/public European Business Registers as a potential model to emulate in terms of addressing the challenges associated with differentiating between legal and natural persons. In light of the above, the GAC proposes that the EPDP consider the following as a new recommendation: Recommendation x: A mechanism be developed within RDAP to differentiate between natural and legal persons. This differentiation is to be implemented within the rollout of RDAP along with a procedure to allow for a phased approach to update legacy registration information.				Intent and wording of this recommendation requires amendment	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 and incorporated as part of the implementation of these policy recommendations addressing: • [Practicable]* timelines for responses to disclosure requests be provided by Contracted Parties; • Published format by which requests should be made and responses are provided; • Communication/Published instructions around how and where requests should be submitted; • Requirements for what information responses should include (for example, auto-acknowledgement of requests and rationale for rejection of request); • Logging of requests with appropriate safeguards to ensure non-disclosure of legitimate law enforcement activities	As we advised in our Barcelona Communiqué advice (25 October 2018), the current Temporary Specification has created a fragmented system for providing access consisting of potentially thousands of distinct policies and practices depending upon the registrar involved. This lack of consistent policies and practices to access non-public information causes delays. When investigations are delayed or stopped, the potentially injurious conduct continues to harm the public with negative results that include physical and financial harm. The current requirements for and lack of criteria defining reasonable access" in the Temporary Specification cannot remain and should be replaced with policy that provides timely and predictable access to redacted WHOIS information in a manner that complies with the applicable data protection laws whilst allowing community work on developing a unified access model to proceed in parallel and complementing the EPDP’s efforts.	While the EPDP team’s recommendation identifies a number of criteria that work to better define “reasonable access” to non-public information, the GAC believes that work on a unified access model needs to also proceed as soon as possible and in parallel with the EPDP efforts.
55																																																																			Email should not be redacted
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103