Are you providing input on behalf of another group (e.g., organization, company, government)?

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 Recommendation #20:

If your response requires an edit or deletion of Recommendation #20, please indicate the revised wording and rationale here.

Choose your level of support of the preliminary conclusion for Legal vs. Natural Persons.

If your response requires an edit or deletion of the preliminary conclusion for legal vs. natural persons, please indicate the revised wording and rationale here.

Choose your level of the preliminary conclusion for city field redaction:

If your response requires an edit or deletion of the preliminary conclusion for city field redaction, please indicate the revised wording here.

Choose your level of support of Recommendation #21:

If your response requires an edit or deletion of Recommendation #21, please indicate the revised wording and rationale here.

Choose your level of support of the preliminary conclusion of the OCTO Purpose:

If your response requires an edit or deletion of the preliminary conclusion of the OCTO Purpose, please indicate the revised wording and rationale here.

Choose your level of support of the preliminary conclusion on the feasibility of unique contacts to have a uniform anonymized email address:

If your response requires an edit or deletion of the feasibility of unique contacts to have a uniform anonymized email address, please indicate the revised wording and rationale here.

Choose your level of support of the preliminary conclusion for accuracy and WHOIS accuracy reporting:

If your response requires an edit or deletion of the preliminary conclusion for accuracy and WHOIS accuracy reporting, please indicate the revised wording and rationale here.

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 #22:

Do you recommend a change to the wording of Recommendation 22? If so, please indicate proposed edits and rationale here.

Choose your level of support of Recommendation #9:

Do you recommend a change to Recommendation 9? If so, please indicate proposed edits and rationale here.

If you do not agree with the proposed SLA matrix and/or accompanying description, please provide your rationale and proposed alternative language.

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 #10:

If your response requires an edit or deletion of Recommendation #10, please indicate the revised wording and rationale here.

Choose your level of support of Recommendation #11:

If your response requires an edit or deletion of Recommendation #11, please indicate the revised wording and rationale here.

Choose your level of support of Recommendation #12:

If your response requires an edit or deletion of Recommendation #12, please indicate the revised wording and rationale here.

Choose your level of support of Recommendation #13:

If you believe edits are needed for Recommendation #13, please propose edits and rationale here.

Choose your level of support of Recommendation #14:

If you do not support Recommendation #14, please provide proposed edits and rationale here.

Choose your level of support of Recommendation #15:

If you believe edits are needed for Recommendation #15, please propose edits and rationale here.

Choose your level of support of Recommendation #16:

If you believe changes are needed for Recommendation #16, please provide proposed edits and rationale here.

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 #17:

Choose your level of support of Recommendation #18:

If you do not support Recommendation #18, please provide proposed edits/changes and rationale here.

Choose your level of support of Recommendation #19:

If you do not support Recommendation #19, please provide proposed edits or changes and rationale here.

What existing processes / procedures, if any, can be used to meet the above responsibilities?

If no suitable existing processes / procedures can be used, what type of mechanism should be created factoring in: Who should guidance be provided to? How is guidance developed / agreed to? How should it be structured?

What information is needed to ensure the continuous evolution of SSAD?

How is guidance of the Mechanism expected to be implemented?

Choose your level of support of Implementation Guidance #i:

If you do not support Implementation Guidance #i, please provide proposed edits or changes and rationale here.

What type of reporting should be required as part of SSAD?

Are there any recommendations the EPDP Team has not considered? If yes, please provide details below.

Are there any other comments or issues you would like to raise pertaining to the Addendum to the Initial Report? If yes, please enter your comments here. If applicable, please specify the section or page number in the Initial Report to which your comments refer.

Recommendation should be deleted

Most of this Recommendation (Parts 1, 2 and 3) merely repeats what other parts of the initial report say, notably Recommendation 6. The parts that are not repetitive are poorly thought out or objectionable.
The part of the recommendation that says "a Contracted Party MAY request the Central Gateway to fully automate all, or certain types of, disclosure requests" is not consistent with the requirement that automated disclosure must be legally permissible. A contracted party could request automation when it is not legally permissible, and this recommendation does not provide any checks on that. It encourages contracted parties to save time and money by sacrificing the data protection rights of their customers.
The part that suggests that law enforcement agencies should be able to automate ALL requests is neither justified nor legally permissible. It is routinely true that LEAs must get warrants or subpoenas to disclose private information; the mere fact that they are LEAs does not relieve them of basic privacy protections.
Automated disclosures raise important legal questions, which this Recommendation does not resolve. Automation of disclosure poses a real danger that all of the legal rights for data subjects could be bypassed by a system that essentially recreates the open-access Whois for any accredited user.

No, I wish to continue to the next section

Support recommendation as written

Support recommendation as written

Recommendation should be deleted

There is no justification in allowing requests to be submitted in an automatic way. Such a possibility would be an open door to system abuses.

No, I wish to continue to the next section

Support recommendation as written

Support recommendation as written

No, I would like to continue to the next section

Recommendation should be deleted

Conclusion should be deleted

Conclusion should be deleted

Recommendation should be deleted

Conclusion should be deleted

Recommendation should be deleted

Conclusion should be deleted

No, I wish to continue to the next section

No, I wish to continue to the next section

No, I would like to continue to the next section

Significant change required: changing intent and wording

We do not support this conclusion regarding accuracy and WHOIS accuracy reporting system. In fact, the EPDP Team should consider this topic as a number 1 priority, in close collaboration with the expected scoping team of the GNSO Council. Every actor in this process should seriously consider accuracy questions, as it is states in Article 5 of the GDPR: “Every reasonable step must be taken to ensure the accuracy of the data in view of the purposes for which it is processed.” Neither the GDPR nor any other law will ever protect fake data! Since we know from experience that WHOIS data is often inexact, the EPDP Team must put all its efforts in finding solutions to this complex issue.

No, I wish to continue to the next section

Support recommendation as written

No, I wish to continue to the next section

No, I would like to continue to the next section

Support Recommendation intent with wording change

In the case of a domain name registration where an accredited privacy/proxy service is used, e.g., where data associated with a natural person is masked, Registrar (and Registry, where applicable) MUST include the full RDDS data of the accredited privacy/proxy service in response to an RDDS query. The full privacy/proxy RDDS data may include a pseudonymized email. Work to implement the PPSAI policy must be restarted without delay.

Support Conclusion intent with wording change

The GDPR does not apply to the data of legal persons, so there is no justification for such data not to be displayed. Given the urgency, it is vital that this is taken forward as soon as possible so a commitment merely to “consult” Council with no concrete action steps or timeline is insufficient.

Proposed wording change:
As a result, the EPDP Team will consult with the GNSO Council at the latest by end May 2020 on potential next steps including obtaining expeditious legal advice on the differentiation of treatment of legal and natural persons under the GDPR and a request to the EDPB on what, if any, limits need to be placed on the display of legal persons’ data in this context.

Support Conclusion intent with wording change

We completely disagree with thus conclusion. There is no valid reason for the city field to be deleted.

Significant change required: changing intent and wording

We fundamentally disagree with this. While noting that the majority of the Council did choose to side-line the question of data accuracy, this ignores the requirements of the GDPR itself and the European Commission’s GAC representative to the EPDP, both of which are clear that data accuracy is essential. To expend so many resources on the elucidation of a system for the processing of and access to inaccurate data is simply unconscionable. Further, absent any timelines or sense of urgency, we foresee this vital issue being furloughed by Council. We need: rapid action; the establishment of a small group as soon as possible within the EPDP itself so as to ensure continuation of the relevant experts; and tight deadlines for concrete action.

Suggested wording change:

Per the instructions from the majority opinion of the GNSO Council, the EPDP Team will not consider this topic further; instead, the GNSO Council is expected to will form a scoping team within the EPDP to further explore the issues in relation to accuracy and ARS before the end of May 2020. This team will to help inform a decision on appropriate next steps to address potential issues identified and issue its preliminary guidance at the latest on 1st July 2020.

No, I wish to continue to the next section

Support recommendation as written

No, I wish to continue to the next section

No, I would like to continue to the next section

Support Conclusion intent with wording change

As GDPR does not apply to the data of legal persons, there should be no question nor divergence on this point. Indeed, we believe that if legal person data cannot remain accessible in real time without redaction, its disclosure should at least be done automatically upon request. Allowing users to know who they are doing business with is as important online as it is offline, and the current over-application of the GDPR has allowed bad actors to proliferate online at the expense of all consumers.

In any case, it is of primary importance that the EPDP team put in their best efforts to find an expeditious solution to this impasse. We urge the team to consult as many stakeholders as possible, beyond the GNSO Council, in order to discuss this question and find solutions that could overpass the blockages and discrepancies regarding distinction between legal and natural persons. In fact, it is of high importance to find a common answer to this element as if there is a difference of treatment between Legal and Natural persons, infringers will always choose the most convenient option and declare that they are natural persons to benefit from anonymity and continue their illegal activities. We are fighting for Transparency and Trust, and this debate around legal and natural persons shouldn’t throw a spanner in the work, especially regarding the fact that GDPR does not apply to the data of legal persons.

We suggest the following wording, which seems to be more appropriate to highlight the very important nature of this distinction between legal vs. natural persons: “The EPDP Team will consult with the GNSO Council on potential next steps at the earliest opportunity, including analysing legal advice on the differentiation of treatment of legal and natural persons under the GDPR and a request to the EDPB on what, if any, limits need to be placed on the display of legal persons’ data in this context.”

Significant change required: changing intent and wording

Referring back to the conclusions of EPDP Phase 1 Initial report, and regarding the request of external legal counsel guidance in relation to the topic of city field (on whether this topic is considered personal data): “The legal analysis is clear – this is personal data; in principle publication could be justified on the basis of rights-holders legitimate interests, unless the interests of individuals override this.” On top of that, the EPDP Team concluded that it is not able to provide a rationale that would justify universal publication of the city field.

Nevertheless, we ask the EPDP Team to take into account the necessity of transparency and trust in this whole process. As a conclusion, there is also no valid reason for this particular data to be redacted in comparison with other personal data such as “State/Province” or “Country”.

In consequence, we suggest the following wording: “Changes to the EPDP Phase 1 recommendation must be considered in order to delete the “redaction” character of city field. It is a matter of Transparency and Trust.”

Support Conclusion as written

Considering the following: “The mission of the OCTO is to constantly improve knowledge about the identifiers ICANN helps coordinate; to disseminate this information to the Internet community; to improve the technical operation of the Internet's system of unique identifiers; and to improve ICANN's technological stature.”; and taking into account EPDP Team’s analysis, we see no arguments to oppose this preliminary conclusion. On top of that, we think that the evolving nature of this recommendation allows flexibility to be maintained if further modifications are necessary.

Significant change required: changing intent and wording

While the legal guidance notes that publication of uniform masked email addresses would still result in the publication of personal data, the GDPR states that “it is up to every organization to develop a rationale for developing the most appropriate data security practices”. Taking both elements into consideration, the use of masked email addresses seems to oppose the objectives of the GDPR.

That is why we ask the EPDP Team to propose diverse options that could substitute today’s process, by taking into account the condition of protection of personal data. The proposed options should be open to discussion, especially regarding their potential implementation and feasibility issues.

Significant change required: changing intent and wording

We do not support this conclusion regarding accuracy and WHOIS accuracy reporting system. In fact, the EPDP Team should consider this topic as a number 1 priority, in close collaboration with the expected scoping team of the GNSO Council. Every actor in this process should seriously consider accuracy questions, as it is states in Article 5 of the GDPR: “Every reasonable step must be taken to ensure the accuracy of the data in view of the purposes for which it is processed.” Neither the GDPR nor any other law will ever protect fake data! Since we know from experience that WHOIS data is often inexact, the EPDP Team must put all its efforts in finding solutions to this complex issue.

That is why we suggest the following wording:
“Per the instructions from the majority opinion of the GNSO Council, the EPDP Team will not consider this topic further; instead, the GNSO Council is expected to form a scoping team within the EPDP to further explore the issues in relation to accuracy and ARS before the end of May 2020. This team will help to inform a decision on appropriate next steps in order to address potential issues identified and draft its preliminary guidance at the latest on 1st July 2020.”

No, I wish to continue to the next section

Support recommendation as written

No, I wish to continue to the next section

No, I would like to continue to the next section

Support Recommendation intent with wording change

In the case of a domain name registration where an accredited privacy/proxy service is used, e.g., where data associated with a natural person is masked, Registrar (and Registry, where applicable) MUST include the full RDDS data of the accredited privacy/proxy service in response to an RDDS query. The full privacy/proxy RDDS data may include a pseudonymized email. Add: ICANN Org must restart the IRT to implement the PPSAI work without delay.

Support Conclusion intent with wording change

The GDPR does not apply to the data of legal persons, so there is no justification for such data not to be disclosed. Given the urgency, it is vital that this is taken forward as soon as possible so a commitment merely to “consult” Council with no concrete action steps or timeline is insufficient.

Proposed wording change:
As a result, the EPDP Team will consult with the GNSO Council at the latest by end May 2020 on potential next steps including obtaining expeditious legal advice on the differentiation of treatment of legal and natural persons under the GDPR and a request to the EDPB on what, if any, limits need to be placed on the display of legal persons’ data in this context. A legitimate request for disclosure of a legal person’s data must be granted.

Significant change required: changing intent and wording

We completely disagree with this conclusion. There is no valid reason for the city field to be deleted. At a minimum, legitimate requests to disclose only the city field for the purpose of establishing jurisdiction for legal proceedings should be granted.

Support Recommendation intent with wording change

The period of data retention should be two years to ensure that full investigations can be completed.

Recommendation should be deleted

As an anonymised address would allow the registrant to be contacted without the disclosure of personal data, we do not understand this conclusion.

Significant change required: changing intent and wording

We fundamentally disagree with this. While noting that the majority of the Council did choose to side-line the question of data accuracy, this ignores the requirements of the GDPR itself and the opinion of the European Commission’s GAC representative to the EPDP, both of which are clear that data accuracy is essential. To expend so many resources on the elucidation of a system for the processing of and access to inaccurate data is simply unconscionable. The compromise agreement in Phase 1 was that data accuracy would be dealt with in Phase 2. Further, absent any timelines or sense of urgency, we foresee this vital issue being furloughed by Council. We need the establishment of a small group as soon as possible of EPDP experts so as to ensure continuation and tight deadlines for concrete action.

Suggested wording change:

Per the majority opinion of the GNSO Council, the EPDP Team will not consider this topic further; instead, the GNSO Council will form a scoping team drawn from the EPDP members to further explore the issues in relation to accuracy and ARS before the end of May 2020. This team will help inform a decision on appropriate next steps to address potential issues identified and issue its preliminary guidance at the latest on 1 July 2020.

No, I wish to continue to the next section

Support recommendation as written

No, I wish to continue to the next section

No, I would like to continue to the next section

Support Conclusion intent with wording change

As GDPR does not apply to the data of legal persons, there should be no question nor divergence on this point. Indeed, we believe that if legal person data cannot remain accessible in real time without redaction, its disclosure should at least be done automatically upon request. Allowing users to know who they are doing business with is as important online as it is offline, and the current over-application of the GDPR has allowed bad actors to proliferate online at the expense of all consumers.

In any case, it is of primary importance that the EPDP team put in their best efforts to find an expeditious solution to this impasse. We urge the team to consult as many stakeholders as possible, beyond the GNSO Council, in order to discuss this question and find solutions that could overpass the blockages and discrepancies regarding distinction between legal and natural persons. In fact, it is of high importance to find a common answer to this element as if there is a difference of treatment between Legal and Natural persons, infringers will always choose the most convenient option and declare that they are natural persons to benefit from anonymity and continue their illegal activities. We are fighting for Transparency and Trust, and this debate around legal and natural persons shouldn’t throw a spanner in the work, especially regarding the fact that GDPR does not apply to the data of legal persons.

We suggest the following wording, which seems to be more appropriate to highlight the very important nature of this distinction between legal vs. natural persons: “The EPDP Team will consult with the GNSO Council on potential next steps at the earliest opportunity, including analysing legal advice on the differentiation of treatment of legal and natural persons under the GDPR and a request to the EDPB on what, if any, limits need to be placed on the display of legal persons’ data in this context.”

Significant change required: changing intent and wording

Referring back to the conclusions of EPDP Phase 1 Initial report, and regarding the request of external legal counsel guidance in relation to the topic of city field (on whether this topic is considered personal data): “The legal analysis is clear – this is personal data; in principle publication could be justified on the basis of rights-holders legitimate interests, unless the interests of individuals override this.” On top of that, the EPDP Team concluded that it is not able to provide a rationale that would justify universal publication of the city field.

Nevertheless, we ask the EPDP Team to take into account the necessity of transparency and trust in this whole process. As a conclusion, there is also no valid reason for this particular data to be redacted in comparison with other personal data such as “State/Province” or “Country”.

In consequence, we suggest the following wording: “Changes to the EPDP Phase 1 recommendation must be considered in order to delete the “redaction” character of city field. It is a matter of Transparency and Trust.”

Support Conclusion as written

Considering the following: “The mission of the OCTO is to constantly improve knowledge about the identifiers ICANN helps coordinate; to disseminate this information to the Internet community; to improve the technical operation of the Internet's system of unique identifiers; and to improve ICANN's technological stature.”; and taking into account EPDP Team’s analysis, we see no arguments to oppose this preliminary conclusion. On top of that, we think that the evolving nature of this recommendation allows flexibility to be maintained if further modifications are necessary.

Significant change required: changing intent and wording

While the legal guidance notes that publication of uniform masked email addresses would still result in the publication of personal data, the GDPR states that “it is up to every organization to develop a rationale for developing the most appropriate data security practices”. Taking both elements into consideration, the use of masked email addresses seems to oppose the objectives of the GDPR.

That is why we ask the EPDP Team to propose diverse options that could substitute today’s process, by taking into account the condition of protection of personal data. The proposed options should be open to discussion, especially regarding their potential implementation and feasibility issues.

Significant change required: changing intent and wording

We do not support this conclusion regarding accuracy and WHOIS accuracy reporting system. In fact, the EPDP Team should consider this topic as a number 1 priority, in close collaboration with the expected scoping team of the GNSO Council. Every actor in this process should seriously consider accuracy questions, as it is states in Article 5 of the GDPR: “Every reasonable step must be taken to ensure the accuracy of the data in view of the purposes for which it is processed.” Neither the GDPR nor any other law will ever protect fake data! Since we know from experience that WHOIS data is often inexact, the EPDP Team must put all its efforts in finding solutions to this complex issue.

That is why we suggest the following wording:
“Per the instructions from the majority opinion of the GNSO Council, the EPDP Team will not consider this topic further; instead, the GNSO Council is expected to form a scoping team within the EPDP to further explore the issues in relation to accuracy and ARS before the end of May 2020. This team will help to inform a decision on appropriate next steps in order to address potential issues identified and draft its preliminary guidance at the latest on 1st July 2020.”

No, I wish to continue to the next section

Support recommendation as written

No, I wish to continue to the next section

No, I would like to continue to the next section

Support Conclusion intent with wording change

As GDPR does not apply to the data of legal persons, there should be no question nor divergence on this point. Indeed, we believe that if legal person data cannot remain accessible in real time without redaction, its disclosure should at least be done automatically upon request. Allowing users to know who they are doing business with is as important online as it is offline, and the current over-application of the GDPR has allowed bad actors to proliferate online at the expense of all consumers.

In any case, it is of primary importance that the EPDP team put in their best efforts to find an expeditious solution to this impasse. We urge the team to consult as many stakeholders as possible, beyond the GNSO Council, in order to discuss this question and find solutions that could overpass the blockages and discrepancies regarding distinction between legal and natural persons. In fact, it is of high importance to find a common answer to this element as if there is a difference of treatment between Legal and Natural persons, infringers will always choose the most convenient option and declare that they are natural persons to benefit from anonymity and continue their illegal activities. We are fighting for Transparency and Trust, and this debate around legal and natural persons shouldn’t throw a spanner in the work, especially regarding the fact that GDPR does not apply to the data of legal persons.

We suggest the following wording, which seems to be more appropriate to highlight the very important nature of this distinction between legal vs. natural persons: “The EPDP Team will consult with the GNSO Council on potential next steps at the earliest opportunity, including analysing legal advice on the differentiation of treatment of legal and natural persons under the GDPR and a request to the EDPB on what, if any, limits need to be placed on the display of legal persons’ data in this context.”

Significant change required: changing intent and wording

Referring back to the conclusions of EPDP Phase 1 Initial report, and regarding the request of external legal counsel guidance in relation to the topic of city field (on whether this topic is considered personal data): “The legal analysis is clear – this is personal data; in principle publication could be justified on the basis of rights-holders legitimate interests, unless the interests of individuals override this.” On top of that, the EPDP Team concluded that it is not able to provide a rationale that would justify universal publication of the city field.

Nevertheless, we ask the EPDP Team to take into account the necessity of transparency and trust in this whole process. As a conclusion, there is also no valid reason for this particular data to be redacted in comparison with other personal data such as “State/Province” or “Country”.

In consequence, we suggest the following wording: “Changes to the EPDP Phase 1 recommendation must be considered in order to delete the “redaction” character of city field. It is a matter of Transparency and Trust.”

Support Conclusion as written

Considering the following: “The mission of the OCTO is to constantly improve knowledge about the identifiers ICANN helps coordinate; to disseminate this information to the Internet community; to improve the technical operation of the Internet's system of unique identifiers; and to improve ICANN's technological stature.”; and taking into account EPDP Team’s analysis, we see no arguments to oppose this preliminary conclusion. On top of that, we think that the evolving nature of this recommendation allows flexibility to be maintained if further modifications are necessary.

Significant change required: changing intent and wording

While the legal guidance notes that publication of uniform masked email addresses would still result in the publication of personal data, the GDPR states that “it is up to every organization to develop a rationale for developing the most appropriate data security practices”. Taking both elements into consideration, the use of masked email addresses seems to oppose the objectives of the GDPR.

That is why we ask the EPDP Team to propose diverse options that could substitute today’s process, by taking into account the condition of protection of personal data. The proposed options should be open to discussion, especially regarding their potential implementation and feasibility issues.

Significant change required: changing intent and wording

We do not support this conclusion regarding accuracy and WHOIS accuracy reporting system. In fact, the EPDP Team should consider this topic as a number 1 priority, in close collaboration with the expected scoping team of the GNSO Council. Every actor in this process should seriously consider accuracy questions, as it is states in Article 5 of the GDPR: “Every reasonable step must be taken to ensure the accuracy of the data in view of the purposes for which it is processed.” Neither the GDPR nor any other law will ever protect fake data! Since we know from experience that WHOIS data is often inexact, the EPDP Team must put all its efforts in finding solutions to this complex issue.

That is why we suggest the following wording:
“Per the instructions from the majority opinion of the GNSO Council, the EPDP Team will not consider this topic further; instead, the GNSO Council is expected to form a scoping team within the EPDP to further explore the issues in relation to accuracy and ARS before the end of May 2020. This team will help to inform a decision on appropriate next steps in order to address potential issues identified and draft its preliminary guidance at the latest on 1st July 2020.”

No, I wish to continue to the next section

Support recommendation as written

No, I wish to continue to the next section

UNIFAB - Union des Fabricants

No, I would like to continue to the next section

Support Conclusion intent with wording change

As GDPR does not apply to the data of legal persons, there should be no question nor divergence on this point. Indeed, we believe that if legal person data cannot remain accessible in real time without redaction, its disclosure should at least be done automatically upon request. Allowing users to know who they are doing business with is as important online as it is offline, and the current over-application of the GDPR has allowed bad actors to proliferate online at the expense of all consumers.

In any case, it is of primary importance that the EPDP team put in their best efforts to find an expeditious solution to this impasse. We urge the team to consult as many stakeholders as possible, beyond the GNSO Council, in order to discuss this question and find solutions that could overpass the blockages and discrepancies regarding distinction between legal and natural persons. In fact, it is of high importance to find a common answer to this element as if there is a difference of treatment between Legal and Natural persons, infringers will always choose the most convenient option and declare that they are natural persons to benefit from anonymity and continue their illegal activities. We are fighting for Transparency and Trust, and this debate around legal and natural persons shouldn’t throw a spanner in the work, especially regarding the fact that GDPR does not apply to the data of legal persons.

We suggest the following wording, which seems to be more appropriate to highlight the very important nature of this distinction between legal vs. natural persons: “The EPDP Team will consult with the GNSO Council on potential next steps at the earliest opportunity, including analysing legal advice on the differentiation of treatment of legal and natural persons under the GDPR and a request to the EDPB on what, if any, limits need to be placed on the display of legal persons’ data in this context.”

Significant change required: changing intent and wording

Referring back to the conclusions of EPDP Phase 1 Initial report, and regarding the request of external legal counsel guidance in relation to the topic of city field (on whether this topic is considered personal data): “The legal analysis is clear – this is personal data; in principle publication could be justified on the basis of rights-holders legitimate interests, unless the interests of individuals override this.” On top of that, the EPDP Team concluded that it is not able to provide a rationale that would justify universal publication of the city field.

Nevertheless, we ask the EPDP Team to take into account the necessity of transparency and trust in this whole process. As a conclusion, there is also no valid reason for this particular data to be redacted in comparison with other personal data such as “State/Province” or “Country”.

In consequence, we suggest the following wording: “Changes to the EPDP Phase 1 recommendation must be considered in order to delete the “redaction” character of city field. It is a matter of Transparency and Trust.”

Support Conclusion as written

Considering the following: “The mission of the OCTO is to constantly improve knowledge about the identifiers ICANN helps coordinate; to disseminate this information to the Internet community; to improve the technical operation of the Internet's system of unique identifiers; and to improve ICANN's technological stature.”; and taking into account EPDP Team’s analysis, we see no arguments to oppose this preliminary conclusion. On top of that, we think that the evolving nature of this recommendation allows flexibility to be maintained if further modifications are necessary.

Significant change required: changing intent and wording

While the legal guidance notes that publication of uniform masked email addresses would still result in the publication of personal data, the GDPR states that “it is up to every organization to develop a rationale for developing the most appropriate data security practices”. Taking both elements into consideration, the use of masked email addresses seems to oppose the objectives of the GDPR.

That is why we ask the EPDP Team to propose diverse options that could substitute today’s process, by taking into account the condition of protection of personal data. The proposed options should be open to discussion, especially regarding their potential implementation and feasibility issues.

Significant change required: changing intent and wording

We do not support this conclusion regarding accuracy and WHOIS accuracy reporting system. In fact, the EPDP Team should consider this topic as a number 1 priority, in close collaboration with the expected scoping team of the GNSO Council. Every actor in this process should seriously consider accuracy questions, as it is states in Article 5 of the GDPR: “Every reasonable step must be taken to ensure the accuracy of the data in view of the purposes for which it is processed.” Neither the GDPR nor any other law will ever protect fake data! Since we know from experience that WHOIS data is often inexact, the EPDP Team must put all its efforts in finding solutions to this complex issue.

That is why we suggest the following wording:
“Per the instructions from the majority opinion of the GNSO Council, the EPDP Team will not consider this topic further; instead, the GNSO Council is expected to form a scoping team within the EPDP to further explore the issues in relation to accuracy and ARS before the end of May 2020. This team will help to inform a decision on appropriate next steps in order to address potential issues identified and draft its preliminary guidance at the latest on 1st July 2020.”

No, I wish to continue to the next section

Support recommendation as written

No, I wish to continue to the next section

No, I would like to continue to the next section

Support Conclusion intent with wording change

As GDPR does not apply to the data of legal persons, there should be no question nor divergence on this point. Indeed, we believe that if legal person data cannot remain accessible in real time without redaction, its disclosure should at least be done automatically upon request. Allowing users to know who they are doing business with is as important online as it is offline, and the current over-application of the GDPR has allowed bad actors to proliferate online at the expense of all consumers.

In any case, it is of primary importance that the EPDP team put in their best efforts to find an expeditious solution to this impasse. We urge the team to consult as many stakeholders as possible, beyond the GNSO Council, in order to discuss this question and find solutions that could overpass the blockages and discrepancies regarding distinction between legal and natural persons. In fact, it is of high importance to find a common answer to this element as if there is a difference of treatment between Legal and Natural persons, infringers will always choose the most convenient option and declare that they are natural persons to benefit from anonymity and continue their illegal activities. We are fighting for Transparency and Trust, and this debate around legal and natural persons shouldn’t throw a spanner in the work, especially regarding the fact that GDPR does not apply to the data of legal persons.

We suggest the following wording, which seems to be more appropriate to highlight the very important nature of this distinction between legal vs. natural persons: “The EPDP Team will consult with the GNSO Council on potential next steps at the earliest opportunity, including analysing legal advice on the differentiation of treatment of legal and natural persons under the GDPR and a request to the EDPB on what, if any, limits need to be placed on the display of legal persons’ data in this context.”

Significant change required: changing intent and wording

Referring back to the conclusions of EPDP Phase 1 Initial report, and regarding the request of external legal counsel guidance in relation to the topic of city field (on whether this topic is considered personal data): “The legal analysis is clear – this is personal data; in principle publication could be justified on the basis of rights-holders legitimate interests, unless the interests of individuals override this.” On top of that, the EPDP Team concluded that it is not able to provide a rationale that would justify universal publication of the city field.

Nevertheless, we ask the EPDP Team to take into account the necessity of transparency and trust in this whole process. As a conclusion, there is also no valid reason for this particular data to be redacted in comparison with other personal data such as “State/Province” or “Country”.

In consequence, we suggest the following wording: “Changes to the EPDP Phase 1 recommendation must be considered in order to delete the “redaction” character of city field. It is a matter of Transparency and Trust.”

Support Conclusion as written

Considering the following: “The mission of the OCTO is to constantly improve knowledge about the identifiers ICANN helps coordinate; to disseminate this information to the Internet community; to improve the technical operation of the Internet's system of unique identifiers; and to improve ICANN's technological stature.”; and taking into account EPDP Team’s analysis, we see no arguments to oppose this preliminary conclusion. On top of that, we think that the evolving nature of this recommendation allows flexibility to be maintained if further modifications are necessary

Significant change required: changing intent and wording

While the legal guidance notes that publication of uniform masked email addresses would still result in the publication of personal data, the GDPR states that “it is up to every organization to develop a rationale for developing the most appropriate data security practices”. Taking both elements into consideration, the use of masked email addresses seems to oppose the objectives of the GDPR.

That is why we ask the EPDP Team to propose diverse options that could substitute today’s process, by taking into account the condition of protection of personal data. The proposed options should be open to discussion, especially regarding their potential implementation and feasibility issues.

Significant change required: changing intent and wording

We do not support this conclusion regarding accuracy and WHOIS accuracy reporting system. In fact, the EPDP Team should consider this topic as a number 1 priority, in close collaboration with the expected scoping team of the GNSO Council. Every actor in this process should seriously consider accuracy questions, as it is states in Article 5 of the GDPR: “Every reasonable step must be taken to ensure the accuracy of the data in view of the purposes for which it is processed.” Neither the GDPR nor any other law will ever protect fake data! Since we know from experience that WHOIS data is often inexact, the EPDP Team must put all its efforts in finding solutions to this complex issue.

That is why we suggest the following wording:
“Per the instructions from the majority opinion of the GNSO Council, the EPDP Team will not consider this topic further; instead, the GNSO Council is expected to form a scoping team within the EPDP to further explore the issues in relation to accuracy and ARS before the end of May 2020. This team will help to inform a decision on appropriate next steps in order to address potential issues identified and draft its preliminary guidance at the latest on 1st July 2020.”

No, I wish to continue to the next section

Support recommendation as written

No, I wish to continue to the next section

No, I would like to continue to the next section

Significant change required: changing intent and wording

We would like to share our concern with the approach proposing not to distinguish between registrations of legal and natural persons. As many commentators have already pointed out, we believe that this is an over-application of the GDPR.

Despite the fact that GDPR does not protect data pertaining to legal persons, we would like to remind ICANN that in its letter dated 11 December 2017, WP29 states the following:

"WP29 wishes to stress that the unlimited publication of personal data of individual domain name holders raises serious concerns regarding the lawfulness of such practice under the current European Data Protection directive (95/46/EC), especially regarding the necessity to have a legitimate purpose and a legal ground for such processing".

It appears very clearly that only personal data of individual domain name holders are requested to be protected and undisclosed in the WHOIS.

Not distinguishing between legal and natural person is a misinterpretation of European DPA’s explicit recommendations on the new legal framework.

Afnic as .fr registry operator (ccTLD) has implemented this distinction since 2005 without any operational nor legal issue.

Support Conclusion as written

No, I wish to continue to the next section

No, I wish to continue to the next section

MARQUES EUROPEAN ASSOCIATION OF TRADE MARK OWNERS

No, I would like to continue to the next section

Support Recommendation intent with wording change

In the case of a domain name registration where an accredited privacy/proxy service is used, e.g., where data associated with a natural person is masked, Registrar (and Registry, where applicable) MUST include the full RDDS data of the accredited privacy/proxy service in response to an RDDS query. The full privacy/proxy RDDS data may include a pseudonymized email. The full privacy/proxy RDDS data MUST include either a pseudonymized or anonymized privacy/proxy account ID.

Rationale: The last sentence should be added to enable the correlation of other domain names registered by the same privacy/proxy service customer through the privacy/proxy account provider based on an account ID without compromising the privacy of the customer.

Significant change required: changing intent and wording

Registries and registrars SHOULD distinguish between legal and natural persons in the publication of RDDS data. Where a registry or registrar knows that RDDS data is that of a legal person, and it is not published by the registry or registrar, it MUST be available through the SSAD as an automated use case from Day 1. Registries may prohibit within their registration policies the use of any personal data as RDDS data and require that registrants submit only data belonging to legal persons.

Implementation guidance: registrars MUST provide high-level guidance to potential registrants on the difference between a legal and natural person, and how legal persons can avoid providing personal data. Registrars must pass through to registrants any registry-level prohibitions on the use of personal data as RDDS data.

MARQUES proposes this language in line with the legal advice provided by Bird & Bird to the EPDP as part of their Phase 1 work. MARQUES also refers to the Court of Justice case 9 March 2017, Manni, C-398/15 and communication between the EPDB and ICANN on 5 July 2018.

Further comment: MARQUES understands that ICANN is still collating and reviewing the results of their questionnaire on legal vs natural persons, that the Addendum notes that the results are expected to be available to the EPDP Team in May, and that the EPDP has limited time to complete its work. If the EPDP Team is unable to reach resolution on this issue, MARQUES asks that the EPDP Team attempts to provide input on the results of the questionnaire to give the GNSO Council as much information as possible when deciding on next steps. At a minimum, the EPDP should recommend a clear path forward for addressing the legal vs natural issues as soon as possible.

Support Conclusion intent with wording change

Registries and Registrars MAY redact the city field in RDDS.

Rationale: MARQUES notes that the practice of redacting the city field varies across European ccTLDs. Further the legal advice provided to the EPDP Team by Bird & Bird sets out that the city field will not always be personal data. Based on this, MARQUES supports registries and registrars having the flexibility to decide whether to redact or publish the City Field in RDDS.

MARQUES also notes that the EPDP Team has considered an automation use case for just the City Field where it is not redacted, and encourages the EPDP Team to adopt this as a use case from Day 1.

Support Recommendation as written

Support Conclusion as written

Significant change required: changing intent and wording

The EPDP Team received legal guidance noting that the publication of uniform masked email addresses results in the publication of personal data; therefore, wide publication of uniform masked email addresses is not currently feasible under the GDPR. The EPDP Team recommends that the disclosure of ONLY a pseudonymized email or a uniform masked email address for a domain name registration be an automated disclosure in the SSAD on “Day 1”.

Rationale: Pseudonymized emails are an example of privacy by design that could contribute to a legitimate interest in a balancing exercise. This means there is less risk associated with disclosure. Just disclosing the pseudonymized email would provide requestors with a means to contact the registrant and without other identifying data.

Support Conclusion as written

No, I wish to continue to the next section

Support recommendation as written

No, I wish to continue to the next section

The comment submitted reflects the position of the National Association of Boards of Pharmacy

No, I would like to continue to the next section

Significant change required: changing intent and wording

The distinction between legal and natural persons should be recognized, and non-personal contact information for registrants who are legal persons should be publicly available. Registrars should instruct potential registrants on this distinction and require legal persons to submit contact details for the legal entity and exclude any personal information.

Rationale:
The National Association of Boards of Pharmacy (NABP) understands there is a persistent divergence of opinion regarding the topic of legal and natural persons within the EPDP working group. Rather than kicking this discussion down the road, the working group should recommend a solution that reflects what many believe to be a balanced and appropriate course of action. Distinguishing between legal and natural persons in the publication of registration data meets the dual goals of protecting personal privacy while maintaining a valuable resource that provides transparency for consumers, law enforcement, and cybersecurity researchers.

Because the GDPR applies only to natural persons, there is no need to mask contact information for legal persons. Moreover, disclosure protects the public interest, as it provides a measure of accountability for entities doing business online. This is especially important during the COVID pandemic. As such, discussions between the working group and the GNSO should focus not on whether to distinguish between legal and natural persons but, rather, how to implement an effective policy that does.

No, I wish to continue to the next section

No, I wish to continue to the next section

The National Association of Boards of Pharmacy, Registry Operator for the .pharmacy gTLD and a member of the Registry Stakeholder Group, has opted to submit comments separate from the RySG in order to bring its differing position to light.

I am submitting on behalf of INTA in my role as Senior Director, Internet Policy

No, I would like to continue to the next section

Support Recommendation intent with wording change

The last sentence stating that “the full privacy/proxy RDDS data may include a pseudonymized email” should be revised to say that “The full privacy/proxy RDDS data shall include a pseudonymized email address.” This will permit the ability to correlate other domain names registered by the same P/P service customer through the P/P service provider, without compromising the privacy of the customer unless or until the customer’s identity is disclosed in accordance with one of the legal justifications under GDPR or other applicable data protection laws.

Significant change required: changing intent and wording

INTA considers maintaining the distinction between natural and legal persons for purposes of the RDS policy (particularly as it determines redaction of data in public RDDS) critical to a functional RDDS and the security and stability of the Internet. This “conclusion” is a dereliction of the EPDP Team’s duty to provide a substantive recommendation on this issue. GDPR does not apply to the data of legal persons. See, e.g. GDPR Recitation 14 (“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.”); see also Letter from EDPB Chair Jelinek to ICANN President Marby (July 5, 2018) (quoting GDPR Recitation 14 verbatim). This distinction in GDPR is consistent with general legal standards concerning legal entities, which in exchange for a grant of limited liability must provide public contact information (e.g. a registered agent) through which the company can be notified in the event a citizen of the jurisdiction is injured by the company. INTA considers maintaining the distinction between natural and legal persons for purposes of the RDS policy (particularly as it determines redaction of data in public RDDS) critical to a functional RDDS and the security and stability of the Internet. Since it has already been publicly disclosed, the name and contact information for the legal entity that registered a domain name should be published because it furthers many policy interests including facilitating the investigations of law enforcement, intellectual property owners, and cybersecurity researchers. Accordingly, the distinction must be made in the context of processing domain name registration data, and all non-personal data, particularly that of legal persons, must be published in RDDS.

INTA has noted the concern expressed by some that the contact details submitted on behalf of a legal person registrant could be for a natural person serving as an employee or other representative of the legal person. This view makes the assumption that such individuals could be coerced or imposed upon by their employers to reveal their identity in this way. Those who have raised this concern contend that RDS data processing must therefore apply to legal persons to protect the rights of such natural persons whose data could be included in an RDDS record for a legal person’s registration. However, INTA notes that any individual contact person could either consent to the publication of their personal data in connection with the registration on the entity’s behalf, or simply provide generic contact information that does not directly identify an individual human contact person associated with making or managing the registration (e.g. “Domain Administrator” as the RNH “name”, and “admin@domain.com” as the RNH email). The EDPB does not consider the publication of such data in the context of RDDS to be unlawful as noted in their July 5, 2018 letter to ICANN, and such practice is not prohibited by ICANN requirements so long as the information is otherwise accurate and appropriately enables identification and contact of the legal entity or a representative.

To implement a recommendation along these lines, registrars could require as part of their registration process that the registrant identify if the registration is being made on behalf of a legal entity. Where the registrant so indicates, they MUST provide non-personal data to complete the data fields, including a generic registrant name (e.g. Domain Administrator), the full organization name, the physical address only for the legal entity, and a generic email address rather than that of a specific individual.

The availability of a publicly disclosed agent required by each Member State’s law as a quid pro quo in exchange for the limited liability established through the formation of the legal person provides an inherent consensual contact that clearly distinguishes a legal person from a natural person. This publicly registered contact required by law should be sufficient to permit ICANN and its contracted parties to provide full disclosure of the name, form and contact details for the legal person in RDDS, yet remain in compliance with GDPR. Accordingly, there is no basis for the EPDP to conclude that this data should not be published, nor any need for the EPDP team to waste valuable time consulting with the GNSO Council on this issue.

Significant change required: changing intent and wording

In view of the range of practices used by registry operators in the European Union, for example by EURID, France and Belgium, among others, the EPDP should further examine the ability to publish the City field, rather than broadly concluding that “it is not able to provide a rationale that would justify universal publication of the city field.” The publication of the City field provides a clear and sufficiently meaningful benefit to rights holders (in particular where they are seeking to protect rights in force at a sub-national level), and also serves the public interest more broadly by ensuring lawsuits and other similar complaints are raised in an appropriate venue. The potential impact on data subjects of publication of the City field, in addition to the other data elements already published in the RDDS, is zero or negligible. The balancing test points towards publication of the City field being appropriate and a number of major registries in the EU already do this, indicating it is permissible under GDPR. Thus, INTA believes that the City field should and can legally be published in RDDS and that the EPDP should revise its recommendation here accordingly.

Support Recommendation intent with wording change

INTA supports the intent of this recommendation, namely in that it works toward the stated goal of ICANN Org, as a matter of urgency, identifying, documenting, and relying upon set retention periods for specific data elements to establish the required relevant and specific minimum data retention expectations for registrars. This is important both for transparency in the community, as well as for holding registrars to certain responsibilities in our collective fight against DNS abuse. However, INTA believes this recommendation wrongly limits the retention periods, by requiring 18 months retention of only the data elements deemed necessary for purposes of the TDRP, and merely making permissible longer data retention periods if the registries or registrars choose to do so. Brand owners and third-party requestors often have legitimate need to obtain historical data in order to protect their interests, and is it important that data be available to them when needed, which can only be ensured if registries and registrars are required to retain data for longer periods, and not only in the context of TDRP.

Support Conclusion as written

Significant change required: changing intent and wording

A pseudonymized code or email address is necessary to assess patterns of multiple malicious or abusive domain name registrations associated with the same registrant. February 4, 2020 legal guidance concluded that anonymized or pseudonymized emails are personal data, because “contracted parties and/or ICANN org will retain the ability to relate the substitute email address to the true email address … in order to enable for forwarding of correspondence … This is particularly the case since third parties will use the masked email address to contact the data subject….” Therefore at a minimum, it stands to reason that if a unique code were merely used for assessing patterns, rather than an email address used for contacting data subjects, it would not be considered personal data. We would suggest revising this recommendation accordingly, i.e. by either: (1) specifying that a pseudonymized email address to facilitate cross-registration correlation is appropriate and permissible under GDPR and therefore should be used instead of an anonymized email address or web contact form/link, or (2) by recommending instead that all RDDS records provide an anonymized email address as well as a pseudonymized code (as a new data element or reviving the once-used Registrant ID field) to enable cross-registration correlation without revealing personal data.

Support Conclusion as written

INTA understands that the GNSO Council has already directed the EPDP and community on this matter, so it seems that any disagreement with the conclusion would be moot. That said, the matter of data accuracy is of critical importance to INTA. In the current environment where the majority of RDS data is redacted from public view, it is critical that disclosure of data through the SSAD contain the most accurate data possible. If such information is inaccurate or false, this would be of little assistance to the party seeking disclosure, and place additional burdens on the users of SSAD to address false or inaccurate data that can no longer be easily determined from the public RDDS alone. Thus, we believe that a timeline must be set for further review of the question of data accuracy and, in the meantime all RDS data (public and non-public) should be provided to ICANN Org to enable ICANN Compliance to maintain a data accuracy program and data verification compliance.

Intent and wording of this recommendation requires amendment

We take this opportunity to revisit the initial placeholder Purpose 2 put forth by the EPDP Team: “Contributing to the maintenance of the security, stability, and resiliency of the Domain Name System in accordance with ICANN’s mission through enabling responses to lawful data disclosure requests” (emphasis added). We believe it is important to retain the intent and wording geared towards combatting DNS abuse in Purpose 2, which is now absent in the present recommendation. We continue to stress the importance of enabling efficient and effective responses to data disclosure requests, and believe this falls under ICANN’s responsibilities and mission.

No, I wish to continue to the next section

INTA expresses its appreciation for the hard work and dedication of the EPDP team. INTA also fully understands that the issues the EPDP team is addressing are multi-faceted, complex, and subject to varying reasonable interpretations in terms of what is required under law and what is needed by the various members of the Internet community.

With that said, as a general observation, INTA notes the serious lack of progress made with respect to several critical issues that were deferred in Phase 1 to be addressed in Phase 2. The work remains seriously incomplete. NOTE: The full text of INTA's response has been forwarded to ICANN staff as it exceeds the 2000 character form limitation. INTA expresses its appreciation for the hard work and dedication of the EPDP team. INTA also fully understands that the issues the EPDP team is addressing are multi-faceted, complex, and subject to varying reasonable interpretations in terms of what is required under law and what is needed by the various members of the Internet community.

With that said, as a general observation, INTA notes the serious lack of progress made with respect to several critical issues that were deferred in Phase 1 to be addressed in Phase 2. The work remains seriously incomplete. For instance, it was expected that distinguishing between legal persons vs. natural persons would be resolved in line with the clear exception of legal persons from GDPR. Yet despite viable and legally sound options to resolve any concerns, e.g., use of registered agents as contacts in line with the discussion above, the EPDP team has not reached a meaningful conclusion on this issue as discussed in more detail above. Its further delay on this issue is unreasonable and detrimental to building confidence that the interests of all stakeholders are being considered, and that the contours of the GDPR are actually being reasonably applied.

INTA also reiterates that GDPR has specific jurisdictional limitations. It should only apply where there is an actual nexus to the European Union within the meaning of GPDR Article 3. Just as over-application of GDPR to cover legal persons is inconsistent with the requirements of GDPR, so, too, is extending GDPR to any data that is beyond the territorial scope of the regulation. It is important to recognize that over-application of GDPR has serious and harmful consequences, including facilitating abuse within the DNS. Data controllers and processors must recognize the limitations of the GDPR and that there are appreciable benefits of publishing as much domain name registration data as legally permissible that serve the public interest, including for purposes of law enforcement, cybersecurity, intellectual property enforcement and consumer protection, etc.

It was also expected that data accuracy and WHOIS/RDAP accuracy concerns would be resolved in Phase 2 as per the commitment made in Phase 1. However, it appears that any meaningful resolution on this issue is also being delayed which, again, lowers confidence in the multi-stake holder process and is detrimental to the RDS as a whole.

INTA notes the continuance of the unreasonable hold on implementation of the PPSAI Consensus Policy. INTA and other members of the intellectual property community have long argued that there was no reasonable need to suspend PPSAI implementation, which has now been stalled since 2018 despite adoption of the Consensus Policy by the Board in 2016. The impact of the stalled work continues to be felt across the community. Cybercriminals regularly hide their identities behind privacy/proxy services and many privacy/proxy services hinder at best, and refuse at worst, legitimate access to underlying registrant data when legitimate requests are made. Given that more than 25% of all domains use privacy/proxy services, there is real urgency in implementing the PPSAI policy, which provides guidelines for accreditation and clear requirements for disclosure of privacy/proxy-shielded registrant data, among other things. INTA calls on the EPDP team to unequivocally recommend that PPSAI policy implementation resume at once.

Tucows family of registrars

No, I would like to continue to the next section

Support Recommendation as written

The intent of the recommendation is acceptable and we support it as long as the use of an accredited privacy/proxy service by a given domain can be determined in an automated manner. Implementation of this Recommendation must wait until the PPSAI is implemented.

Support Conclusion intent with wording change

The EPDP Phase 1 team addressed this topic and reached a suitable conclusion in Point 1 of Recommendation #17. The EPDP Phase 2 team should now confirm that Registrars and Registry operators are permitted but not required to differentiate between Registrants of different legal types. The study recommended in Point 2 has been completed and, while we do not believe that any further requirements should be recommended at this time, if any more work needs to be done on this topic it should be referred to the GNSO Council instead of back to the EPDP team.

Support Conclusion as written

Significant change required: changing intent and wording

Data retained for the purposes of the TDRP must only be used for the TDRP or for compatible other data processing activities; no such compatible activities have yet been identified. The section of this recommendation beginning with “For clarity…”, including everything that follows, should be removed entirely. Additionally, text should be added to the initial section clearly specifying the purpose for processing this retained data as being for TDRP issues. We propose that the Recommendation be amended to:
The EPDP Team confirms its recommendation from phase 1 that registrars be required to retain only those data elements deemed necessary for the purposes of the TDRP, for a period of fifteen months following the life of the registration plus three months to implement the deletion, i.e. 18 months, FOR THE PURPOSE OF THE TDRP. This retention is grounded on the stated policy stipulation within the TDRP that claims under the policy may only be raised for a period of 12 months after the alleged breach (FN: see TDRP section 2.2) of the Transfer Policy (FN: see Section 1.15 of TDRP).
(NOTE THAT OUR ADDITIONAL TEXT IS IN ALL-CAPS TO MAKE IT EASY TO FIND)

Support Conclusion as written

Support Recommendation as written

Support Conclusion as written

No, I wish to continue to the next section

Support recommendation as written

No, I wish to continue to the next section

ICANN Business Constituency

No, I would like to continue to the next section

Significant change required: changing intent and wording

This falls well short of the public’s interest in data disclosure for reasonable purposes.
ICANN has no choice -- it must restart the implementation team for Privacy/Proxy Services Accreditation Issues (PPSAI). After three years, the settled PPSAI policy needs to move into implementation immediately.

Cybercriminals are benefiting from the stalled privacy/proxy policy. Meanwhile, the rest of the community -- even ICANN itself -- is suffering from the stall.

ICANN Org is turning a blind eye to the growing use of privacy/proxy services to facilitate fraud and abuse.

The EPDP is not addressing privacy/proxy registrations. Without implementation, there will be a gaping and widening hole in any Whois policy coming from the EPDP on what amounts to approximately 31% of domain registrations -- or approximately 110 million (based on trends from UDRP filings for the last three years).

The BC recommends the following wording for a policy recommendation:

ICANN Org MUST direct the Privacy/Proxy Services Accreditation Issues IRT to promptly conclude its implementation work. That IRT output must then be incorporated into the EPDP policy once completed to dictate how an accredited privacy/proxy service is used under the policy.

Significant change required: changing intent and wording

• Lack of differentiation between legal and natural persons is an over-application of GDPR and breaks with one of the core tenets of the GDPR.
• The legal vs. natural question has persisted throughout the life of the EPDP; it’s well known to the community that such a distinction can be made and is an intended underpinning of the GDPR.
• The legal vs. natural persons distinction is a Phase 1 issue that was promised to be addressed in Phase 2. However, various parties participating in the EPDP have thus far successfully blocked policy development on this matter. Now is the time to handle what should be a non-controversial issue to fall in line with the GDPR -- which is the point of this exercise.
• We object to the legal vs. natural person distinction being punted to GNSO Council, where we fear it would be intentionally de-prioritized or buried.

The BC recommends following legal advice from Bird & Bird which, upon implementation, would allow contracted parties to rely on self-identification by the registrant to determine legal vs. natural status and the ability to reveal. To further streamline the process, the BC recommends automated responses to data queries for legal persons.

The BC suggests the following wording for a policy recommendation: In the case of a domain name registration where the registration data has been self-identified as that of a legal person, a party’s legitimate request for disclosure MUST be granted, preferably on an automated basis.

Support Conclusion intent with wording change

The BC would like to see automated use case where just the city field would be returned in appropriate situations, such as where the jurisdiction for legal claims is to be established.

Support Recommendation intent with wording change

The BC notes there will be cases in which investigations require access to data beyond the proposed 18 month timeframe put forth in the recommendation. We therefore recommend a retention period of at least two years.

Support Conclusion intent with wording change

This is acceptable under the assumption that Purpose 2 will cover any necessary processing by ICANN of personal data; this includes OCTO, Compliance, assistance with cyber investigations, etc. If the assumption is not correct, this outcome is unacceptable.

Further, the BC urges the EPDP team to recognize that ICANN Org has identified its own unique role with regard to the registration database. Quoting from ICANN Org’s comment to the European Commission on the application of GDPR: “ICANN’s role in providing the technical coordination of the globally distributed WHOIS system is a unique matter, considering the public interest nature of WHOIS, and responsibilities relating to the WHOIS system are encapsulated in ICANN’s Bylaws.” ICANN Org goes on to say: “Developing and implementing a global system to balance the law’s data protection requirements with the legitimate interests of parties seeking access to nonpublic gTLD registration data, including the important public interest goals that legitimate access to non-public registration data serves for all parties involved, presents a number of challenges.” (Emphasis added.) Implicit here is the periodic need for ICANN Org itself, including OCTO, to access WHOIS records in support of this unique mission. The community should recognize this admission by ICANN Org and take care not to abridge this capability.

Significant change required: changing intent and wording

The BC supports neither this recommendation nor the interpretation of legal guidance purporting to support it. Anonymization of email addresses is designed precisely to avoid disclosure of personally identifiable information while still offering a reasonable method for contacting the registrant as necessary.

Registrant contactability should be enhanced:

ICANN should ensure registry and registrar RDAP output includes a method for contacting the current registrant.

Registrars should take measures to ensure messages forwarded to domain contacts are not blocked as spam but affirmatively received by intended contacts.

ICANN should require automation of contact mechanisms, without resorting to the use of generic addresses.

ICANN should regularly test contact forms and anonymized emails to determine if operational.

Significant change required: changing intent and wording

The European Commission has (correctly) said accurate data isn’t an optional obligation of GDPR -- it’s essential. A reminder that Article 5(1)d of the GDPR stipulates 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.” This is critical to a workable registrant data system and an obligation for controllers who collect, store, and process personal data.

Data accuracy is an issue the EPDP team promised action on during Phase 1 as a deliverable in Phase 2. That promise has been broken.

The BC suggests the following wording for a policy recommendation:

ICANN Org MUST address registration data accuracy by:
• resuming its registration data accuracy studies;
• Obtaining contact data for Compliance department use in performing data accuracy compliance checks;
• Implementing enforceable cross-field validation check requirements for Registrars and Registries, per the terms of the 2013 RAA; and
• Requiring enhanced verification requirements for registrants – particularly registrants identified as engaged in DNS abuse, online crimes and IP infringement (following the methodology used in conducting the accuracy tests).

No, I wish to continue to the next section

No, I wish to continue to the next section

The new policy is inadequate on the most basic level, making it unfit for purpose to "ensure compliance with the GDPR while maintaining the existing WHOIS system to the greatest extent possible." (https://www.icann.org/news/blog/data-protection-privacy-issues-update-more-details-published-on-icann-proposed-interim-model )

Accordingly, the BC will have a difficult time supporting the EPDP’s proposed outcomes, for the following reasons:

GDPR has been consistently and inappropriately over-applied to impact jurisdictions and data subjects outside the EU due to ICANN allowing “flexibility to Registry Operators and Registrars to choose to apply the requirements [of the GDPR] on a global basis where commercially reasonable to do so or where it is not technically feasible to limit application of the requirements to data governed by the GDPR.” ( See ICANN’s Temporary Specification for gTLD Registration Data: https://www.icann.org/resources/pages/gtld-registration-data-specs-en )

While this flexibility may have been necessary at the outset of ICANN’s new Whois policy implementation to quickly pivot to address the GDPR, the EPDP team -- chartered to review and tweak that policy -- has proposed no remedies or adjustments that would “right-size” this unnecessary and overly broad application of the GDPR. Not only does this deny those with legitimate reasons access to data (data that is at the heart of maintaining internet security and stability and not meant to be covered by the GDPR), such over-application has blunted the potential outcomes of the EPDP and granted cover to bad actors online.

The EPDP team has failed to meet its charter obligations. The team has consistently sought to block data access in nearly all scenarios, while failing to answer operational questions it was chartered to address. For example:
o The Whois system has not been preserved “to the greatest extent possible” And, instead, the EPDP seemed to constantly seek the opposite outcome even where the GDPR and other laws supported otherwise.
o Fundamental questions of data controllership and purpose for collection of data have not been answered, making policy output flawed, if not entirely useless under a GDPR analysis.
o Fundamental GDPR tenets, such as application to natural persons only and not legal persons were ignored or deemed “out of scope”, making policy output flawed under a GDPR analysis.
o Common Whois use cases have not been properly identified or included in discussions to form the basis of policy output.
o There’s been no commitment to prompt responses to volume data requests for cybersecurity needs or as otherwise necessary to perform basic counter-DNS abuse functions.
o Many important issues pushed to Phase 2 of EPDP work were simply ignored or later argued to be “out of scope” and left unaddressed.

The Standardized System for Access and Disclosure (SSAD), as proposed by the EPDP, is not a useful system because the decision making is decentralized. Rather, in operational reality, it’s more of a ticketing system that eases the intake burden on data controllers (currently assumed to be Registry Operators and Registrars) but provides no real benefit to users. This is in contravention of guidance from the Data Protection Authority and the European Commission about their preferences for such a model that would, at a minimum, centralize the Whois system. ( See https://www.icann.org/resources/pages/h/en/system/files/correspondence/odonohue-to-marby-03may19-en.pdf and European Commissioner Thierry Breton’s answer given on behalf of the Commission to a question from a Member of the European Parliament : https://www.europarl.europa.eu/doceo/document/E-9-2020-000826-ASW_EN.html#def1 )

There is no remedy envisaged to address instances where legitimate data requests are being denied. There needs to be set guidance on how legitimate and lawful requests are fulfilled. Many such requests are being unnecessarily denied today, and nothing about the proposed EPDP policy or SSAD would change that outcome. ICANN Org must be able to take compliance action to remedy situations where legitimate data requests are routinely being denied or outright ignored.

Expanded use cases for automation have been dismissed by the EPDP team and those omissions will hobble the SSAD. It is critical these use cases be immediately added as part of the SSAD if it is to meet global needs. Use cases include:
o Law enforcement agency in same jurisdiction as contracted party
o Request for city field (only)
o Registration record contains no personal data and already has been disclosed
o Registration record already has been disclosed under the same authorization assertions to a requestor of the same type
o Cases of a “clear cut” trademark claim
o When identifying the infrastructure involved in botnets, malware, phishing, and consumer fraud
o Data subjects have consented to make their registration data public
o Request for data from a UDRP/URS provider
o Request for data from ICANN Contractual Compliance, in support of compliance-related investigations

The EPDP has overlooked Section 4.2 of Appendix A of the Temporary Specification, which states that:
4.2. Notwithstanding Section 4.1 of this Appendix, Registrar and Registry Operator MUST provide reasonable access to Personal Data in Registration Data to a third party where the Article 29 Working Party/European Data Protection Board, court order of a relevant court of competent jurisdiction concerning the GDPR, applicable legislation or regulation has provided guidance that the provision of specified non-public elements of Registration Data to a specified class of third party for a specified purpose is lawful. Registrar and Registry Operator MUST provide such reasonable access within 90 days of the date ICANN publishes any such guidance, unless legal requirements otherwise demand an earlier implementation.
This provision is necessary to incorporate into any EPDP policy to ensure that a new policy adjusts automatically in situations where legal clarity under GDPR or other applicable law is received after the EPDP concludes its policy work.

The BC must take the opportunity here to also highlight important policy proposals made by Interisle in its study that have not yet been included in the EPDP team’s output that would not only improve the team’s work product, but would constructively benefit the user community without violating the tenets of GDPR. Namely:

Steps for effective RDAP implementation:
o ICANN Org should expeditiously publish a plan, subject to public comment, for fully retiring Whois in favor of RDAP, including reasonable timelines with milestones and deadlines to meet.
o Registrars must be required, via new RAA language, to serve registration data (equivalently, regardless of the access mechanism, and according to meaningful SLAs) for all sponsored domains, across all gTLDs.
o ICANN Org should create a support program for RDAP end users, including a comprehensive toolkit.
o Contracted parties must provide a free, web-based output mechanism on their respective websites, configured for easy human understanding and use. This requirement, and its associated SLAs, should be codified in contracts (see below regarding contract enhancement).
o Registrars must come to parity with registries in terms of obligations to publish monthly RDAP query activity.
o ICANN’s compliance monitoring function should verify that RDAP services are responding with correctly formatted and complete data, including all required fields.
o IANA should publish changes to registry and registrar base URLs into the RDAP Bootstrap Registries within 24-48 hours of update; PTI must set and publish SLAs and performance metrics for these functions.

Compliance: ICANN must enhance and enforce its contracts in ways it historically has not:
o Solicit community input regarding constructive modifications to the RAA (last updated in 2013) and RA (last updated in 2012), particularly concerning the area of DNS abuse, and enter into negotiations with contracted parties to effect appropriate changes.
o Revise agreements so that rate-limiting access to public data is not permitted.

Finally, the BC supports the GAC’s comment on this addendum. The BC finds the GAC’s positions (treatment of legal person data, registration data accuracy, treatment of privacy/proxy registrations, and anonymized email) persuasive and oriented toward successful outcomes for the EPDP that will benefit the internet community, and urges the EPDP team to favorably consider them.

No, I would like to continue to the next section

Support Recommendation intent with wording change

It should be possible for the registrar to do this in an automated fashion.

Support Conclusion intent with wording change

Agree with comments from G Bunton

Support Conclusion as written

Support Recommendation intent with wording change

Data collected for the TDRP can only be used for that purpose - the section starting with "for clarity" should be removed

Support Conclusion as written

Support Recommendation as written

No, I wish to continue to the next section

No, I wish to continue to the next section

No, I would like to continue to the next section

Support Recommendation intent with wording change

The last sentence stating that “the full privacy/proxy RDDS data may include a pseudonymized email” should be clarified to say that “As defined by the PPSAI Policy, the full privacy/proxy RDDS data will include an email address, and this email address may be pseudonymized..” Further, to avoid the pseudonymized email address problem noted by Bird & Bird, privacy/proxy RDS data should also include a non-email pseudonymized P/P account number. This will permit the ability to correlate other domain names registered by the same P/P service customer through the P/P service provider, without compromising the privacy or contactability of the customer unless or until the customer’s identity is disclosed in accordance with one of the legal justifications under GDPR or other applicable data protection laws.

Given the dependency on the PPSAI, the following obligation must be added to Recommendation #20: -

Given this recommendation is dependent on both the completion of the Privacy/Proxy Implementation Review Team, including the launch of an accreditation program, and ultimately the deployment of services that realize this implementation by Registrars and Accredited Privacy/Proxy service providers, ICANN Org MUST un-pause and immediately instruct the Privacy/Proxy Implementation Review Team to complete all remaining work.

Significant change required: changing intent and wording

High Level:
Registries and registrars SHOULD distinguish between legal and natural persons in the publication of RDDS data. Where the registry, registrar, or Central Gateway Manager knows that RDDS data is that of a legal person, and it is not published by the registry or registrar, it MUST be available through the SSAD as an automated use case from Day 1. Additionally, note that registries are permitted to prohibit, within their registration policies, the use of any personal data as RDDS data, and require that registrants submit only data belonging to legal persons, which includes domain names used by unincorporated sole proprietorships offering goods or services for sale on the Internet.
Implementation guidance: registrars MUST provide high-level guidance to potential registrants on the difference between a legal and natural person, and how legal persons can avoid providing personal data. Registrars must pass through to registrants any registry-level prohibitions on the use of personal data as RDDS data.
Rationale and Legal Analysis:
The IPC proposes this language in line with the legal advice provided by Bird & Bird to the EPDP as part of their Phase 1 work. The IPC also refers to the Court of Justice case 9 March 2017, Manni, C-398/15 (http://curia.europa.eu/juris/document/document.jsf?text=&docid=194059&pageIndex=0&doclang=EN&mode=req&dir=&occ=first&part=1&cid=1767678), and communication between the EPDB and ICANN on 5 July 2018 https://www.icann.org/en/system/files/correspondence/jelinek-to-marby-05jul18-en.pdf.
Specifically, the single case cited by the European Commission at the above reference, Camera di Commercio, Industria, Artigianato e Agricoltura di Lecce v Salvatore Manni, 9 March 2017, Manni, C-398/15, further supports that distinction by allowing Member States to determine on a case by case basis whether to restrict the privacy data of natural persons that would be subject to disclosure on public registries (e.g. central register, commercial register or companies register) after dissolution and windup of the public entity. The subject natural persons would have to apply to the authorities responsible for the registries to restrict access to their personal privacy data. See Judgement of the Court of Justice of 9 March 2017, Manni, C-398/15.
The GDPR expressly distinguishes between natural and legal persons and makes clear that it does not apply to legal persons. Specifically, Recitation 14 states that “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.” This language is clear and unambiguous. The European Commission has further confirmed that the GDPR “rules only apply to personal data about individuals, they don’t govern data about companies or any other legal entities.” (https://ec.europa.eu/info/law/law-topic/data-protection/reform/rules-business-and-organisations/application-regulation/do-data-protection-rules-apply-data-about-company_en). The single case cited by the Commission at the above reference further supports that distinction by allowing Member States to determine on a case by case basis whether to restrict the privacy data of natural persons that would be subject to disclosure on public registries (e.g. central register, commercial register or companies register) after dissolution and windup of the public entity. The subject natural persons would have to apply to the authorities responsible for the registries to restrict access to their personal privacy data. See Judgement of the Court of Justice of 9 March 2017, Manni, C-398/15
(http://curia.europa.eu/juris/document/document.jsf?text=&docid=194059&pageIndex=0&doclang=EN&mode=req&dir=&occ=first&part=1&cid=1767678)
NN. See, e.Further, representatives of the European Data Protection Board (“EDPB”) have confirmed the natural person v. legal person distinction and the exception of legal persons from GDPR in correspondence with ICANN See e.g., Letter dated July 5, 2018, from EDPB Chairperson Andrea Jelinek to ICANN President Goran Marby, p.4 (“The GDPR does not apply to 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.”) Ms. Jelinek also suggested in the July 5 Letter that ICANN should clarify “that the registrant is free to (1) designate the same person as the registrant (or its representative) as the administrative or technical contact; or (2) provide contact information which does not directly identify the administrative or technical contact person concerned (e.g. admin@company.com)”. Id.
IPC has also noted that the concern expressed by some, perhaps as a justification for expanding GDPR to cover legal persons, is that the contact details submitted would be for natural persons serving as employees of the legal person who have been prevailed upon by their employers to disclose their personal data. As noted in the EPDP working sheets and a memorandum to ICANN from the law firm of Bird and Bird, the concern raised by the data privacy authorities about disparate treatment in the Registration Data Directory Service (RDDS) of the personal information of natural persons, expressly identified as protected under GDPR and legal persons (e.g. juristic entities), not covered by GDPR, was that contact details for legal persons in RDDS, e.g., administrative, billing and technical, would be employees of the legal person. The employees selected to be disclosed as these contacts, they assumed, would be coerced or imposed upon by their employers to reveal their identity. This analysis, therefore, contends that GDPR must still apply to legal persons to protect the rights of the natural person employees.
IPC notes first that the contact person whose name is provided could just as likely be a legal person as well, or a paid administrator such as a resident, registered or statutory agent, or the top level managers, directors, officers or founding owners governing the registrant company, whether or not employed by it, would be less subject to coercion. In addition the Commission expressly noted in the July 5 Letter that there is nothing to prohibit the contact email from being that of info@company.com: “If the registrant provides (or the registrar ensures) generic contact email information (e.g. admin@domain.com), the EDPB does not consider that the publication of such data in the context of WHOIS would be unlawful as such.” Similarly, it is permissible to use a title, such as “Domain Administrator” as the Registrant Name in the dataset, allowing for publication of legal entity data without improperly publishing natural person data of an individual acting on behalf of the legal entity registrant. ICANN should make the clarifications suggested in the July 5 Letter to maintain the legal versus natural person distinction.
Also, the legal person or legal entity as the term is used in the above reference by the Commission is by definition a person “created by law”. Although the applicable law of the jurisdiction in which the legal person was organized may vary, it appears reasonably certain that the legal person was organized to avail its owners (whether legal or natural persons) of limited liability, denoted by the business descriptor that must be attached to the company name (e.g. Ltd., SARL, SA, SRL, GMBH, etc.). Moreover, in addition to the mandatory attachment of a business descriptor, in exchange for a grant of limited liability the organizers must also provide a valid contact through which they can be reached in the event a citizen of the jurisdiction is injured by the company. While each EU Member State has its own equivalent, in the U.S. such contact is provided through the designation of a registered agent, who among other things, consensually and contractually provides contact information on a public registry for notice (service of process) by claimants who assert they have been injured by the company. Given the ready availability of a publicly registered contact (see case above referencing “central register, commercial register or companies register” as possible examples of sources of such public contact data) and one that is legally bound to hold itself out publicly for notification of claims, IPC suggests that the vast majority of legal persons may already have provided through their creation under law, a viable alternative to serve as the contact person in RDDS, that has already consensually agreed to public disclosure of their valid, member-state ordained contact information. Why not employ this as an acceptable contact for RDDS disclosed data for legal persons?
The registered agent as the contact would meet the requirements of DPAs by avoiding the issue of employment and its assumption of possible duress or imposition by a legal person employer over its natural person employee.
The availability of a publicly disclosed registered agent required by each Member State’s law as a quid pro quo in exchange for the limited liability established through the formation of the legal person provides an inherent consensual contact that clearly distinguishes a legal person from a natural person. This publicly registered contact required by law should be sufficient to permit ICANN and its contracted parties to provide full disclosure of the registered agent as the contact for the legal person in RDDS while remaining in compliance with GDPR.
IPC considers maintaining the distinction between natural and legal persons and the exception of legal persons from GDPR critical to a functional RDDS and the security and stability of the Internet. The disclosure of the name and contact information of the legal entity that registered a domain name furthers many policy interests including facilitating the investigations of law enforcement, intellectual property owners, and cybersecurity researchers. It is also not reasonably debatable that such data does not constitute personal data protected by the GDPR. Accordingly, since disclosure of the name and non-personal contact information of the registrant if it is a legal entity furthers many policy interests and there is no legal or policy basis for not disclosing such information, there is no basis for the EPDP to conclude that this information should not be disclosed, nor any need for the EPDP team to waste valuable time consulting with the GNSO Council on this issue.
Numerous ccTLD and .Brand registry operators already prohibit the use of any personal data as RDDS data. Further, the IPC believes that while it is appropriate to refer to the GNSO Council for guidance as to “next steps”, this guidance should be limited to procedural input, as the GNSO Council is not the appropriate body to be tasked with developing policy on this or other matters. As per Article 11.3(d) of ICANN’s Bylaws: “The GNSO Council is responsible for managing the policy development process of the GNSO.” The IPC emphasizes that “managing the policy development process” (emphasis added) must be distinguished from “policy development” (again, emphasis added): Article 11 of the Bylaws make the GNSO Council responsible for the former, while Annex A attributes responsibility for the latter to the Policy Development Process. Further, with respect, and acknowledging the difficult task faced by all who have participated - volunteers, Chair and Vice Chair, and staff - in the EPDP, the IPC objects to the tendency of the EPDP to “handball” issues flagged as essential in the EPDP Charter from Phase 1 to Phase 2, and now from Phase 2 to the GNSO Council. This damages the perceived legitimacy of the EPDP’s outcomes and may have lasting repercussions in implementation and enforcement.

Significant change required: changing intent and wording

In view of the range of practices used by registry operators in the European Union, for example by EURID, France and Belgium, among others, the EPDP should further examine the ability to publish the City field, rather than broadly concluding that “it is not able to provide a rationale that would justify universal publication of the city field.”

The publication of the City field provides a clear and sufficiently meaningful benefit to legal rights holders (in particular where they are seeking to protect rights in force at a sub-national level) among other legitimate users of RDDS, and also serves the public interest more broadly by ensuring lawsuits and other similar complaints are raised in an appropriate venue. As the IPC has previously noted, in jurisdictions including the US, the City is needed to know what law applies in a given case. For example, simply knowing that the registrant’s postal address is in California does not sufficiently indicate whether controlling precedent (law) of the U.S. federal court’s Northern District of California would apply if the postal address City is San Francisco, or whether the Southern District’s law would apply if the postal address City is San Diego. The same holds true in many other states where a significant number of registrants are located. The potential impact on data subjects of publication of the City field, in addition to the other data elements already published in the RDDS, is de minimis. Balancing the public interest against risk points towards publication of the City field being appropriate and a number of major registries in the EU already do this, indicating it is permissible under GDPR. Thus, the IPC believes that the City field should and can legally be published in RDDS and that the EPDP should revise its recommendation here accordingly.

Support Recommendation intent with wording change

The IPC supports the intent of this recommendation to bolster an important ICANN Org goal, namely: as a matter of urgency, identifying, documenting, and relying upon set retention periods for specific data elements to establish the required relevant and specific minimum data retention expectations for registrars. Retention of RDS data is an important tool in combating DNS abuse, as it increases transparency within the community. Additionally, the IPC supports the effect of this recommendation in that it makes clearer the responsibilities of registrars in the collective fight against DNS abuse, and thus aids in mitigating registrars’ liability. Data retention is also necessary for the other stated Purposes for the collection of RDS data, not merely TDRP, so this draft recommendation is too narrow in scope. The IPC therefore believes that this recommendation should require retention not only in the context of TDRP, so important data is retained, and available when needed for purposes consistent with the purposes for which the data was collected.

Support Conclusion intent with wording change

It is important to note that the reason the EPDP team came to this preliminary conclusion was because the processing of data for all functions, teams, groups, divisions and organizations within ICANN Org, as a whole, would be sufficiently encompassed by the updated and currently agreed Purpose 2. As such Purpose 2 would include, by definition, research and investigative work undertaken by the Office of the CTO [in the role it plays to ensure the security, stability and resilience of the Internet domain identifiers.]

For the avoidance of doubt and to ensure sufficient context and detail to ensure proper implementation, this important point should be made clear in the text of the conclusion, as follows.

"Having considered this input, most members of the EPDP Team agreed that at this stage, there is no need to propose an additional purpose(s) to facilitate ICANN’s Office of the Chief Technology Officer (OCTO) in carrying out its mission. This reason for this agreement is because the newly updated ICANN Purpose 2 sufficiently covers the work of the OCTO, along with the work of other ICANN org teams [such as Contractual Compliance and others]. Most also agreed that the EPDP Team’s decision to refrain from proposing an additional purpose(s) would not prevent ICANN org and/or the community from identifying additional purposes to support unidentified future activities that may require access to non-public registration data."

Significant change required: changing intent and wording

A pseudonymized email address or registrant ID code is necessary to assess patterns of multiple malicious or abusive domain name registrations associated with the same registrant.

February 4, 2020 legal guidance to the EPDP concluded that anonymized or pseudonymized emails are personal data, because “contracted parties and/or ICANN org will retain the ability to relate the substitute email address to the true email address … in order to enable forwarding of correspondence … This is particularly the case since third parties will use the masked email address to contact the data subject….” Therefore at a minimum, it stands to reason that if a unique code were used for assessing patterns, rather than an email address that could also be used for contacting data subjects, the unique code would not be considered personal data. The IPC therefore proposes revising this recommendation accordingly, i.e., by either: (1) specifying that a pseudonymized email address to facilitate cross-registration correlation is appropriate and permissible under GDPR and therefore should be used instead of an anonymized email address or web contact form/link; or (2) by recommending instead that all RDDS records provide an anonymized email address as well as a pseudonymized code (as a new data element or reviving the once-used Registrant ID field) to enable cross-registration correlation without revealing personal data.

Significant change required: changing intent and wording

The IPC is disappointed that the GNSO Council has prematurely removed the subject of data accuracy from the EPDP’s remit, a decision with which the IPC disagrees. While the overall topic of data accuracy requirements is indeed complex and warrants significant legal and policy work, the EPDP is well suited to resolve a few discrete policy matters within the remit of the EPDP charter. This important topic should not have been removed from the EPDP’s work.

ARS

First, the IPC specifically objects to the treatment of the subject of data accuracy as it relates to the Accuracy Reporting System (ARS). Encouragingly, we note that the recent addition of “Purpose 2” has added needed clarity, which should enable ICANN to continue this important activity without undue delay. For reasons including input received from the EU Data Protection Board (https://www.icann.org/resources/pages/h/en/system/files/correspondence/odonohue-to-marby-03may19-en.pdf), the Registration Data Policy from EPDP Phase 1 is oddly missing an ICANN-related purpose for the collection of RDS data. However, the EPDP Phase 2 Initial Report Addendum has corrected this. The Addendum reflects consensus on a simplified ICANN-related purpose for the collection of RDS data, noting that RDS data is collected to “Contribute to the maintenance of the security, stability, and resiliency of the Domain Name System in accordance with ICANN’s mission.”

To correct the record from ICANN’s December 5, 2019 letter (https://www.icann.org/en/system/files/correspondence/marby-to-drazek-05dec19-en.pdf) to the GNSO Council, the third sentence in the third paragraph of the letter should read: “ARS has relied on collecting registration data for which ICANN is controller to determine the accuracy of registrant contact information as specified in the 2013 Registrat Accreditation Agreement.” ICANN mischaracterizes ARS processing as related to “publicly available registration data,” but ICANN Org previously clearly performed this ARS work as data controller to ensure registrars were complying with the data processing agreement between ICANN and the registrar pursuant to their obligations under the 2013 Registrar Accreditation Agreement. The fact that ICANN Contractual Compliance would investigate inaccuracies detected by ARS, in addition to those reported by third parties, further evidences this distinction. The fact that the data was publicly available and not exclusively made available to ICANN as controller is merely a relic of the pre-GDPR world where unfettered publication of RDS data was commonplace as the most expedient way to serve all controller and third-party interests in identifying the registered owner of a domain name. However, ICANN acting as data controller for the purpose of ensuring the security, stability, and resiliency of the DNS continues to have every interest it ever had in ensuring the accuracy of the data for the purpose for which it was collected. There is, in other words, no impact on ICANN’s interest in or obligation to enforce accuracy occasioned by the GDPR. Based on this and the renewed clarity around “Purpose 2” for the collection of the data, the EPDP should easily be able to require that ICANN’s important ARS work continues.

Additionally, the need for ICANN’s ARS work has increased tremendously now that third parties are denied reliable access to RDS data. The direct and unavoidable consequence of ICANN’s position as to internet content (ie, that ICANN will not police internet content) is that law enforcement, cybersecurity professionals, intellectual property owners, and other consumer protection groups have been forced to carry this burden, and in doing so have primarily contributed to the security, stability, and resilience of the DNS by reporting RDS data inaccuracy. Unfortunately, all these groups have reported an utter inability to do their important work when relying on contracted parties to grant access to RDS data. Especially in the remaining years before the SSAD is available to these good actors, ICANN must leverage its controllership to increase its ARS work, not abdicate its responsibility under the false pretense of inability to obtain publicly available data.

Support intent of recommendation with edits

The IPC believes that the proposed recommendation has been wrongly gutted of important wording geared towards combating DNS abuse. Previously, the EPDP expressed a notably and significantly stronger placeholder version of Purpose 2: “Contributing to the maintenance of the security, stability, and resiliency of the Domain Name System in accordance with ICANN’s mission through enabling responses to lawful data disclosure requests.” The current recommendation is lacking the specificity we would like to see about how this SSR mission is carried out. The IPC believes greater specificity is important in that it highlights the importance of efficient and effective responses to disclosure requests in the fight to prevent abuses of the DNS. Furthermore, because this deleted language speaks directly to ICANN’s responsibilities and mission, the IPC believes the initial language is appropriate and should be re-incorporated into the proposed Purpose 2.

No, I wish to continue to the next section

Centralization

As a matter of priority, the IPC reiterates the need for disclosure decisions to be made centrally, either by ICANN or its designee, and automated to the greatest extent possible. The IPC echoes the European Commission’s support for “the centralisation and automation of the access and disclosure model to the extent that this is technically and legally feasible, as a way to ensure maximum efficiency of the model and legal certainty for the registrants, the disclosing entities and the access seekers.” (https://www.europarl.europa.eu/doceo/document/E-9-2020-000826-ASW_EN.html#def1)

The ICANN community has tried the decentralized approach to WHOIS data requests, and it has proven to be a failure. MarkMonitor, a leading online brand protection company and ICANN-accredited registrar, analyzed registrar responses to over 1,000 requests for redacted WHOIS data spread over the nine-month period following the implementation of the Temporary Specification. The requests pertained to 15 different global brands based in Europe and North America, and were manually reviewed and confirmed to be infringing by professional brand protection analysts before being sent to over 50 different contracted parties. A mere 14 percent of requests resulted in receipt of the data, with most being ignored or denied with auto-responses indicating that no review would actually happen. Cybersecurity, law enforcement, and ironically a DPA’s own request for WHOIS data in furtherance of an investigation have been met with similar systemic failure.

The Phase 2 policy does not yet adequately address concerns that there will be little to no improvement in an SSAD functioning merely as a ticketing system leading to more of the same.

Helpfully, recent inputs to the EPDP should help steer the EPDP back on track to a centralized decision making model. The IPC notes that the only rationale to depart from the centralized model that was being considered through December was a misinterpretation of a letter from the Belgian DPA, which was clarified to indicate the DPA’s preference for the centralized approach, calling it ‘a better “common sense” option in terms of security and for data subjects.’ (https://www.icann.org/news/blog/icann-meets-with-belgian-data-protection-authority) Recent legal advice from Bird & Bird confirms that centralized decision making also “offers least risk of liability to CPs.” (Contracted Parties) (https://community.icann.org/display/EOTSFGRD/EPDP+-P2+Legal+subteam?preview=/111388744/132941802/ICANN_Automation%20memo%2023%20April%202020%5B1%5D.pdf)

Automation

The IPC cautions that mixed use of the terms automation and centralization may be distracting or complicating the EPDP team’s work. Distinct from centralization (who makes the decision) is the concept of whether requests can be automated by the Central Gateway Manager. From the Contracted Parties’ perspective in providing the data the concept is the same in either scenario, but the EPDP team should take care to use the proper terminology for the intended scenario. While the recent Bird & Bird memo cautions that automating SSAD decisions might invoke Article 22 of the GDPR in some cases, the IPC notes that centralization in these cases is still very much possible and is the IPC’s preference.

The IPC also urges ICANN and the EPDP to consider the impacts of the concept of proximate cause on any Article 22 analysis. As Bird & Bird confirmed, the only legal literature on point confirms that there is a distinction to be made between processing which has a legal or similarly significant effect (which the SSAD sua sponte is incapable of producing), and processing which might lead to another party’s intervening act which causes a legal or similarly significant effect.

Section 4.2 of Appendix A

The EPDP has overlooked Section 4.2 of Appendix A of the Temporary Specification, which states that:

4.2. Notwithstanding Section 4.1 of this Appendix, Registrar and Registry Operator MUST provide reasonable access to Personal Data in Registration Data to a third party where the Article 29 Working Party/European Data Protection Board, court order of a relevant court of competent jurisdiction concerning the GDPR, applicable legislation or regulation has provided guidance that the provision of specified non-public elements of Registration Data to a specified class of third party for a specified purpose is lawful. Registrar and Registry Operator MUST provide such reasonable access within 90 days of the date ICANN publishes any such guidance, unless legal requirements otherwise demand an earlier implementation.

This provision is necessary to ensure that the new policy adjusts automatically in situations where legal clarity under GDPR or other applicable law is received after the EPDP concludes its work.

The IPC appreciates the EPDP Team’s efforts involved in addressing the important set of issues before them. The IPC recognizes the difficulty of the EPDP Team’s task, which requires them to work through complex issues that are subject to differing interpretations, both under the law and from the perspectives of various internet community members.

The IPC would like to echo support of the GAC comments filed on the Phase 2 Initial Report Addendum.

The IPC similarly remains frustrated at the lack of progress on certain items that the EPDP Team was tasked with addressing. Many important issues that were deferred in Phase 1 to be addressed in Phase 2 have yet again been deferred to some later, unknown date.

To start, reasonable application of GDPR’s provisions continues to frustrate the interests of many stakeholders. For example, distinguishing between legal persons and natural persons should have been resolved in line with the clear exception of legal persons from GDPR. As has been noted herein, legal opinions provided by relevant bodies, including the law firm, Bird & Bird, confirm that over-application of GDPR to cover legal persons is neither appropriate nor based on sound legal reasoning. Instead, the unnecessary delay ensures that no meaningful resolution can be reached in a timely manner, despite the assurances provided in Phase 1.

The IPC continues to stress that the GDPR has specific jurisdictional limitations such that its regulations should only apply where there is an actual nexus to the E.U. per the meaning of GDPR Article 3. It is an overextension of the GDPR to apply its provisions to cover legal persons, which is inconsistent with and not required by the GDPR. Similarly, it is an overextension to apply the GDPR’s provisions to any data that is beyond the specific territorial jurisdiction of the regulations. These overextensions come with significant harmful consequences—it makes it easier for bad actors to engage in DNS abuse, and harder for the good actors in the community to protect themselves and their rights. There are limitations to the GDPR, and it is important that these limitations be recognized by the data controllers and processors who are in a position to hold back, or preferably publish, as much accurate domain name registration data as is legally permissible. Legitimate access to accurate data is critical to serving the public interest, including for purposes of law enforcement, cybersecurity, intellectual property enforcement and consumer protection, and more.

In line with the failure to honor commitments made in Phase 1, the GNSO Council’s decision to remove data accuracy from the scope of the EPDP in Phase 2 will be damaging to confidence in the multi-stake holder model. The IPC believes that the EPDP team is capable of resolving complex issues, including issues concerning the relationship of publication of fictitious data and GDPR. To hold otherwise would not engender confidence in the policy-making process.

Lastly, the IPC voices its frustration at the unreasonable suspension of the PPSAI Consensus Policy implementation. PPSAI is Consensus Policy that was adopted in 2016, yet the de facto suspension since 2018 reflects a lack of urgency despite more than 25% of all domains using privacy/proxy services. The IPC believes the delay continues to aid bad actors committing abuse, including facilitating phishing and hacking attacks, IP infringement, sex and child trafficking, among other forms of abuse. It is unremarkable and indisputable that cybercriminals hide their identities behind privacy/proxy services. Without proper guidance that PPASI was intended to provide, many privacy/proxy services obfuscate, or even flat-out refuse, access to underlying registrant data in response to legitimate data requests, despite the time-sensitive nature of such cybercrimes.
While IPC recognizes that there is a subset of overlapping issues in reference to EPDP and PPSAI, there is no justification for stalling the overwhelming majority of remaining PPSAI policy recommendations. This is especially important given that any oversight will be lost if registrars transfer domain registrations to privacy/proxy services, which appears to be occurring. Accordingly, the IPC calls on the EPDP team to unequivocally recommend that PPSAI policy implementation resume at once.

No, I would like to continue to the next section

Support Recommendation as written

Support Conclusion as written

This issue was sufficiently addressed in Point 1 of Recommendation 17 of EPDP Phase 1. We should affirm that Recommendation, no further work is needed. That said, since not all parties came to consensus on how to handle this topic, we agree that the correct next step is to consult with the GNSO Council; we trust that the Council will uphold the determination of EPDP Phase 1 to permit but not require differentiation by person type.

Support Conclusion as written

Significant change required: changing intent and wording

The RrSG notes that any processing of personal data will always be subject to relevant data protection laws. Data elements required for the purpose of TDRP must be retained, and must only be used for the specified purpose. The section of this Recommendation beginning with “For clarity” should be removed entirely.

Support Conclusion as written

The RrSG notes that any processing of personal data will always be subject to relevant data protection laws.

Support Recommendation as written

Significant change required: changing intent and wording

From the RrSG’s perspective, the accuracy issue was never in-scope for the EPDP and we disagree it should be dealt with by the EPDP on extended timeline or otherwise.

It is crystal clear from the Charter that the EPDP has a very specific and narrow scope, namely, to ensure the new registration data policy (based on the Temporary Specification) is compliant with GDPR and other privacy laws. The EPDP was not about more accurate data for access purposes or for combating abuse.

As catalogued in the Bird & Bird memo (https://community.icann.org/download/attachments/102138857/ICANN - Memo on Accuracy.docx?version=1&modificationDate=1550152014000&api=v2), we are of the view that the existing contractual obligations regarding accuracy are sufficient. Indeed, we believe an accuracy scoping team would be duplicative of these existing efforts and long-standing accomplishments

Any new initiative to review non-public data requires a sufficient legal justification, and without one is not permissible under GDPR and other privacy legislation. No legal basis or any significant need for such a review has yet been demonstrated.

Additionally, before dedicating substantial resources to a policy initiative, the goal of such a policy initiative should be determined. It is not clear that complete accuracy of RDS data is possible, nor whether improved accuracy will result in any benefits (e.g. reducing DNS abuse), but if there are benefits or goals of increased RDS data accuracy they should be clearly documented prior to any policy undertakings.

As such, no further work on Accuracy is required, and the Conclusion should be modified to indicate that.

Support recommendation as written

The RrSG notes that any processing of personal data will always be subject to relevant data protection laws.

No, I wish to continue to the next section

MarkMonitor, part of Clarivate

No, I would like to continue to the next section

Support Recommendation intent with wording change

MarkMonitor supports this Preliminary Recommendation. The last sentence would benefit from greater clarity, without losing meaning, if worded, “As defined by the PPSAI Policy, the full privacy/proxy RDDS data will include an email address, and this email address may be pseudonymized.”

Significant change required: changing intent and wording

MarkMonitor is disappointed that the EPDP has not yet made constructive progress on this important topic. As a simple observation in the midst of policy complexities, GDPR does not apply to legal persons, so there is no rationale grounded in law for Contracted Parties to conceal RDS data of registrants who are legal persons. MarkMonitor is sympathetic to Contracted Party concerns about risks associated with relying on registrants’ self-selection of “personhood”, and we note that the concept might initially be confusing to some registrants as well. However, the EPDP has received very helpful guidance from Bird & Bird on constructive ways to make this clear to registrants, and MarkMonitor suggests that the EPDP take this advice into consideration while moving ahead constructively on this topic.

Support Conclusion as written

As noted in the IPC comment, the city field has significant utility for RDS data users, and the privacy risk to data subjects seems to be de minimis, so a balancing of the equities seems to indicate that it should be published. However, MarkMonitor is aware that the EPDP team has recently received legal advice that the city field can be disclosed upon request in an automated fashion, which might strike the balance needed.

Significant change required: changing intent and wording

MarkMonitor agrees that a data retention period of “life of the domain, plus 18 months” is appropriate. We agree with the wisdom of grounding the retention period in an existing policy in order to meet the GDPR’s purpose limitation principle. In doing so here, however, the language incorrectly or unwisely limits the retention to “only those data elements deemed necessary for the purposes of the TDRP.” This language unnecessarily limits retention to this precise purpose, and would be better stated, “registrars be required to retain all data elements collected, including those data elements deemed necessary for the purposes of the TDRP, among other purposes compatible with the purposes for which the data was collected…”

Support Conclusion intent with wording change

MarkMonitor agrees with this conclusion, and we note that this conclusion depends on the characterization of ICANN’s OCTO work being done under the recently-agreed “Purpose 2”, which notes that the data is collected for the security, stability, and resilience of the DNS.

Significant change required: changing intent and wording

MarkMonitor notes the increased need to correlate domain names belonging to the same bad actors, especially now with the expected diminishing utility of commercial providers of “reverse WHOIS” services. While the law seems to indicate that even pseudonymized email addresses would be considered “personal data” for GDPR purposes, we suggest that because the need to correlate domains persists and grows, the EPDP team consider whether other forms of anonymized or pseudonymized identifiers would be legally sound and technically possible.

Significant change required: changing intent and wording

MarkMonitor notes that regrettably the GNSO Council has removed the concept of accuracy from the EPDP’s scope. MarkMonitor is disappointed in this decision and echoes comments submitted by the GAC that “accuracy of domain name registration data is fundamental to both the GDPR and the goal of maintaining a secure and resilient DNS.”
MarkMonitor also calls for ICANN to resume performance of its important Accuracy Reporting System (ARS) work. To correct the record on ICANN’s June 21, 2019 letter to GNSO Council, ICANN performs its ARS work because it is a data controller monitoring compliance with its contracts, not because the data was conveniently public. GDPR notwithstanding, ICANN remains a data controller with responsibility for the security, stability, and resilience of the DNS, including “maintenance of and access to accurate and up-to-date information concerning registered names.” (ICANN Bylaws, Annex G-1 and G-2). As a controller, ICANN does not need the data to be public to do its ARS work. Rather, MarkMonitor calls for ICANN to obtain the data needed to continue this important work.

No, I wish to continue to the next section

Support recommendation as written

While MarkMonitor would prefer to include greater specificity around the types of security, stability, and resiliency purposes for which RDS data is collected (e.g. law enforcement, cybersecurity, and intellectual property purposes), we understand that this language is intended to capture these third-party purposes, while representing a compromise between groups with different views on this purpose. Therefore, while we do have a preference for greater specificity, we do not oppose the compromised language as reflected here.

No, I wish to continue to the next section

These comments are submitted on behalf of the Global Brand Owner and Consumer Protection Coalition (GBOC). GBOC is an organization of global industry-leading businesses and brand owners working together to address common concerns in the online consumer and brand protection space. Members of GBOC represent leaders in software and technology, consumer goods, hospitality, and apparel, among other sectors.

No, I would like to continue to the next section

Support Recommendation intent with wording change

The last sentence stating that “the full privacy/proxy RDDS data may include a pseudonymized email” should be revised to say that “The full privacy/proxy RDDS data shall either include a pseudonymized registrant ID code or pseudonymized email.” This will permit the ability to correlate other domain names registered by the same P/P service customer through the P/P service provider, without compromising the privacy of the customer unless or until the customer’s identity is disclosed in accordance with one of the legal justifications under GDPR or other applicable data protection laws. See also our comments regarding “Preliminary Conclusion: Feasibility of unique contacts to have a uniform anonymized email address.”

Significant change required: changing intent and wording

This is a serious dereliction of the EPDP’s duty to provide a recommendation on this issue. It is clear that GDPR does not apply to legal person data. The distinction must be made in the context of RDS policy. All non-personal data, including that of legal persons, must be published in RDDS.

Some are concerned that individuals acting on behalf of a legal entity could have their data published in RDDS, and therefore it is necessary to apply data redaction regardless of registrant type. However, any individual acting on behalf of a legal entity registrant could either consent to the publication of their personal data in connection with the registration on the entity’s behalf, or, preferably, provide generic contact information that does not identify a specific individual contact acting for the entity (e.g. “Domain Administrator” as the RNH “name”, and “admin@domain.com” as the RNH email). The EDPB does not consider the publication of such data in the context of RDDS to be unlawful as noted in their July 5, 2018 letter to ICANN, and such practice is not prohibited by ICANN requirements so long as the information is otherwise accurate (enables identification and contact of the legal entity).

It should not be unduly burdensome for registrars to require that all prospective registrants identify if the registration is being made on behalf of a legal entity, and if so, to require the registrant to only provide non-personal data to complete the data fields (e.g. Domain Administrator), the full organization name, the physical address only for the legal entity, and a generic email address rather than that of a specific individual. Thus, the responsibility is on the registrant and should insulate the registrar from liability for any inadvertent publication of personal data, which can be corrected at the direction of the registrant if later discovered.

We urge the EPDP to recommend limiting the application of redacted data fields only to personal data of natural persons.

Significant change required: changing intent and wording

The justification given regarding universal redaction of the city field appears to be overcome by the rationales given for publication to support the legitimate interests of third parties, including rights holders, in having public access to this data element. The database of .eu domains publishes the "city" field, as do other European ccTLDs (e.g. .be). In light of the publication among many European ccTLDs and the lack of GDPR-related consequences, it appears obvious that publication of the city field is permissible. Accordingly, in keeping with the stated ICANN goal of publishing the most RDDS data possible, while still complying with the law, it appears that the city field can legally be published, and therefore the EPDP should modify its recommendation to require publication of the city field in RDDS.

Support Recommendation intent with wording change

We believe this recommendation wrongly limits the retention periods, by requiring 18 months retention of only the data elements deemed necessary for purposes of the TDRP, and merely making permissible longer data retention periods if the registries or registrars choose to do so. Brand owners and other third-party requestors often have legitimate need to obtain historical data in order to protect their interests, and is it important that data be available to them when needed, which can only be ensured if registries and registrars are required to retain all data for the full required retention period, and not only the elements relevant to the TDRP. We suggest the recommendation be revised to remove this limitation.

Support Conclusion as written

Significant change required: changing intent and wording

We respect the legal analysis provided by Bird & Bird finding that even pseudonymized email addresses would be considered personal data and therefore must not be published as such in RDDS. However, some kind of identifier is necessary to assess patterns of multiple malicious or abusive domain name registrations associated with the same registrant (i.e. to correlate various domain names to the same registrant, even if the identity of that registrant is unknown).

Based on our reading of the Bird & Bird analysis, if a unique code were used for assessing patterns, rather than an email address that could also be used to contact the data subject, it would not be considered personal data. We would suggest revising this recommendation accordingly, i.e. by recommending instead that all public RDDS records provide a pseudonymized code (as a new data element or reviving the once-used Registrant ID field) to enable cross-registration correlation without revealing personal data.

Significant change required: changing intent and wording

Again, we believe it is a dereliction of the EPDP’s duty to not provide recommendations regarding data accuracy requirements, per its charter and the EPDP Phase 1 final recommendations which deferred further discussion on accuracy to Phase 2. As the vast majority of data elements have been redacted from public view, it is more essential than ever to ensure that the data is accurate. If SSAD provides access to non-public data, and such data is found to be inaccurate, disclosure is effectively meaningless and a waste of time. ICANN and Contracted Parties must be held to the highest possible standard in ensuring registration data they collect is accurate; this means proper adherence to existing data verification and validation requirements under the RAA, and ICANN compliance enforcement of same. However, there may need to be additional requirements to ensure data accuracy if these measures do not go far enough to ensure high quality data throughout the system. Accuracy is also a key principle under the GPDR (see GDPR Art. 5), so failure to ensure adequate accuracy is itself a potential violation of GDPR, considering the purposes for which the data is processed – which includes all of the Purposes identified by the EPDP, including for ICANN SSR and related third-party purposes (e.g. legitimate interests like law enforcement, cybersecurity, IP enforcement and consumer protection). The ARS also must be updated to account for the ability to provide and review complaints from third-parties based on disclosed but inaccurate data, and to enable direct access by ICANN to review/audit the accuracy of data on its own initiative.

No, I wish to continue to the next section

Support intent of recommendation with edits

We support a variation of an earlier formulation of Purpose 2, namely: “Contributing to the maintenance of the security, stability, and resiliency of the Domain Name System in accordance with ICANN’s mission, including through lawful data disclosure to ICANN and third parties with a legitimate interest in such data.”

No, I wish to continue to the next section

GBOC appreciates the work and dedication of the EPDP team, and recognizes that the issues the EPDP team is addressing are multi-faceted, complex, and subject to varying reasonable interpretations in terms of what is required under law and what is needed by the various members of the Internet community. That said, there are several key areas where the contours of GDPR are clear, and where the EPDP should refine the Registration Data Policy accordingly. First, as discussed in greater detail above, we continue to be greatly concerned by the EPDP’s failure to recommend distinguishing between legal persons and natural persons, which is a clear and unequivocal distinction drawn in the GDPR itself. In a similar vein, the GDPR has specific jurisdictional limitations, and should apply to registration data only where there is an actual nexus to the European Union within the meaning of GPDR Article 3. Again, the EPDP team has failed to recommend this distinction as part of further amendments to refine the Registration Data Policy. Accuracy is another key component of the GDPR itself, but the EPDP has recommended passing off further work on data accuracy to a “GNSO scoping team”. This is another unfortunate abandonment of the EPDP’s duty to craft an actual policy recommendation concerning data accuracy requirements and reporting/compliance, as discussed above. The EPDP must reach meaningful recommendations on these matters, and prioritize actual adherence to the GDPR’s requirements and DNS security over what is expedient for contracted parties. We urge the EPDP team to revise its recommendations and conclusions as suggested in these comments.

Registries Stakeholder Group (RySG)

No, I would like to continue to the next section

Support Recommendation as written

Significant change required: changing intent and wording

This preliminary conclusion should be updated to reflect the current status of these deliberations with the GNSO.

The RySG’s view is that the issue of redaction of legal vs. natural person data has been thoroughly considered and determined by the EPDP. The RySG membership consists of dozens of registry operators with distinct business models, including some that exclusively serve registrant bases that are organizations or legal persons, and others that serve a broader registrant base. The RySG supported the Phase 1 recommendation to allow registries and registrars the flexibility to differentiate between legal and natural persons in the public RDS output, without establishing that differentiation as a requirement, because it met the needs of its members.

Given the prior deliberations on this topic within Phase 1 of the EPDP, and the conclusion that the Team reached, the RySG believes that this is not a topic where the Team will benefit from additional discussion or consideration of the issue. The EPDP determined in Phase 1 Rec 17 that Contracted Parties are “permitted to differentiate between registrations of legal and natural persons, but are not obligated to do so.” We do not disagree that GDPR does not require the redaction of legal person data, but as a policy matter it is not feasible for all contracted partie to reliably differentiate between legal and natural person registrants. Moreover, in some instances even legal person registrations may contain natural person data in some fields (e.g. contact data for a natural person).

While some have proposed registrant self-identification and consent from natural persons for the publication of their data in a legal person registration as a solution to publishing legal person data, the legal advice received on this issue from Bird & Bird demonstrates that both approaches create significant risks of liability for Contracted Parties.

We note that one RySG member, the National Association of Boards of Pharmacy (NABP, operator of the .PHARMACY gTLD) opposes this position on the grounds that transparency of contact information for legal persons promotes public safety.

Support Conclusion as written

Support Recommendation intent with wording change

For clarity, this does not prevent the identification of additional retention periods for stated purposes by the controllers, as identified and as established by the controllers, for purposes other than TDRP; This does not exclude the potential disclosure of such retained data to any party, subject to relevant data protection laws.

Support Conclusion as written

Support Recommendation intent with wording change

Propose changing “not currently feasible under the GDPR” to “not currently permissible under the GDPR” to more accurately reflect that this is a legal restriction on the publication of this data.

Support Conclusion as written

No, I wish to continue to the next section

Support recommendation as written

No, I wish to continue to the next section

No, I would like to continue to the next section

Significant change required: changing intent and wording

We would recommend that all domain registration are treated the same (whether registered via proxy providers or otherwise) and with respect to the following rights:

i. Right to ensure that data is stored and processed lawfully (on the basis of consent or some other lawful basis laid down by law),fairly and securely;
ii. Right to know what personal data is held about them by controllers (right of access) and for what purpose;
iii. Right to seek to correct that data when it is inaccurate (right of rectification);
iv. Right to demand that data be deleted when it is no longer necessary for the permitted purpose, when it is irrelevant or out-of-date, when consent has been withdrawn and there is no other lawful basis, when the data has been unlawfully processed, or when it has been made public without justification (right to erasure);
v. Right to receive one’s personal data from a data controller for the purpose of changing a service (data portability); and
vi. Right to object to the processing of data for particular purposes, including for direct marketing and profiling, where certain conditions apply (right to object).

Support Conclusion as written

We support the multi-stakeholder consultations within ICANN community in order to resolve the divergence of opinion.

Support Conclusion as written

Significant change required: changing intent and wording

We recommend removal of the term, "For the avoidance of doubt, this retention period does not restrict the ability of registries and registrars to retain data elements for longer periods. " as it is vague and with no timelines.

Support Conclusion intent with wording change

We support the recommendation and request for wording change to reflect that OCTO would act in consultation with ICANN community members.

Support Recommendation as written

Support Conclusion as written

No, I wish to continue to the next section

Support recommendation as written

No, I wish to continue to the next section

We recommend that EPDP recommendations under the Global Principles on Protection of Freedom of Expression and Privacy which can be found here:- http://article19.shorthand.com/

Staff submission of ALAC response.

No, I would like to continue to the next section

Support Recommendation intent with wording change

Since all domains registered via accredited privacy/proxy services providers will be labeled as such in the domain registration data, the ALAC fully supports the recommendation. Should the domain registration be done via accredited privacy-proxy provider the data must not be redacted.

The ALAC notes that in the recommendation and the text, there are multiple references to “data associated with a natural person”. In fact a privacy/proxy registration may mask the data of ANY registrant, whether natural or legal person. As the recommendation stands, it might be construed that masking of the p/p service RDDS data would be allowed if the underlying registrant is a legal person, and that was not what was intended.

The ALAC also notes that Privacy & Proxy Services Accreditation Issue (PPSAI) PDP implementation has been halted pending the EPDP outcomes. The EPDP has determined that there is no need for the PPSAI implementation to be halted. The PPSAI PDP started in 2013 and the recommendations were approved by the Board in 2016. The implementation MUST be completed with haste and the EPDP must make a clear recommendation to that effect.

Significant change required: changing intent and wording

On April 9th, the EPDP team received legal advice from Bird & Bird that includes information relevant to some concerns related to the differentiation between legal and natural persons’ registration data. In response to the concern that registrants might wrongfully self-identify themselves the legal advice says independent verification measures that would identify mis-labelled registrants would be considered a reasonable accuracy measure. In addition, Bird & Bird had previously provided other measures that could be taken to address this issue. Previous memos have addressed concerns related to the data of the legal persons including personal information of natural persons. In addition, concerns related to the practicality and costs associated with the differentiation are currently being addressed through a survey conducted by ICANN org. The survey addresses the feasibility and costs, examples of industries that have successfully implemented the differentiation between legal and natural persons’ registration data and the various risks associated with the differentiation, the result of the survey should be available in May. Taking into account:

● The interest of the Internet end-users and their right to be able to confirm the legitimacy of websites registered by legal persons.
● Burdening the system with unnecessary requests and thus leading to an inefficient system for access/disclosure of non-publicly available registration data.
● Wasting the information that we currently have and the other that would be available through the survey by not acting upon it.

The ALAC believes potential next steps are feasible at the current stage if the will exists.
For avoidance of doubt, the ALAC does not agree to return the issue to the GNSO for possible action (or inaction) at some unknown future date.

The ALAC understands that differentiation may be difficult for existing registrations and that some time may be needed to fully implement differentiation, but that is not a reason to not immediately do so for new registrations and to begin the process of adjusting existing registrations.

Support Conclusion as written

The ALAC supports the recommendations.

Support Recommendation as written

The ALAC supports the recommendations.

Support Conclusion as written

In light of preliminary recommendation number 22, purpose two, the ALAC supports not adding a purpose in relation to ICANN’s Office of the Chief Technology Officer. We believe that ICANN purpose number two would cover such a purpose for OCTO when required.

Significant change required: changing intent and wording

The ALAC cannot support the rejection of anonymized email addresses. The Bird & Bird memo clearly equates “masking” of email addresses with “the data controller hands over part of this dataset”. The form of anonymization that the EPDP has considered does not include providing ANY PART of the original address and thus the term “masking” is entirely inappropriate.

The ALAC can see no way in which a party other that the Registrar who created the anonymization could associate the new address with the registrant. Moreover, saying that the anonymized address allows contact and is thus personal information implies the same thing for a Web Link which also allows contact.

The ALAC particularly notes that Item 9 of the Bird & Bird memo gives significant benefits to using an anonymized address.

Lastly, if the EPDP were to not allow anonymized email addresses to be published, then the ALAC believes that the EPDP has an obligation to recommend options for what IS legitimately allowed to ensure registrant contactability.

Significant change required: changing intent and wording

In light of the current information, provided by Bird & Bird in relation to the accuracy of the registration data, the ALAC is of the view that a recommendation with regard to accuracy is possible at this stage and that such a recommendation would either definitively address the issue or, at worst, would help and inform the GNSO scoping team. To that end, the ALAC does not support the recommendation. The EPDP Phase 1 Report committed that this issue would be covered, and that commitment was an essential component of the ALAC supporting that report.

The ALAC notes that the RDS-WHOIS2 Specific Review made a strong recommendation that resumed operation of the Accuracy Reporting System or something comparable is essential given the high rate of inaccuracy observed on pre-GDPR WHOIS data and the fact that the EPDP Phase 1 recommendation significantly reduced the number of possible contact points, increasing the potential for uncontactability. The SSR2 Specific Review makes a comparable recommendation in its draft report.

No, I wish to continue to the next section

Support recommendation as written

In light of the EDPB letter and ICANN board recommendation in relation to this ICANN purpose, the ALAC fully supports adding the stated purpose to the ICANN purposes for processing gTLD registration data mentioned in recommendation one of the EPDP phase one final report.

No, I wish to continue to the next section

N/A - will copy entirety of ALAC statement below.

ALAC Statement on Addendum to the Initial Report of the Expedited Policy Development Process (EPDP) on the Temporary Specification for gTLD Registration Data Team - Phase 2

The ALAC thanks ICANN for putting forward the EPDP phase two addendum to the initial report of the gTLD registration data for public comment and takes this opportunity to provide its comments herein.

Preliminary recommendation #20 Display of Information of affiliated vs. accredited privacy/proxy providers

Since all domains registered via accredited privacy/proxy services providers will be labeled as such in the domain registration data, the ALAC fully supports the recommendation. Should the domain registration be done via accredited privacy-proxy provider the data must not be redacted.

The ALAC notes that in the recommendation and the text, there are multiple references to “data associated with a natural person”. In fact a privacy/proxy registration may mask the data of ANY registrant, whether natural or legal person. As the recommendation stands, it might be construed that masking of the p/p service RDDS data would be allowed if the underlying registrant is a legal person, and that was not what was intended.

The ALAC also notes that Privacy & Proxy Services Accreditation Issue (PPSAI) PDP implementation has been halted pending the EPDP outcomes. The EPDP has determined that there is no need for the PPSAI implementation to be halted. The PPSAI PDP started in 2013 and the recommendations were approved by the Board in 2016. The implementation MUST be completed with haste and the EPDP must make a clear recommendation to that effect.

Preliminary Conclusion – Legal vs. Natural Persons

On April 9th, the EPDP team received legal advice from Bird & Bird that includes information relevant to some concerns related to the differentiation between legal and natural persons’ registration data. In response to the concern that registrants might wrongfully self-identify themselves the legal advice says independent verification measures that would identify mis-labelled registrants would be considered a reasonable accuracy measure. In addition, Bird & Bird had previously provided other measures that could be taken to address this issue. Previous memos have addressed concerns related to the data of the legal persons including personal information of natural persons. In addition, concerns related to the practicality and costs associated with the differentiation are currently being addressed through a survey conducted by ICANN org. The survey addresses the feasibility and costs, examples of industries that have successfully implemented the differentiation between legal and natural persons’ registration data and the various risks associated with the differentiation, the result of the survey should be available in May. Taking into account:

● The interest of the Internet end-users and their right to be able to confirm the legitimacy of websites registered by legal persons.
● Burdening the system with unnecessary requests and thus leading to an inefficient system for access/disclosure of non-publicly available registration data.
● Wasting the information that we currently have and the other that would be available through the survey by not acting upon it.

The ALAC believes potential next steps are feasible at the current stage if the will exists.
For avoidance of doubt, the ALAC does not agree to return the issue to the GNSO for possible action (or inaction) at some unknown future date.

The ALAC understands that differentiation may be difficult for existing registrations and that some time may be needed to fully implement differentiation, but that is not a reason to not immediately do so for new registrations and to begin the process of adjusting existing registrations.

Preliminary Conclusion – City Field Redaction and Preliminary Recommendation #21. Data Retention

The ALAC supports the recommendations.

Preliminary Conclusion – OCTO Purpose

In light of preliminary recommendation number 22, purpose two, the ALAC supports not adding a purpose in relation to ICANN’s Office of the Chief Technology Officer. We believe that ICANN purpose number two would cover such a purpose for OCTO when required.

Preliminary Conclusion - Feasibility of unique contacts to have a uniform anonymized email address

The ALAC cannot support the rejection of anonymized email addresses. The Bird & Bird memo clearly equates “masking” of email addresses with “the data controller hands over part of this dataset”. The form of anonymization that the EPDP has considered does not include providing ANY PART of the original address and thus the term “masking” is entirely inappropriate.

The ALAC can see no way in which a party other that the Registrar who created the anonymization could associate the new address with the registrant. Moreover, saying that the anonymized address allows contact and is thus personal information implies the same thing for a Web Link which also allows contact.

The ALAC particularly notes that Item 9 of the Bird & Bird memo gives significant benefits to using an anonymized address.

Lastly, if the EPDP were to not allow anonymized email addresses to be published, then the ALAC believes that the EPDP has an obligation to recommend options for what IS legitimately allowed to ensure registrant contactability.

Preliminary Conclusion – Accuracy and Whois Accuracy Reporting System

In light of the current information, provided by Bird & Bird in relation to the accuracy of the registration data, the ALAC is of the view that a recommendation with regard to accuracy is possible at this stage and that such a recommendation would either definitively address the issue or, at worst, would help and inform the GNSO scoping team. To that end, the ALAC does not support the recommendation. The EPDP Phase 1 Report committed that this issue would be covered, and that commitment was an essential component of the ALAC supporting that report.

The ALAC notes that the RDS-WHOIS2 Specific Review made a strong recommendation that resumed operation of the Accuracy Reporting System or something comparable is essential given the high rate of inaccuracy observed on pre-GDPR WHOIS data and the fact that the EPDP Phase 1 recommendation significantly reduced the number of possible contact points, increasing the potential for uncontactability. The SSR2 Specific Review makes a comparable recommendation in its draft report.

Preliminary Recommendation #22. Purpose 2

In light of the EDPB letter and ICANN board recommendation in relation to this ICANN purpose, the ALAC fully supports adding the stated purpose to the ICANN purposes for processing gTLD registration data mentioned in recommendation one of the EPDP phase one final report.

No, I would like to continue to the next section

ICANN org would like to thank the EPDP team for its thoughtful and dedicated work in producing this report. ICANN org hopes the comments it is providing in this form are helpful to the team as it discusses community input and finalizes its recommendations.

ICANN org understands Registrars and Registries must continue to publish information of any affiliated privacy/proxy provider (pursuant to recommendation 14 of the EPDP Phase 1 report) until PPSAI is implemented. Can the EPDP confirm this understanding is correct?

The recommendation also states that “where data associated with a natural person is masked, Registrar (and Registry, where applicable) MUST include the full RDDS data of the accredited privacy/proxy service ..” yet the recommendation does not address how a Registry is meant to know the difference between a domain that is a privacy/proxy registration versus other registration data that is currently redacted per ICANN policy.

As recognized in the PPSAI Final Recommendations, “Privacy Services” are a service “by which a Registered Name is registered to its beneficial user as the Registered Name Holder, but for which alternative, reliable contact information is provided by the privacy or proxy service provider for display of the Registered Name Holder's contact information in the Registration Data Service (WHOIS) or equivalent services.” Thus, for registrations protected by Privacy Services, the full name of the “beneficial user,” who may be a natural person, is listed in the “Registrant Name” field. This seems inconsistent with the EPDP’s recommendations regarding redacting natural persons’ names. Is the intent of the proposed requirement to require that the Registrant Name field (which may include a natural person’s name) MUST be displayed for registrations protected by accredited proxy services and accredited privacy services, or just proxy services?

More fundamentally, ICANN org notes that the work of the EPDP Team and the recommendations of the PPSAI Working Group concern many of the same issues: policies and procedures for access to and disclosure of non-public data concerning domain name registrants. Will the EPDP Team evaluate how its recommended SSAD (and, potentially, the requirements concerning lawful access from Phase 1) are intended to apply to domain name registrations covered by a proxy or privacy service? For example, has the EPDP Team considered that its recommendations could be circumvented simply by placing domain name registrations behind a privacy or proxy service? This situation could be addressed via a clear expression from the EPDP Team regarding how the PPSAI recommendations (which have no explicit requirements concerning the criteria or processes for disclosure of data) are to be impacted by the EPDP Team’s new, post-PPSAI recommendations concerning the disclosure of non-public data concerning registrants.

Implementation Note:
ICANN org suggests that the first section of implementation note 1 be removed to simply state, “This recommendation once in effect supersedes EPDP phase 1 recommendation 14.” Additionally, can the team clarify how this language is reconciled with the text preceding Recommendation #20, which states: “The EPDP Team noted that at the time of publication of this report, the implementation of the Privacy and Proxy Services Accreditation Issues (“PPSAI”) Working Group’s recommendations is on hold. Accordingly, the EPDP Team phase 2 working group confirms that Phase 1 Rec #14 remains in place.”

ICANN org has two comments on implementation guidance #2.
First, this guidance is written as a MUST NOT requirement. This may lead to confusion during implementation as guidance is not considered to be a part of the consensus policy recommendations. In order to ensure clarity in implementation, ICANN org suggests clarifying whether this language should be included as a policy requirement in the recommendation.
In addition, as noted above, the display of complete, unredacted name and contact information for a domain protected by a privacy service would display the registrant name, which may include personal data protected by the GDPR.

Implementation guidance #3 states that “note, this does not impact the EPDP Phase 1 policy recommendation in relation to “affiliated” privacy / proxy services.” This sentence seems to contradict the first implementation guidance which states that “ This recommendation once in effect replaces or otherwise supersedes EPDP phase 1 recommendation 14.” ICANN org understands that all affiliated privacy/proxy services have labeling requirements while accredited/unaffiliated privacy/proxy services do not have labeling requirements until PSSAI has been implemented. Could the EPDP team confirm if this understanding is correct ?

ICANN org notes that there is an existing recommendation on the differentiation between legal and natural persons, where Registrars and Registry Operators are permitted to differentiate between registrations of legal and natural persons, but are not obligated to do so. This is being implemented as part of the EPDP Phase 1 recommendations, and ICANN org understands that this will remain in place unless superseded by an EPDP Phase 2 or other consensus policy recommendation.

No, I wish to continue to the next section

No, I would like to continue to the next section

Significant change required: changing intent and wording

InfoNetworks agrees with the recommendation to publish the “full RDDS data of the accredited privacy/proxy service in response to an RDDS query.” However, we believe that the final recommendations for SSAD must also address data for the beneficial Registrant who registered the domain using the privacy/proxy service.

As aptly stated by ICANN on its website, “WHOIS isn't an acronym, though it may look like one. In fact, it is the system that asks the question, who is responsible for a domain name or an IP address?”

ICANN’s Advisory Statement for the Temporary Specification states that “the WHOIS system helps serve the public interest as it contributes to the security and stability of the Internet by providing contact information to support issues related to consumer protection, investigation of cybercrime, DNS abuse and intellectual property; as well as to address appropriate law enforcement needs.”

The Temporary Specification provides that ICANN’s objective is to comply with the GDPR, “while maintaining the existing WHOIS system to the greatest extent possible.” It is with that mandate that the EPDP was chartered “to determine if the Temporary Specification for gTLD Registration Data should become an ICANN Consensus Policy, as is or with modifications”.

As stated in the final report from the GNSO working group on privacy / proxy services in 2015, a Privacy Service is “a service by which a Registered Name is registered to its beneficial user...but for which alternative, reliable contact information is provided by the privacy or proxy service provider for display [in WHOIS].” Similarly, a Proxy Service is “a service through which a Registered Name Holder licenses use of a Registered Name to the privacy or proxy customer in order to provide the privacy or proxy customer use of the domain name, and the Registered Name Holder's contact information is displayed in the Registration Data Service (WHOIS).”

Even if a provider of a P/P service is legally responsible for the actions of their beneficial Registrant for a given domain, the identity of that beneficial Registrant may still be necessary to address criminal matters and other situations where the identity of the beneficial Registrant is needed (such as cybersecurity issues and certain activities that span multiple domains).

Thus, merely publishing anonymous contact information for a P/P service will not assist in any meaningful way with addressing the domain abuse issues for which the identity of the “responsible” party is required and the fundamental public interest in WHOIS.

The P/P working group itself was also keenly aware of this, noting in its 2015 report that “disclosure of at least some contact details of the customer may in some cases be required in order to facilitate such direct resolution” -- providing an illustrative disclosure framework for intellectual property disputes but expressly not addressing the needs of law enforcement.

If the EPDP does not address access to information regarding a beneficial Registrant using a P/P service (which information is not currently part of the registration data), then its entire body of work and recommendations for the SSAD process will be moot as to the growing portion of domain name registrations that use such services.

Significant change required: changing intent and wording

The failure of the EPDP to take a more holistic approach to WHOIS access (e.g. privacy/proxy, natural/legal, data accuracy) has significantly limited the benefits of its recommendations for the SSAD process. The GDPR presents a generational opportunity for ICANN to solve a more fundamental problem with WHOIS that has plagued the organization since its inception. However, instead of trying to solve that problem (which is also core to SSAD), the EPDP has simply designated these concerns as Priority 2 issues.

Nowhere is this more evident than in connection with the distinction between natural and legal persons. While there is no dispute that the GDPR provides no legal protection to legal persons, ICANN, the GNSO and the EPDP has reinforced an overly broad interpretation of the original Temporary Specification as well as the policy work of the original EPDP to extend protection to this data set. Initially, Registries and Registrars raised valid concerns about the potential cominguling of employee personal data in the domain name registration data of legal persons. However, Registrars could have used the intervening two years to correct this cominguling of data as part of their Annual Whois Data Reminder Policy notifications. Instead, there appears to be inaction by most of the contracting parties to address this issue.

There has been no shortage of legal opinions obtained by the EPDP discussing the distinction between natural and legal persons under the GDPR, yet the EPDP has failed to conduct even a cursory review of how many in the domain name community have actually made the distinction in their registration data. For example, over 70% of European ccTLDs make a distinction between natural and legal persons in their public registration data. Moreover, while some members of the EPDP sought to distinguish between ccTLD and gTLDs, it does not appear that any research was even done by ICANN.org to analyze how gTLDs themselves are addressing this problem.

In 2011, PuntCAT, the Registry Operator of the .CAT gTLD, in consultation with the Spanish DPA, submitted an RSEP (2011007) to ICANN that sought to alter the output of their public Registrant registration data. As part of their RSEP submission PuntCAT identified three Registrants classes: Legal Person; Natural Person (Commercial); Natural Person (Non-Commercial). Only Natural Persons engaged in non-commercial activity had their data withheld from publication. An additional relevant fact, PuntCAT activity monitors their zone file and will inform natural persons engaged in commercial activity that they need to change their designation.

Additionally, fTLD (the Registry Operator of the .BANK and .INSURANCE gTLDs) makes a natural/legal person distinction in connection with their registration processes. Specifically, only legal persons are permitted to register in .BANK, whereas either natural or legal persons are permitted to register in .INSURANCE. Similarly, NABP (the Registry Operator of the .PHARMACY gTLD) also prohibits the registration of domain names by natural persons.

In the case of .NYC, the New York City Department of Information Technology & Telecommunications has required its backend provider Neustar to implement a registration wrok flow that distinguishes between Individuals and Organizations. While some within the EPDP have tried to highlight the relevant small zone files of .BANK, .INSURANCE, and .PHARMACY (less than 10,000), this ignores the fact that .NYC has over 60,000 names and .CAT has over 100,000.

The importance of making this natural / legal person distinction becomes evident when you look at a breakdown of registration data for TLDs (both gTLD and ccTLDs) having this distinction: Norway (.NO) - 789,831 registrations (12% natural / 88% legal); Belgium (.BE) - 1.6 million registrations (30% natural / 70% legal); City of New York (.NYC) - 66,000 registrations (50% natural / 50% legal); PuntCAT (.CAT) - 108,000 (30% natural (protected) / 70% natural/legal (unprotected).

There is no question as to the ease with which Registries and Registrars can add a distinction between natural and legal persons and otherwise address any personal contact information in the registration data - as evidenced by various gTLDs and ccTLDs that have done it. Unfortunately, the EPDP failed to consider implementing this distinction, and instead have relied upon legal memos based on not making this distinction.

Support Conclusion intent with wording change

Further to our prior comments on the distinction between natural and legal persons, InfoNetworks believes the redaction of the city field is unduly conservative as to all natural persons. And, it is out of scope (and unnecessary) to redact this information for legal persons. Therefore, we propose that any redaction of city information only be in connection with natural persons engaged in non-commercial activities.

Support Recommendation as written

Support Conclusion as written

Support Recommendation intent with wording change

While Bird & Bird has provided a memo acknowledging the potential “privacy-enhancing technology (OPET) / privacy by design measure” benefit of this approach, it did not fully explore other potential options on how this system could be implemented. Additional research on how other Registration Authorities have implemented similar safeguards should be undertaken before declaring the use of a unique contact handle associated with a pseudonymized email address as the “publication of personal data.”

Conclusion should be deleted

Further to our prior comments, the EPDP should have taken a more holistic approach to Non-Public Registration Data access, including accuracy which is a critical piece of the overall solution.

No, I wish to continue to the next section

Support recommendation as written

No, I wish to continue to the next section

No, I would like to continue to the next section

Significant change required: changing intent and wording

Below is the relevant extract from the full GAC comment on the Addendum, available at: https://gac.icann.org/file-asset/public/gac-comment-epdp-addendum-5may20.pdf

----
Note: The GNSO’s Intellectual Property Constituency (IPC), Business Constituency (BC) and the At-Large Advisory Committee (ALAC) support the views expressed in this comment.

----
Recommendations Related to the Handling of Data Protected by Privacy/Proxy Service Providers Should be Implemented Without Delay

The EPDP team has developed recommendations concerning the treatment of domain name registration data protected by privacy/proxy service providers but noted that its recommendation must not be implemented until related PPSAI policy is implemented.[1] At the same time, the ICANN Org, with the support of the ICANN Board, has stalled implementation of the PPSAI recommendations.[2] Hence, there is a standoff.

The GAC has emphasized the importance of implementation of the Privacy Proxy Services Accreditation Issues (PPSAI) policy “given the impact of unregulated and unaccountable privacy proxy services on the stability and security of the DNS.”[3] While Privacy Proxy Services may serve legitimate purposes,[4] a U.K. study noted that a “significant percentage of the domain names used to conduct illegal or harmful Internet activities are registered via privacy or proxy services to obscure the perpetrator's identity.”[5]

At the least, there should not be unnecessary delays to implementing policies that support clear labeling of when privacy proxy services are in use and eliminate barriers to legitimately accessing such data. We recommend that the EPDP ask the Board to eliminate the current timing conundrum by permitting the PPSAI implementation to resume and thereby clearing the path to implementation of the EPDP team’s related privacy proxy recommendations.

[1] See Addendum to Initial Report of Phase 2 EPDP on gTLD Registration Data: https://gnso.icann.org/sites/default/files/file/field-file-attach/epdp-phase-2-addendum-26mar20-en.pdf.
[2] See ICANN org letter to the GNSO Council on 5 September 2019: https://www.icann.org/en/system/files/correspondence/namazi-to-drazek-et-al-05sep19-en.pdf and ICANN Board response to the GAC Montréal Communiqué: https://www.icann.org/en/system/files/files/resolutions-montreal66-gac-advice-scorecard-26jan20-en.pdf
[3]See Section 6. Importance of Accreditation of Privacy/Proxy Services and Validation of Registration Data Using Them: https://gac.icann.org/file-asset/public/gac-comments-rds-whois2-review-final-report-23dec19.pdf .
[4] For example, to protect “[o]rganizations within a religious, political or ethnic minority, or sharing controversial moral or sexual
information.” See https://whois.icann.org/en/privacy-and-proxy-services
[5] See https://www.icann.org/public-comments/whois-pp-abuse-study-2013-09-24-en

Significant change required: changing intent and wording

Below is the relevant extract from the full GAC comment on the Addendum, available at: https://gac.icann.org/file-asset/public/gac-comment-epdp-addendum-5may20.pdf

----
Note: The GNSO’s Intellectual Property Constituency (IPC), Business Constituency (BC) and the At-Large Advisory Committee (ALAC) support the views expressed in this comment.

----
The Registration Data of Legal Entities Should Remain Public

As a starting point, as clearly explained by the European Data Protection Board (EDPB) in its letter to ICANN of 5 July 2018, the GDPR only applies to and protects the processing of personal data of natural persons.[1] Information concerning legal persons is not personal data under the GDPR if it does not allow the identification of individuals. Therefore, the contracted parties could make such data publicly available without triggering GDPR concerns. Nevertheless, Recommendation 17 of Phase 1 stated that Registrars and Registry Operators are permitted but not obligated to differentiate between registrations of legal and natural persons. This does not seem consistent with the objectives set out in the Temporary Specifications which “aim[] to ensure the continued availability of WHOIS to the greatest extent possible”[2] and highlighted the issue of “distinguishing between legal and natural persons to allow for public access to the Registration Data of legal persons, which are not in the remit of the GDPR” as an important issue for further community action. Further, the Charter for the EPDP also tasked the team with considering several aspects of this topic.[3] Results of ICANN research on the feasibility, costs, potential liability, and privacy risks of requiring such a distinction is expected this May. ICANN’s legal advisor noted that the percentage of legal registrants is “substantial.” A 2013 ICANN-commissioned study indicated that legal entities comprised the highest percentage category of domain name registrants.[4] This information is especially important in light of scams promising cures for COVID-19. One method for the public to assess the legitimacy of a website and law enforcement to find out what entities are behind it, is to consult the publicly available domain name registration information, which should include the data of legal entities.

In January 2019, the EPDP team also received legal guidance that noted while some legal entities’ domain name registrations contain personal data (e.g., JohnDoe@Acme.com), if the “contact details are generic, such as info@company.com, then the registration data will not include personal data” ("non-personal registrants"). The law firm observed that because “non-personal registrants make up a substantial portion of registrants, one solution being discussed is to distinguish these registrants from those that provide personal data. Under this approach, registration details would be made publicly available by default for non-personal registrants.” Noting the concern that individuals may wrongly designate themselves as legal entities, the law firm suggested several steps to reduce the risk of liability, such as:
1. developing language directed to registrants that “is as clear as possible to help avoid mistakes”;
2. confirming the designation with registrants by “asking them to re-certify that the contact details do not include personal data”;
3. verifying independently the designation through “technical means” (screening for personal information or requiring “a corporate registration ID number”); and
4. ensuring that “data subjects clearly understand the consequences for them of the registrants' self-identification.”[5]

The clear implication of this legal advice as well as the EDPB guidance is that there is a variety of measures to ensure that registrants accurately designate themselves as legal entities. The fact that many ccTLDs (including those based in the EU) already make certain registrant data of legal entities publicly available demonstrates that such distinction is both legally permissible and feasible.[6]

Consequently, the GAC suggests that the EPDP reconsider its position. Instead of deferring this issue, the EPDP team could focus upon the legal guidance provided to develop reasonable policies to permit the information of legal entities to remain public. The time is now to implement policy that deals with this issue in a manner that promotes public safety and provides useful information to internet users seeking to navigate the internet safely and securely.


[1] The GDPR dos 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 (Recital (14) GDPR. “While the contact details of a legal person are outside the scope of the GDPR, the contact details concerning natural persons are within the scope of the GDPR, as well as any other information relating to an identified or identifiable natural person” (See EDPB letter to ICANN of 5 July 2018).
[2] See ICANN Data Protection Privacy Issues: https://www.icann.org/dataprotectionprivacy
[3] See EPDP Team Charter: https://gnso.icann.org/sites/default/files/file/field-file-attach/temp-spec-gtld-rd-epdp-19jul18-en.pdf (included directions for team to consider whether contracted parties should be allowed or required to treat legal and natural persons differently, and what mechanism is needed to ensure reliable determination of status).
[4] See WHOIS Registrant Identification Study: https://gnso.icann.org/sites/default/files/filefield_39861/registrant-identification-summary-23may13-en.pdf: Based on our analysis of the WHOIS records retrieved from a random sample of 1,600 domains from the top five gTLDs,
· 39 percent (± 2.4 percent) appear to be registered by legal persons
· 33 percent (± 2.3 percent) appear to be registered by natural persons
· 20 percent (± 2.0 percent) were registered using a privacy or proxy service.
· We were unable to classify the remaining 8 percent (± 1.4 percent) using data available from WHOIS.
[5] The law firm explained that “this means that the language provided to registrants should explain, separately from any detailed terms and conditions, that self-identifying as a non-personal registrant will result in registration data being made publicly available.” See Advice on liability in connection with a registrant's self-identification as a natural or non-natural person pursuant to the General Data Protection Regulation (Regulation (EU) 2016/679) ("GDPR") from Bird & Bird.
[6] See e.g., Belgium (.BE), European Union (.EU), Estonia (.EE), Finland (.FI), France (.FR), Norway (.NO), etc.

Significant change required: changing intent and wording

Below is the relevant extract from the full GAC comment on the Addendum, available at: https://gac.icann.org/file-asset/public/gac-comment-epdp-addendum-5may20.pdf

----
Note: The GNSO’s Intellectual Property Constituency (IPC), Business Constituency (BC) and the At-Large Advisory Committee (ALAC) support the views expressed in this comment.

----
Recommendation Concerning Feasibility of Unique Contacts to have a Uniform Anonymized Email Address

The EPDP Team received legal guidance noting that the publication of uniform masked email addresses results in the publication of personal data. Based on that legal advice, the EDPD concluded that “wide publication of uniform masked email addresses is not currently feasible under the GDPR.” The GAC wishes to note that the legal advice actually rightly pointed out that pseudonymization is “a useful Privacy Enhancing Technique/privacy by design measure.”[1]

Therefore, the GAC considers that the publication of uniform masked email addresses is a potentially useful privacy enhancing solution (even if the data would still be considered as personal data), which should be further considered. Advice/guidance on this particular matter could also be sought from the EDPB. The Belgian Data Protection Authority, in its letter to ICANN of 4 December 2019, explicitly encouraged ICANN to take note of the draft Guidelines recently issued on 10 November 2019 by the EDPB on Data Protection by Design and by Default, which recognize that controllers could implement technical measures such as pseudonymization under appropriate circumstances.[2]

[1] See Bird & Bird Memo, “Batch 2 of GDPR questions regarding a System for Standardized Access/Disclosure ("SSAD"),
Privacy/Proxy and Pseudonymized Emails” (February 4, 2020).
[2] See Belgian DPA letter to ICANN (December 4, 2019):
https://www.icann.org/en/system/files/correspondence/stevens-to-marby-04dec19-en.pdf citing
https://edpb.europa.eu/sites/edpb/files/consultation/edpb_guidelines_201904_dataprotection_by_design_and_by_default.pdf

Significant change required: changing intent and wording

Below is the relevant extract from the full GAC comment on the Addendum, available at: https://gac.icann.org/file-asset/public/gac-comment-epdp-addendum-5may20.pdf

----
Note: The GNSO’s Intellectual Property Constituency (IPC), Business Constituency (BC) and the At-Large Advisory Committee (ALAC) support the views expressed in this comment.

----
Domain Name Registration Data Should be Accurate

The accuracy of domain name registration data is fundamental to both the GDPR and the goal of maintaining a secure and resilient DNS. The GDPR, as well as other data protection regimes and ICANN’s Registrar Accreditation Agreement, require data accuracy and such accuracy is critical to ICANN’s mandate of ensuring the security, stability, reliability, and resiliency of the DNS. As stated in the European Commission’s letter to ICANN of 7 February 2018: “[a]s stipulated by the EU data protection legal framework and in line with the obligations of contracted parties under their contracts with ICANN, personal data shall be accurate and 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 […]. To comply with the data quality principle, reasonable steps should be taken to ensure the accuracy of any personal data obtained.”

The Charter for the EPDP tasked the team with assessing “framework(s) for disclosure […] to address (i) issues involving abuse of domain name registrations, including but not limited to consumer protection, investigation of cybercrime, DNS abuse and intellectual property protection, (ii) addressing appropriate law enforcement needs . . . ” The effectiveness of Domain Name Registration data for these purposes (indeed for any purpose, including the ability of contracted parties to reach their customers) is of course contingent upon its accuracy. Moreover, the EPDP Phase 1 Final Report stated, “the topic of accuracy as related to GDPR compliance is expected to be considered further . . .” Hence, the GAC does not support the GNSO Council’s guidance to defer the EPDP’s consideration of data accuracy. The GAC further does not support the EPDP’s preliminary conclusion not to consider this topic further. Conducting these discussions now would be the most efficient and logical course of action given the crucial role that data accuracy plays in preserving the operability and integrity of the DNS. The GAC therefore encourages the EPDP to reconsider its position in the light of the arguments provided above.

No, I wish to continue to the next section

Below is the relevant extract from the full GAC comment on the Addendum, available at: https://gac.icann.org/file-asset/public/gac-comment-epdp-addendum-5may20.pdf

----
Note: The GNSO’s Intellectual Property Constituency (IPC), Business Constituency (BC) and the At-Large Advisory Committee (ALAC) support the views expressed in this comment.

----
The GAC appreciates the efforts over the past 21 months and acknowledges the considerable time and commitment by the EPDP team and ICANN support staff to develop these complex and important policies in a timely manner. Nevertheless, the recently released Addendum to the Phase 2 Recommendations does not adequately address several crucial issues, including:
the treatment of domain name registration data from legal entities,
the accuracy of domain name registration data,
the display of data registered with privacy proxy service providers, and
the feasibility of unique contacts to have a uniform anonymized email address.

The GAC has issued advice and contributed input that highlights the importance of these issues [1]. The GAC would like to explain why these issues remain important and urges the EPDP team to either address these issues in its Final Report or at least recommend a clear and definite path to resolve these key issues.

Note: The GNSO’s Intellectual Property Constituency (IPC), Business Constituency (BC) and the At-Large Advisory Committee (ALAC) support the views expressed in this comment.

[1]: See GAC Input on EPDP Phase 1 Final Report at: https://gac.icann.org/reports/epdp-initial-report-gac-Input-21dec18.pdf, Joint GAC-ALAC Statement on EPDP at: https://gac.icann.org/publications/public/icann64-joint-gac-alac-statement-epdp-13mar19.pdf and GAC Advice in its Communiqués in San Juan (15 March 2018), Kobe (14 March 2019) and Montréal (6 November 2019).

No, I would like to continue to the next section

Support Recommendation as written

Support Conclusion as written

Support Conclusion as written

Support Recommendation as written

Support Conclusion as written

Support Recommendation as written

Support Conclusion as written

No, I wish to continue to the next section

If the intent is compliance with the GDPR, I still (having argued this as a member of the EPDP Team) don't understand how this purpose is at all helpful. It is nowhere near being as specific as required by the GDPR. If a data subject has its personal information processed to satisfy this purpose, how would it be explained to them in any way that would be considered understandable. Noting ICANN's mission with respect to names, as stated on page 22 of the Addendum to the Initial Report, as well as the input by the ICANN Board, I still don't see how any of it is relevant. Processing of gTLD Registration Data for an ICANN purpose (with ICANN being one of the data controllers) is not required to fulfill anything in the statement; at least not in any way other than those already identified during Phase 1 of the EPDP. To help clarify the "purpose of this purpose", the EPDP Team should develop a worksheet similar to those developed for purposes in Phase 1 of the EPDP. Processing activities concerning this purpose should be listed, Controllers and Processors of the data should be declared and the lawful basis for each processing activity should be identified.

No, I wish to continue to the next section

ICANN Purpose 6 in Phase 1 of the EPDP says:

"Operationalize policies for the 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 the TDRP;"

It is my belief that the lawful basis corresponding to this purpose, identified as Article 6(1)(b) from the GDPR by the EPDP Team, is the incorrect lawful basis. The reason this lawful basis was selected was that the processing of gTLD Registration Data for this purpose was found to be necessary for the performance of the contract between Registrars (Data Controller) and Registrants (Data Subject).

In October 2019, the European Data Protection Board (EDPB) published guidelines on this lawful basis, which I believe is pertinent to its use, and conflicts with the rationale developed by the EPDP Team in selecting it as the appropriate lawful basis for this Purpose. The EDPB guidelines on this can be found here: https://edpb.europa.eu/our-work-tools/our-documents/retningslinjer/guidelines-22019-processing-personal-data-under-article_en

I believe it is important for the EPDP Team to consider these guidelines, which were published months after the ICANN Board approved the GNSO Recommendations, and determine if it is indeed the appropriate lawful basis for processing gTLD Registration Data for the purpose of ICANN Dispute Resolution Processes. The EPDP Team should also explore what options may be available to amend the recommendation it made on this in Phase 1 of the EPDP, should this be deemed to be necessary.