ABCDEFGHIJKLMNOPQRSTUV
1
Timestamp
Please provide your name.
Please provide your affiliation.
Are you providing input on behalf of another group (e.g., organization, company, government)?
If yes, please explain:
Question for Community Input: Is there new information or inputs that the Phase 2A team has not considered in assessing whether to make changes to the recommendation that Registrars and Registry Operators may, but are not obligated to, differentiate between legal and natural persons?
Question for Community Input: Is this recommendation necessary for the GNSO council in considering future policy work in this area? If yes, in what ways does this monitoring assist the Council?
Question for Community Input: Should a standardized data element be available for a Contracted Party to use? If yes, why? If no, why not? Why is harmonization of practices beneficial or problematic?
Question for Community Input: If yes, what field or fields should be used and what possible values should be included, if different from the ones identified above? Aspects of the recommendation that the EPDP Team is looking for specific input on have been marked with an asterisk (*) on pp. 5-6 of the Initial Report, and indicate the options that are under consideration.
Question for Community Input: If such a standardized data element is available, MUST a Contracted Party who decides to differentiate use this standardized data element or should it remain optional for how a Contracted Party implements this differentiation?
Question for Community Input: Does this guidance as written provide sufficient information and resources to Registrars and Registry Operators who wish to differentiate? If not, what is missing and why?
Question for Community Input: Are there additional elements that should be included in the guidance?
Question for Community Input: Are there legal and regulatory considerations not yet considered in this Initial Report, that may inform Registries and Registrars in deciding whether and how to differentiate, and if so, how?
Question for Community Input: If a Registrar or Registry Operator decides to differentiate, should this guidance become a requirement that can be enforced if not followed (“MUST, if Contracted Party decides to differentiate”)?
Question for Community Input: Does this guidance as written provide sufficient information and resources to Registrars and Registry Operators who wish to publish a registrant-based or registration-based email address? If not, what is missing and why?
Are there any other comments or issues you would like to raise pertaining to the EPDP Phase 2A 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.
2
6/29/2021 1:10:24Roberto herrera
123.45.67.89 - 25/Mar/2003 10:15:32 - http://www.google.com/search?q=cars - Firefox 1.0.7; Windows NT 5.1 - 740674ce2123e969
NoGoogleID.ME
Wire tapp jurisdiction 5th edition warehouse company labormax PDF file 5th edition jury of mexico A.D.O.S.L FTPF MACDOWELL JUSTICE COURTS DISCRIMINATION OF CHINESE CONSUMERS BY MEXICO.
BENEFICIALCONFIRMGOOGLE GTS ROOT R4GOOGLE ROOT R4
ROOT GOVERNMENT CERTIFICATION AUTHORITY
SANTACLARACOURTSFILESAVER.BASE.APK
GOOGLE LEGALADDHS
123.45.67.89 - 25/Mar/2003 10:15:32 -
http://www.google.com/search?q=cars -
Firefox 1.0.7; Windows NT 5.1 -
740674ce2123e969
3
7/11/2021 17:12:50
4
7/12/2021 0:47:26Arlyss engebretsonGoogleplus.comNo
I'm the one who made this
I have been anonymous in my account and some how was kicked off of my accounts
Beneficial and problematic
Why someone who try to take over my accounts
I'm supposed to be in charge of my data
Theft of my account is a crime
I want all my accounts back
Arlyss engebretson should be owner and controller
By law it should be corrected
Arlyss Michelle engebretson (651)354-5967
Engebretsonarlyss7@gmail.com
Address 1459 county road b east maplewood MN 55109 mailing address
Owner
5
7/13/2021 9:48:50Michele NeylonBlacknightNo
No. We agree with the recommendation.
No. This is pointless. Contracted parties need to comply with the law. If there are changes to laws that impose different obligations on registrars then we will comply with them as needed.
If a contracted party wants to go down this route then a standardised data element should be available to be used. However we do not think that such a complex issue can be determined through the usage (or not) of a single data element.
The distinction between legal and natural persons is over simplified presentation of a complex and nuanced issue. The question for us as a registrar is whether we are exposing PII or not. An organisation might be one thing, but the contact data will very often contain other elements like the personal details of an employee or agent
Optional
No. Data protection law is complex and the penalties both legal, financial and reputational are high. The concept of "consent", for example, is complex and needs to be "informed". Due to the way that domain registration data has been used and abused in the past it's impossible to truly provide informed consent. While the guidance might be a starting point it would be incumbent on each registrar or registry to seek their own legal advice and be able to adapt to their local laws.
See above
Local laws and possibly advice from the local DPA
No. As in our previous responses we'd note that this is a starting point only and is not comprehensive
No. We'd want a clear legal rationale and technical explanation and basis for how doing "registrant based" email addresses provides anonymisation. In any case we'd definitely want something more detailed than this and ultimately we have to comply with local law before anything else
No.
6
7/14/2021 0:25:59GABER AHMEDGOOD
7
7/14/2021 11:47:45
8
7/15/2021 3:35:30Zhou Heng
Hunan Academy of Social Science
No
According to Article 24/61 of China Cyber Security Law(中华人民共和国网络安全法), the service provider of Domain Name registration is obligated to require the registrants to provide their real identity. Failed to comply such obligation, the China Network authority is entitled to shut down the domain name registration service.

Therefore, ICANN and its Contracted Parties should not only allow the registrants to self-identify as natural or legal persons, but to require the registrants to provide their true identification. Otherwise, ICANN and its Contracted Parties might face compliance risk from China.
9
7/15/2021 11:49:56QuentinNoNoNothing to do with itYesYesYedYes I do
10
7/15/2021 11:52:56QuentinNo
Yes you should have registration legal national
YesI'm notI'm not
11
7/15/2021 11:53:29No
12
7/19/2021 2:48:04
Elizabeth Bacon, RySG Vice Chair, Policy
the Registries Stakeholder Group (RySG)
Yes
Comment submitters on behalf of the Registries Stakeholder Group (RySG). In the interest of time, we did not conduct a vote on these comments. We did discuss them on our mailing list and during a biweekly conference call, and no member opposed their submission.
The RySG agrees with this recommendation. The RySG finds that its review of the study (1) conducted by ICANN Org on differentiation between Legal and Natural Persons in the Domain Name RDDS, the Bird & Bird memo (2) on Legal vs Natural Persons and the substantive input provided during the public comment forum on the addendum to the EPDP Phase 2 Initial Report (3) has not yielded any compelling reasons to amend Recommendation #17 in the Phase 1 Final Report.

Moreover, the RySG continues to observe that Recommendation #17 in the Phase 1 Final Report, permitting but not requiring differentiation, is the most appropriate approach given legislative developments with NIS2 and the Digital Services Act. Rather than create an unnecessary potential conflict between law and ICANN policy, existing Recommendation #17 allows Registries the necessary flexibility to determine compliance with their applicable laws.

(1) https://mm.icann.org/pipermail/gnso-epdp-team/attachments/20200708/5f72ece1/Rec17.2_Legal-Natural_8jul201-0001.pdf
(2) https://community.icann.org/display/EOTSFGRD/Legal+v.+Natural
(3) https://www.icann.org/public-comments/epdp-phase-2-addendum-2020-03-26-en
The RySG does not agree with this recommendation and believes it is out-of-scope of the EPDP Team’s mandate. First, it is important to note that the EPDP on the Temporary Specification for gTLD Registration Data had a narrow scope of bringing gTLD Registration Data Policies at ICANN into compliance with the European Union’s General Data Protection Regulation. Limiting the scope so narrowly to the topic of compliance with EU data protection regulation and using the Temporary Specification as a starting point allowed for the use of an Expedited Policy Development Process as opposed to a more traditional PDP in which an issues scoping phase would have been required. Annex 4 of the GNSO Operating Procedures (1) allows for very specific conditions under which the use of an Expedited PDP is permitted, none of which are fulfilled by addressing the EU’s draft Revised Directive on Security of Information Systems (NIS2).

As the draft legislation stands, NIS2 does not present the same conflict for contracted parties that GDPR did. The requirements of GDPR forced contracted parties into conflict with either the law or their ICANN Agreements. As law cannot require a party to act in conflict with law, the EPDP work was necessary to address data processing. The same cannot be said for NIS2.

The RySG understands the concerns expressed by colleagues within the EPDP Team regarding their belief that GNSO processes are not agile enough to deal with a changing legislative environment that impacts the domain name space. However, we do not believe that this concern, if true, is best addressed by developing out-of-scope policy recommendations in order to seek some form of mitigation against this.

Furthermore, the RySG does not consider this recommendation to add any substantive value. ICANN Org is currently already monitoring draft legislation that is relevant to its policies and how they are implemented by its Contracted Parties. The draft NIS2 is, in fact, already listed in its currently published report (2) as a relevant draft proposed legislation in-progress that ICANN should follow closely. Adding a recommendation to that same effect is not only out-of-scope, but redundant.

We must also note that it is not the task of any PDP team to criticize, directly or indirectly, or otherwise suggest any recommendation which is aimed, not at the task the GNSO has set, but at changing established GNSO processes. Such matters should be raised in the appropriate fora, of which the EPDP is not one.

(1) https://gnso.icann.org/sites/default/files/file/field-file-attach/annex-4-epdp-manual-24oct19-en.pdf
(2) https://www.icann.org/legislative-report-2019
The RySG believes that an obligation of adding new data elements to the RDDS in this manner is also out-of-scope of the EPDP. On the topic of Legal vs Natural, the EPDP team was specifically tasked with reviewing recommendation #17 from Phase 1, to determine if this recommendation should be amended following a review of the ICANN Org study, Bird & Bird’s legal advice and substantive input on the topic submitted during the public comment forum on the addendum to the Phase 2 Initial Report. Further instructions were given by the GNSO Council to consider developing guidance for Contracted Parties that choose to differentiate.

The introduction of a binding policy recommendation, as is being done in recommendation #3, does not address either of the 2 sets of instructions by the GNSO Council. If adopted, this recommendation would however potentially require amendments to Phase 1 recommendations #5, #7, #8 and #10, none of which the GNSO Council tasked the EPDP Team with amending. These recommendations have already been adopted by the ICANN Board and are currently in the process of being implemented by an Implementation Review Team.

Finally, the RySG does not believe that there is any added value in requiring Contracted Parties to differentiate between the Registrant type (Legal Person vs Natural Person), as this is not in any way determinative in how gTLD Registration Data is processed. It is the nature of the data itself that is more crucial and whether or not this data might result in the identification of a Natural Person, not the Registrant type.

This is already demonstrated in various sections of the Phase 2 Final Report and Recommendations, such as in Recommendation #9, section 9.4.4, where disclosure of gTLD Registration Data must be automated where there is “No personal data on registration record that has been previously disclosed by a Contracted Party”.

Those parties proposing the addition of this data element have put forward several rationales for its necessity as a publically available field: (i) tracking to what extent Contracted Parties are implementing differentiation; (ii) allow the public to verify the accuracy of a legal vs. natural designation. Neither of these rationales make practical sense, let alone are compelling enough to justify such significant and out-of-scope changes to existing policy. What is the purpose of tracking implementation of a voluntary action? Wouldn’t the existence of unredacted legal person data demonstrate that the party is implementing differentiation without the data element? And how does this data element alone provide any additional value for accuracy efforts? The RySG cannot support significant mandatory changes on such thin rationales.

Notwithstanding our observations outlined above, and with due regard to the RySG comments relating to Recommendation 4 ‘guidance’ outlined below; we do believe the inclusion of a suggested ‘standardized data elements’ may be more acceptable an option were it to be included, for the purpose of encouraging consistent labelling and handling of potential flags, not as a mandatory recommendation, but as a practical voluntary element contained in truly voluntary guidance (e.g. Preliminary Recommendation 4.3).

For the avoidance of doubt, the RySG also notes that were any contracted party to decide to engage in voluntary differentiation under the existing recommendation 17 (EPDP Phase 1), then any reliance on ‘guidelines’, MUST equally remain voluntary. We would caution the EPDP team to consider the consequence of making any ‘guidance’ mandatory. Mandatory expectations cannot be considered ‘guidance’, but rather a factual and unequivocal determination of ‘legality’, adherence to which will be enforced by ICANN compliance, under the relevant contracts. Noting our concerns with the guidance itself (Question 6 below), where we do not believe the guidance to be comprehensive, or practical enough for such purpose at this juncture, we must insist that any guidance issued by the EPDP Phase 2A team MUST remain voluntary as per the GNSO instructions i.e. ‘guidance’ not ‘mandatory enforced procedure’.
The RySG does not agree with the recommended amendments to the fields for the reasons stated in our response to Question 3 above. For the avoidance of doubt, we will restate that the RySG does not agree that the creation of such a mandatory field is in the scope of the EPDP Phase 2A team; we reiterate the only GNSO established task for the team was to identify whether a change to recommendation 17 was likely to receive consensus (i.e. that the Registry / Registrar MAY differentiate between natural and legal persons). The creation of such a field is not envisaged in the GNSO instructions, and such instructions certainly did not include, explicitly or impliedly, the creation of a new mandatory data element for RDDS. Such a data element relating to the RDDS has no bearing, nor is it necessary to answer the query as to whether consensus to change an existing recommendation is likely to exist.
The RySG does not agree with the recommended amendments to the fields for the reasons stated in our response to Question 3 above. Should this recommendation be adopted, the RySG firmly believes that the collection/generation of the field concerning the “Registrant Legal Person (Yes/No/Unspecified)” should be optional for the applicable Contracted Party to collect/generate.

We would also like to remind the EPDP team, that where a contracted party specifies either ‘yes’ or ‘no’ in such a field, a substantial set of additional processing of data, personal or otherwise, is required. The guidance does not provide standard, practical and reliable means of arriving at such a predictable conclusion as expecting mandatory publication of the outcome of such data processing operations. This places a large number of Contracted Parties at an elevated, if not substantial risk, were they to voluntarily choose to delineate. If it is the intention of the EPDP to encourage voluntary delineation, then we must advise that all aspects of the guidance must remain voluntary, as intended.
The RySG submits that the guidance, although certainly welcome in principle, ultimately falls short, in form, of what is actually necessary to be of specific operational use to a registry operator. The RySG appreciates the effort in the intention to provide legal clarity to the contracted parties; however, unfortunately upon review and reflection this ultimately provides little or no actual practical guidance as to how to achieve such compliance.

The RySG is supportive of guidance for contracted parties, but we must conclude that noting the very nature of the concept, such guidance, to be actionable and effective, should be created by the Contracted Parties themselves, to aid those Contracted Parties who may choose to delineate, and who may find the guidance useful, in part, or in full, in their efforts to carry out the delineation as they deem appropriate for their business. The Contracted Parties retain the necessary practical knowledge applicable to create and trace the implications of such practices. Therefore, to be clear, the RySG does not support practices, best, good or otherwise, which are not created with deference to the specific expertise and practical understanding of the underlying processes being proposed. We have not benchmarked, user tested, or evaluated this guidance in any way sufficient to determine its real world efficacy, and are in no position to deem it superior to any other practices. We believe that publication of any such practices, without the full agreement of the affected controllers, serves minimal purpose. We are not convinced that the practices as drafted meet this standard.

More specifically, the proposed guidance (in section 5) states that Registrars should publish the Registration Data of a Registrant in the publicly accessible RDDS should the Registrant self-identify as a Legal Person. Despite the proposed guidance also stating that Registrars should clearly communicate to Registrants the consequences of self-identifying as a Legal Person, the responsibility (and legal liability associated with that responsibility) remains with the Controller(s) of the data despite any “education” or knowledge of the Registrant. Effectively, the proposed guidance is encouraging Registrars to process personal information of a potential natural person without conducting the due diligence required of them. Ironically, section 7 of the proposed guidance points this out, which places it in conflict with the guidance in section 5.
Notwithstanding the answer to Q6 above, the RySG does not believe that additional elements for inclusion in this guidance will be helpful.
For the purpose of guidance on differentiation between Legal and Natural Person Registrants, the RySG believes that each Contracted Party must take into account any legal and regulatory considerations that are applicable to it. These might not be uniform across all Contracted Parties, further demonstrating how the proposed guidance may, or indeed may not be helpful to those it is meant to assist.
The RySG firmly believes that this guidance must not become an enforceable requirement to implement. It is very likely that it would be harmful to both ICANN and Contracted Parties, should it become a requirement as well as potentially harmful to Natural Person Registrants whose personal information might inadvertently be published as a result of following the guidance.

Even if the EPDP Team is able to achieve consensus on substantive guidance for Contracted Parties, it is still important that any guidance be optional for Contracted Parties to implement. Not only to allow Contracted Parties the flexibility to comply with applicable law as appropriate but to implement changes in a way that makes operational sense to each one of them individually. This will very likely vary across Contracted Parties depending on multiple factors such as applicable laws, size of operations, availability of resources, Contracted Party business model, etc..
The RySG appreciates that the recommendation is well intentioned, and we support efforts to provide any additional clarity and aid to the contracted parties, but again we find the recommendation to be lacking in practical and functional aspects of guidance, noting that the guidance ultimately restates legal expectation, whilst providing no practical means or guidance on how to achieve this. We refer again to our statements in response to Q6 above.

Moreover, we are concerned that the wording of this guidance implies that anonymization of email address contacts is possible, when the guidance from Bird & Bird very clearly concludes that this data is pseudonymous, not anonymous, even from the perspective of third parties. Rather than provide clarity, this appears to muddle the issue for parties attempting to implement this guidance.
13
7/19/2021 7:10:50Manju ChenNCSGYes
I'm submitting the comment on behalf of the Non-Commercial Stakeholder Group (NCSG).
The NCSG wishes to point out that GDPR does not, in fact, distinguish between legal and natural persons. The Regulation distinguishes only between the personal data of natural persons and data pertaining to legal persons. In other words, the distinction in GDPR is data-based, not person-type-based. The GDPR applies to natural persons and provides protection for them; this is a legislative scope question.
   
In many cases, a domain name registration by a legal person could very well include personal information of a natural person. Therefore, requiring registry operators and registrars to make distinctions based on the person-type of a Registered Name Holder (RNH) will not only put the contracted parties at the risk of violating GDPR but also increase the possibility of undermining the RNH’s privacy rights.
   
The distinction between legal and natural persons is not as easy and clear-cut as some might assume. Not all countries and their legislative system recognize or apply the concept of legal or natural persons, particularly when it concerns independent contractors and single person businesses.. Even in those countries that do, there is no guarantee that their people are familiar with this legal concept.
   
The NCSG represents non-commercial users of all kinds, often staffed by volunteers. Many non-commercial organizations have a loose, unincorporated structure, others are quite large and formal. Since the management of domains is rather a specialized area of expertise, it is frequently the case that a technology-oriented volunteer will register the domain names on behalf of the organization, and it may be difficult to decide what the status of that registration is in terms of personal vs. legal person. Since it is not the concern of ICANN, why would we ask our members to consult a lawyer over a domain registration?
Given the length of time it has taken to comply with data protection law, and the difficulty in reaching consensus in multiple phases of this EPDP, the NCSG objects to the proposed monitoring mechanism because it will continue to generate a hefty and unnecessary workload for the GNSO Council.
   
In our opinion, it is not the GNSO council’s responsibility to monitor any specific regional legislative development. According to ICANN’s Bylaw (Section 11.3.d), the GNSO council is responsible for managing the policy development process of the GNSO. Asking the GNSO council to monitor legislative development is asking it to perform tasks outside its remit.
   
NCSG also believes that there are existing efforts within ICANN regarding this task. ICANN ORG’s Government Engagement team does an outstanding job of following such developments and reporting back to the community. In addition, the GNSO Standing Committee recommended in the EPDP Phase 2 Final report was designed to perform such tasks. We are also quite confident that many of the larger business organizations represented in the GNSO BC and IPC stakeholder constituencies will be assiduous in bringing any legislative changes in favour of the historical style WHOIS to the attention of the GNSO Council. We will undertake to keep the GNSO posted on interesting new developments in data protection.
   
Volunteer burnout is one of our greatest struggles within the ICANN community. We have all agreed during the discussions of enhancing ICANN’s multistakeholder model that precisely scoping the work is critically important to prevent inefficient use of resources, delayed decision-making and volunteer burnout. We neither want to burden the GNSO council with work outside of its remit nor to duplicate existing efforts and risk creating another silo.
No. If a data element differentiating between legal and natural persons is required, then ICANN is encouraging Contracted Parties to differentiate between legal and natural persons. We have explained in our response to Question 1 why that is problematic for many non commercial registrants and unacceptable to NCSG; we also see no policy consensus for differentiation emerging from the EPDP.
   
There are many different business models in the contracted parties community, with different relationships to the actual registrant. Many of those relationships have little or no contact with the registrant, so explaining legal issues surrounding the registrant’s entitlement to data protection law, difficult and confusing at the best of times, is made even more remote. . Since the contracted parties are the data controllers, it is up to them to determine the burden that applies in terms of legal explanations, not to mention correction, access, and the right to be forgotten. They also carry the legal liability for making a mistake if they choose to use the standard data element.
The NCSG does not believe that further fields are necessary or desirable.
As described above, there are a great many different business models in the DNS ecosphere. We believe firmly that the Contracted Parties should be left to implement any potential differentiation between legal persons and natural persons in the way they see fit, in the jurisdictions in which they operate.
NCSG maintains its position that no guidance regarding the distinction between natural and legal persons should be provided to the Contracted Parties as an ICANN consensus policy.
   
We note that registrants who wish to consent have their data published already have the option to do so. This makes self-identification as a ‘legal person’ unnecessary. At best, the guidance proposed adds a complicated process to achieve the same result; at worst it will confuse some registrants into self-designation as legal persons who may not understand the full consequences.
   
Registrars and registry operators who wish to attempt to differentiate can voluntarily develop guidance for themselves. They are the ones who bear the legal obligations to protect personal data and they can assess the procedures and associated legal risks that suit best to their business models and needs.
   
We strongly recommend not providing what amounts to legal guidance in an ICANN policy.
No. See above.
NSCG reiterates that ‘consent’ is not the master key that opens all doors to personal data. ‘Consent’ or ‘explicit permission’ is not the only basis for processing personal data under GDPR. GDPR has six grounds of processing. As it is a prohibitive regulation, one cannot process personal data in the EU unless one of those six grounds is satisfied. Most companies will NOT be processing on the basis of ‘consent’ but on ‘legitimate interests’ (Article 6 (1)(f) ) or performance of a contract (Article 6 (1)(b) ).
   
If consent is relied upon as the basis for processing then the consent must be informed and explicit. Risk needs to be well explained. This is not easy in the context of a global registration data access tool, despite the best efforts of ICANN and the EPDP to comply with law.
No. See answer to the first question for Preliminary Recommendation #4.
No. The legal memo from Bird&Bird has made it clear that publishing or automatically disclosing either registrant-based or registration-based email addresses would be considered to be the processing of personal data, thus subject to GDPR.
   
This means that there is no way to eliminate the risks of violating the registrant’s privacy rights if the Contracted Parties publish either registrant- or registration-based email addresses. This puts the Contracted Parties at risk of facing penalties for violating the law.
   
We have pointed out many times that so-called anonymization techniques are usually merely de-identification techniques.
   
Throughout the discussions of the EPDP 1, 2, and 2a, the NCSG has pointed out that there has been very little discussion of the rights of the individual, and how best to protect registrants’ privacy. For instance, our best advice to all registrants would be to avail themselves of privacy proxy services, since they cannot really be certain, as registrants, how opaque this ‘SSAD’ is going to be, with its contractors who will run the accreditation process for users wishing to gain access to data, the contractors who will audit the procedures, etc. How strict will compliance with the GDPR, and indeed this policy, actually be? ICANN’s track record of compliance with privacy law is hardly encouraging.
The NCSG has been calling for respecting the privacy rights of registered name holders since the earliest days of ICANN. We collaborated with the Council of Europe to bring a host of data protection experts, including then European Data Protection Supervisor Giovanni Buttarelli and the UN Special Rapporteur on Privacy Professor Joseph Cannataci to the public meeting in Copenhagen (ICANN 58, March 2017) prior to the coming into force of the GDPR.
   
The NCSG does not claim to represent small businesses and sole entrepreneurs, but we caution against neglecting them and their rights in ICANN’s policy discussions. We live in a gig economy. Even without COVID and lockdowns, more and more individuals are working for themselves. Many privacy laws protect employees, and recognize their rights, but that usually does not extend to contractors. Many companies now are forcing their employees into ‘contractor’ status, often to avoid paying benefits, health, and safety liability.
   
The policy we are developing must address the privacy rights of employees of legal persons, and other persons employed by those entities in certain cases. The GDPR applies to personal information. The rather sparse statement that it does not apply to legal persons is not particularly helpful in actually parsing the data in a DNS registration.
   
The NCSG has participated in good faith and in large numbers throughout the RDS pdp, EPDP 1, EPDP 2, and EPDP2a. We would like to underscore that we do not want to reargue these particular points, raised in this last group, in the upcoming discussions on accuracy. ICANN has a track record of dismissing data protection law for at least 18 years. We think they ought to be capable of refraining from discussing these issues for at least 5 years, at which point we will have a much better perspective on how a post-WHOIS world is actually functioning.
14
7/19/2021 10:34:51Lori SchulmanINTAYes
Submitting on behalf of INTA and not in my personal capacity.
Redaction of legal entity RDS data is simply not warranted under data protection legislation. In fact, the GDPR says, “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.” (Recital 14)
Because ICANN established the Temporary Specification to preserve “the former WHOIS system to the greatest extent possible,” shifting the burden to justifying why redacting this data should not be redacted is inappropriate.
One new input to consider is the practical experience gained since the EPDP Phase 1 Final Report contemplated that contracted parties would provide WHOIS data in response to individual requests. Unfortunately, empirical evidence indicates this is largely not the case. Leading organizations requesting this data from contracted parties for consumer protection purposes report disclosure rates in the range of 10 (https://www.appdetex.com/appdetex-whois-requestor-system-awrs-3/) to 14 (https://clarivate.com/markmonitor/blog/gdpr-whois-and-impacts-to-brand-protection-nine-months-later/) percent. Voluntary disclosure rates this low weigh heavily in favor of requiring a distinction and publishing legal entity data. Since the data is generally redacted and not provided upon request, mandatory publication seems to be the only way for ICANN to ensure this data is available for those with legitimate interests.
We note that some contracted parties have contended that criminals and tortfeasors do not list legal entity data in WHOIS records, but this is unfounded and in the experience of many INTA members, simply untrue. Furthermore, while consumer protection and IP rights enforcement may be the primary uses of WHOIS data for INTA, we note that all legitimate needs for this data are impeded when the data is unavailable. (https://whois.icann.org/en/what-whois-data-used)
We encourage the EPDP team to follow the legal advice provided by Bird & Bird on this issue, which found that “the risk to Contracted Parties seems low” since inadvertent publication “would be a hopefully rare and unintended event” and “liability should attach to a Contracted Party only if and when they fail to properly address complaints.”

Finally, while it appears that the contracted parties are primarily concerned with liability for substantial fines under GDPR, we caution that failure to provide timely access to RDS data may result in other liability for contracted parties. The pending NIS2 Directive, for example, requires contracted parties to publish RDS data where no natural person data is present.
As discussed above in response to Question #1, we believe that differentiation between natural and legal person entities’ data should be mandatory for all contracted parties as a matter of consensus policy for purposes of publication of all non-personal data in RDDS consistent with the scope of the GDPR and consistent with ICANN’s promise to maintain traditional RDDS service to the greatest extent possible under applicable law in service of its SSR mission. Failing that, it is critical that this question be reexamined as new regulatory or legal guidance becomes available confirming what is already apparent in GDPR, including that contracted parties would be insulated from liability and on an equal competitive playing field by differentiating and publishing non-personal data in RDDS. The current NIS2 proposal already clarifies that this approach is appropriate under GDPR. Per NIS2 Article 23.4: “Article 23.4. Member States shall ensure that the TLD registries and the entities providing domain name registration services for the TLD publish, without undue delay after the registration of a domain name, domain registration data which are not personal data.” The European Commission is also considering updates to this text to specifically confirm that all domain name registration data of legal persons shall be published, as such data is beyond the scope of Union data protection rules, and stating that in the event that such data of legal persons contains personal data, publication by the data processor shall not be considered an actionable data breach, provided that steps are taken promptly, when notified by the data subject, to rectify the record and cease the publication of such personal data.

Although this recommendation is probably not strictly necessary, since it does not include any proposed new policy or changes to existing policy, it importantly implies some future further consideration of the EPDP Phase 1 policy concerning differentiation between data of natural and legal person entities. We therefore support its inclusion. That said, the recommendation could be more certain or specific in terms of providing triggering events or timelines at which points reengagement on this issue would be appropriate, or guidance as to specific mechanisms by which the Council would monitor developments and trigger reevaluation, although we appreciate that this may be too constraining given the organic nature of regulatory and legal developments. One possibility may be to empower the GNSO Liaison to the GAC to coordinate with GAC colleagues to monitor these developments, report to Council, and present recommendations to trigger a limited policy reevaluation on this specific issue as further regulatory or legal guidance becomes available that is relevant to this matter. It may also be beneficial to coordinate with ICANN org on this matter, as we understand that ICANN org is also already undertaking certain efforts to monitor and flag developments in the regulatory landscape that may implicate ICANN policy matters.

These considerations are especially important given that completion of an operational SSAD is likely years away, and that the proposed SSAD in its current form as outlined in EPDP Phase 2 recommendations pending Board approval is still deeply flawed from INTA’s perspective (which view is shared by a significant portion of the community, based on minority statements and other statements of opposition from GAC, SSAC, ALAC, and the BC and IPC, of which INTA is a member).
Yes. A standardized data element for legal versus natural persons should be available for use by contracted parties who wish to distinguish between natural and legal persons. Contracted Parties already need to develop some form of “flag” in order to comply with EPDP Phase 2 Recommendation 9.4.4 (https://gnso.icann.org/sites/default/files/file/field-file-attach/epdp-phase-2-temp-spec-gtld-registration-data-2-31jul20-en.pdf). Use of this standardized data element will create greater efficiencies for contracted parties, as it can be used to automate reveal requests for registration data that has already been processed. Publication of the flag will also lead to greater transparency, as it will allow ICANN policy-making groups to have greater insight into the percentage of registrants that choose to self-designate or are legal versus natural entities. It will also permit RDS users to assess the veracity of the registrant’s designation.
Furthermore, use of a standardized data element will expedite delineation between natural and legal persons by registry operators that already make this distinction, in particular .Brand registry operators or other registries whose legal terms prohibit the use of personal registration data. It will also facilitate flexibility and compliance with new legislation such as NIS2, which when enacted, will require the publication of non-personal data belonging to legal entities.
There is no legal downside to harmonization through use of a standardized data element. As the flag is not itself personal data, there is no data protection risk for contracted parties in publishing it. Moreover, there is currently no proposal that the data must be published, even if both flags indicate that there is only legal entity data. On the other hand, harmonization is critical for assuring the expediency, efficiency, transparency, and predictability of the SSAD, as opposed to the disjointed, opaque, and unpredictable ad hoc approach taken today by contracted parties.
The fields recommended, namely “Yes/No/Unspecified”, are appropriate. The term “unspecified” is a preferable default to either a blank space or the term “REDACTED”. Pursuant to the Initial Report, there does not appear to be a legal requirement to redact this standardized data element, as the legal memoranda issued to date have not taken the position that a “Yes/No” field signifying the registrant’s status as either a natural or legal entity constitutes a piece of personal data. That piece of information should not be considered personal data because it cannot, either directly or indirectly, be used to identify any data subjects.
Yes. Harmonization dictates that contracted parties who decide to differentiate and/or are ultimately forced to differentiate to comply with NIS2, use this standardized data element. Lack of uniformity on this issue would vitiate otherwise useful automated reveal request responses or processes used to study publicly available registration data. It would also only replicate the current disjointed, opaque, and unpredictable ad hoc approach taken by contracted parties.
Yes, it is generally sufficient. However, INTA recommends that more guidance can be provided to registries and registrars. They should also be directed to Section 11 et seq of the April 6, 2021 Legal Memo, or the additional elements INTA has gleaned and expanded upon below. INTA’s proposed data elements are designed to allow registries and registrars to differentiate and publish data belonging to legal persons at minimal practical or legal risk under the GDPR.
Yes. Registries and registrars may also choose to contractually proscribe the use of personal data as registration data in general, or contractually proscribe the use of personal data as registration data for registrants who self-identify as a legal entity. Registries and registrars may also choose to contractually require registrants to release, covenant not to sue, and indemnify against any claims and regulatory actions resulting from their erroneous, inadvertent, or mistaken self-selection as a legal entity and submission of personal data. Registries and registrars may also choose to build in a reasonable two business day waiting period between registrant self-identification and publication in the RDDS, to allow registrants time to correct erroneous or inadvertent self-identification as a legal entity.
Collectively, these additional elements combined with the elements already present in Preliminary Recommendation #4, mitigate the risk of legal liability created by personal data erroneously, mistakenly, or inadvertently included in published registration data for a legal entity, regardless of whether consent has been provided.
EPDP Legal Memoranda have not yet analyzed situations in which registries and registrars contractually proscribe the submission of personal data by registrants, either as an across-the-board prohibition, or as a prohibition that applies only to registrants who self-select as legal entities.
EPDP Legal Memoranda have also not yet analyzed the impact of contractual releases, covenants not to sue, and indemnification from registrants covering claims or regulatory actions resulting from the erroneous, mistaken, or inadvertent provision of personal data by data subjects.
Consistent with the GDPR Recital 146, which provides that “The controller or processor should be exempt from liability if it proves that it is not in any way responsible for the damage,” the foregoing recommendations place responsibility with data subjects for their erroneous submission of personal data in contravention of clear contractual prohibitions. Coupled with the existing safeguards in Preliminary Recommendation #4, including “an easy means [for registrants] to correct possible mistakes”, these additional proposed elements significantly mitigate the risk of legal liability to registries and registrars.
Yes, although to be clear, it remains INTA’s position that differentiation should be made mandatory, and publication of registration data belonging to legal entities will be made mandatory when NIS2 becomes law. Thus, the guidance and additional elements proposed by INTA should also be made mandatory. Registries and registrars will eventually be required under the law to publish registration data for legal entities and establishing plus prescribing the best methods for differentiation now only makes good sense.
No, the guidance does not provide sufficient information. The assessment of whether “appropriate safeguards'' are in place requires a risk-based assessment of: (i) whether to use a registrant-based or registration-based email address; and (ii) whether such addresses should be available through web publication or automatic disclosure. The notes at Annex E confirm that no approach is entirely risk free and the assessment of the relative risk of each solution is an exercise few parties will be confident in undertaking. This means Contracted Parties are likely to take the most conservative approach towards risk (Registration Based + Automated Disclosure). However this will be the most expensive and complicated solution to implement and maintain (and therefore discourage uptake) when the legal analysis at Annex E acknowledges a registrant-based web published solution would not create any meaningful risks to privacy or data security.
We would therefore encourage the EPDP Phase 2A team to make the guidance more prescriptive about the solution (Registrant Based + Web Publication) with Contracted Parties being asked only to satisfy themselves that the solution provides adequate data subject safeguards before adopting it.
15
7/19/2021 11:28:05Brian GuttermanICANN orgYes
Providing input on behalf of ICANN org
What if any policy language does the EPDP Team expect for implementation of this recommendation?
The ICANN Board has previously passed through recommendations that are made to other ICANN structures. It is also our understanding that this recommendation is for the GNSO Council, thus this will not require Board action. If adopted as a recommendation, this recommendation would not result in implementation or enforcement.

If ICANN org is expected to provide a field that CPs MAY use, it will require; for example, clear policy language requiring said implementation. If the EPDP Team intends for a contracted party to be required to use the standardized element if it chooses to differentiate, the team must specify the criteria for when the use of this element is required.

Additionally, how does the WG view this as impacting existing policies such as Consistent Labeling & Display (CL&D) and the Additional Whois Information Policy (AWIP)/Whois Advisory, which have provisions on additional fields? For example, the CL&D Policy provides that:

Registry Operator MAY output additional RDDS fields, as defined in the WHOIS Advisory, without further approval by ICANN. The key and the value of each additional field MUST NOT: include browser executable code (e.g., Javascript); provide confidential information of any sort; or cause a negative impact to the security, stability, or resiliency of the Internet's DNS or other systems. Prior to deployment, Registry Operator SHALL provide the list of all additional RDDS fields to ICANN. Registry Operator SHALL provide to ICANN any changes to the list of additional RDDS fields prior to deploying such changes.

Would the standardized element be subject to these requirements if used by a Registry Operator? If a registrar chose to use the element, would it be expected to follow the same requirements, different requirements, or none?

The Advisory: Clarifications to the Registry and Registrar Requirements for WHOIS (port 43) and Web-Based Directory Services specifies certain fields as optional and describes how such optional fields are to be handled. The Advisory also states that: If additional data fields are included in the Whois output beyond those required by contract or policy, the additional data fields MUST be placed at the end of the response, except where otherwise described in this Advisory or required by policy or contract.

Would the standardized element be subject to these requirements? Should the documentation for contracted parties be updated to account for the new standardized element if adopted?

How would the additional field comply with existing technical standards? Would updates be required or expected as part of implementing this recommendation?

ICANN org notes that the status of a registrant as a legal or natural person does not, alone, determine whether any of the registrant’s contact information contains personal data. Standardized methods to “flagging” differentiated registrations and whether the contact information includes personal data will make it easier for Contractual Compliance to enforce any future requirements. For instance if the SSAD recommendations become requirements, use of a standardized data element displayed in RDDS will make it easier for Contractual Compliance to investigate complaints regarding SSAD disclosure requests and enforce certain requirements such as disclosure of data elements that do not result in the disclosure of personal data, automated disclosure of no personal data on registration record that has been previously disclosed by the Contracted Party, etc. Harmonization of practices may reduce the number of inquiries and/or questions Contractual Compliance may need to send to Contracted Parties.

ICANN org understands the collection logic under Rec 5 to mean that if a registrar chooses to differentiate, it MUST collect/generate the new data element. For clarity, the final report should make clear that the Recommendation numbers referenced in this Recommendation 3 reference the original recommendation numbers in the EPDP Phase 1 report. In addition, the asterisk reference should be copied over or removed.

Noting that “MUST IF” in the collection logic is missing for Transfer logic, this information will be lost if not transferred. Please indicate that this is by design and the risk of not having this information in data escrow as an example is an acceptable risk. Any recommendations with MAY logic cannot be enforced.

As currently drafted, this recommendation does not require any action on the part of CPs or ICANN org for implementation/enforcement. If the EPDP Team intends for a contracted party to be required, as a matter of consensus policy, to follow these best practices under any circumstances, the Team must make a recommendation to this effect and clearly specify when and how these best practices would become requirements and, in addition, whether a contracted party would be able to follow only a subset of these practices, or must adopt all of them, whether the contracted party could later decide to stop differentiating among registrant types, etc. If the EPDP Team has any specific expectations beyond what org has communicated in its previous response in relation to how best practices would be promoted, it will need to state this clearly as part of the recommendation. Put another way, would CPs who choose to differentiate be required to follow this guidance? Additionally, some of this guidance is written as a “must”. If a contracted party chooses to differentiate, does this mean these MUST elements (and only these elements) are required for those who choose to differentiate? As a rule, the policy implementation team will use MUST and MUST NOT as contractually enforceable requirements. Any language that is not clearly stated in terms of MUST may result in multiple interpretations by IRT and would be subject to debate.
ICANN org understands that the team is not leaning towards recommending that registrant- or registration-based anonymized email contacts should be required. Nonetheless, if the EPDP Phase 2A team did decide to recommend that registrant-based emails be required, Contractual Compliance foresees hurdles in enforcing such a requirement without full access to non-public Registration Data. Contracted Parties will use the pseudonymized emails for domain names that are redacted; therefore, without obtaining the non-public Registration Data from the Contracted Party, there is currently no way for Compliance to determine whether the same pseudonymized email is displayed in the RDDS for domain names registered by the same RNH. Without access to all non-public Registration Data, there will be no means for Compliance to independently verify a registrar’s response regarding its use of registrant-based emails, no way to check if the same pseudonymized email is used across all registrars for the same RNH should registrant-based emails be required across all registrars, and no means for audit to proactively test for compliance.

Please note that any recommendations stated as “guidance” or “should” would not result in any policy requirements that are enforceable. Most likely this language would be included as Implementation Notes or informal educational material for implementers.
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 would like to emphasize and reiterate its prior input (https://mm.icann.org/pipermail/gnso-epdp-team/2021-May/003904.html) to the team that a contracted party’s compliance with any recommended best practices (e.g. preliminary recommendations 4 and 5) would not be subject to Contractual Compliance enforcement, absent a consensus policy recommendation that a contracted party MUST follow such best practices (and, if so, when and under what conditions).
16
7/19/2021 12:44:28Lars SteffenISPCPNo
We are not aware of any useful information or input. In our view, the EPDP Team has conducted a well-informed review of this question.
There is no obligation for the GNSO Council to monitor upcoming legislation and initiate policy development processes to reflect such legal requirements. Therefore, such recommendation is a useful mechanism to ensure that the GNSO Council takes action if and when required by legislative changes.
The availability of a standardised data element is a useful option for the contracted parties. It will help foster consistency the treatment of data across the industry.
We do not have specific view on what the values should be.
It should be optional for a contracted party to implement the differentiation. However, contracted parties should be encouraged to use the standardised data element. By doing this, there are good chances for consistency while allowing for different implementations due to local requirements or business models.
We consider the guidance to be sufficient.
We consider the guidance to be sufficient.
We consider the guidance to be sufficient.
Where a contracted party choses to follow the guidance, there should be a requirement for that contracted party to actually follow the guidance and implement it correctly. However, the language requesting compliance with the guidance should clarify that the guidance is a minimum requirement that needs to be met. If the local legal system or case law require different language or additional information, that should not be an issue. Also, it should be possible for a contracted party to embed required information in its own policies and explanatory notes.

The guiding principle should be that users can expect certain minimum standards from a contracted party that claims to follow the guidance.
We would prefer the guidance to be stronger in encouraging registration-based e-mail addresses versus registrant-based e-mail adresses.
No.
17
7/19/2021 12:48:59Lars Steffen
eco - Association of the Internet Industry
No
We are not aware of any useful information or input. In our view, the EPDP Team has conducted a well-informed review of this question.
There is no obligation for the GNSO Council to monitor upcoming legislation and initiate policy development processes to reflect such legal requirements. Therefore, such recommendation is a useful mechanism to ensure that the GNSO Council takes action if and when required by legislative changes.
The availability of a standardised data element is a useful option for the contracted parties. It will help foster consistency the treatment of data across the industry.
We do not have specific view on what the values should be.
It should be optional for a contracted party to implement the differentiation. However, contracted parties should be encouraged to use the standardised data element. By doing this, there are good chances for consistency while allowing for different implementations due to local requirements or business models.
We consider the guidance to be sufficient.
We consider the guidance to be sufficient.
We consider the guidance to be sufficient.
Where a contracted party choses to follow the guidance, there should be a requirement for that contracted party to actually follow the guidance and implement it correctly. However, the language requesting compliance with the guidance should clarify that the guidance is a minimum requirement that needs to be met. If the local legal system or case law require different language or additional information, that should not be an issue. Also, it should be possible for a contracted party to embed required information in its own policies and explanatory notes.

The guiding principle should be that users can expect certain minimum standards from a contracted party that claims to follow the guidance.
We would prefer the guidance to be stronger in encouraging registration-based e-mail addresses versus registrant-based e-mail adresses.
No.
18
7/19/2021 13:01:52Steven DelBiancoNetChoiceYes
The ICANN Business Constituency (BC)
The BC believes that ample legal and practical, real-life information already has been presented to and informed discussions of EPDP Phase 2A work. This has highlighted the critical need for and requirement that Registries and Registrars differentiate between legal and natural persons. We reiterate that the inability of Internet users to identify with whom they are doing business with online, and the increasingly pervasive inability of law enforcement, cybersecurity, and legal professionals to identify criminal actors online through their domain name registration data, continues to severely undermine the security and stability of the Internet.

The BC concurs with the GAC and other SO/ACs that “voluntary” differentiation of legal/natural persons is inadequate. Differentiation between legal and natural persons should be required to ensure a healthy and stable digital ecosystem for the DNS. Steady progress in the European Parliament to finalize NIS2 legislation continues to strengthen this view, with the latest development coming from the Internal Market Committee’s (IMCO) adoption on July 12th of Compromise Amendments to what will be a highly influential Opinion in the development of the lead committee’s final report (expected on October 14th) and, ultimately, the legislative resolution anticipated for the Parliament’s Plenary Session in December.

Compromise Amendment 20 on Article 23 of the NIS2 Directive reveals that the European Parliament expects contracted parties to differentiate legal vs natural persons, and to make public all of the domain registration data for the former. The bold/italicized text below reflects the suggested changes to paragraph 4 of Article 23, and we strongly encourage the entire ICANN community to review the Compromise Amendments in full :

Member States shall ensure that the TLD registries and the entities providing domain name registration services make publicly available, without undue delay and in any event within 24 hours after the registration of a domain name, all domain registration data of legal persons as registrants. (available at: https://www.europarl.europa.eu/meetdocs/2014_2019/plmrep/COMMITTEES/IMCO/DV/2021/07-12/p5-CAs_cybersecurityNIS2_EN.pdf )

We appreciate that the Phase 2A Report details other benefits contracted parties will gain by making the legal vs natural differentiation. For example, publishing legal persons’ data based on differentiation instead of consent significantly reduces the Contracted Parties’ liability; and following proper safeguards also lowers the risks associated with publishing registration data for legal entities.
Yes -- it is critical that the GNSO Council continue this work. NIS2 legislation will be the most prominent -- but not the only – clarification from elected officials and regulators when it comes to the requirements for “registries and entities providing domain name registration services for the TLD [to] have policies and procedures in place to ensures that the database infrastructure includes accurate, verified and complete information.”

( Secretariat of the Committee on the Internal Market and Consumer Protection, "Compromise amendments on the Draft Opinion on the measures for a high common level of cybersecurity across the Union, repealing Directive (EU)", Compromise Amendment 20 on Article 23, Paragraph 3.)

The importance of GNSO Council monitoring of these developments is only increasing. The development of incremental drafts and compromise amendments at the committee level for NIS2 signal that the legislation will address and impact the issue of legal vs natural differentiation along with many other issues material to existing and future policy work around WHOIS, including accuracy, critical data elements, timely publication of non-personal data, and timely reply to legitimate access seekers. ICANN should be keenly aware that key stakeholders, including regulatory authorities in Europe and the United States, are keeping a close eye on the European Parliament’s engagement on these issues via NIS2. Forthcoming opinions and even decisions by tribunal and privacy regulatory authorities are likely and could accelerate as a result of the NIS2 proceedings.

As the BC has stated in previous comments, the SSAD fails to provide guidance to contracted parties about how to address data accuracy and distinctions between legal and natural persons. Further, the SSAD is inflexible and lacks the ability to evolve with anticipated legislative developments in the EU and elsewhere and updates to data privacy laws that may have a significant impact on obligations to disclose registrant data. Thus, ongoing work by the GNSO Council is imperative to inform appropriate changes to the SSAD, which ideally will create a more centralized and adaptable disclosure framework, and mandate disclosure by contracted parties.
Yes -- The BC urges that a standardized data element be made available for contracted party use and that Registries/Registrars should be required to use it. Harmonizing this data element will create a more consistent and reliable WHOIS database, which may be accessed by third parties for legitimate purposes. This will facilitate more effective and prompt response to DNS abuse, cybercrime activity, intellectual property violations, and other activity that threatens consumer welfare.

The standardization of the data element must extend to standardization of publication of the data element. A standardized data element must be defined to create an updated RDAP profile consistent with the recommendation. This is true whether the data element is published in the public RDDS, or redacted and transmitted alongside personal data disclosed from SSAD. Regarding the latter option, we note that such a data element will never contain personal data, and therefore should never be redacted; we include both options only for completeness.
The BC regards the above guidance to contracted parties who wish to differentiate as sufficient. No other fields or values are required. That said, it would be useful if the same Natural/Legal distinction were available to Technical Contact fields as well as Registrant data fields.
If such a standardized data element is available, a Contracted Party should be required to use it. As the BC notes in question 3, Harmonizing this data element will create a more consistent and reliable WHOIS database, which may be accessed by third parties for legitimate purposes. This will facilitate more effective and prompt response to DNS abuse, cybercrime activity, intellectual property violations, and other activity that threatens consumer welfare.
The BC regards the above guidance to contracted parties who wish to differentiate as sufficient. However, #7 is not necessary, as the importance of defining a legal person, noting that designation as a legal entity might include personal data, and requiring registrant consent if the latter is the case, has been laid out clearly in points 1-6.

During both EPDP Phase 2 and EPDP Phase 2a the value of “flags” for streamlining both manual and automated processing was discussed. We note the value of updating such flags once a disclosure request has been processed and the absence or presence of personal data has already been determined, which ensures that any future requests for that same non-personal can be automated. Standardized data elements indicating the presence or absence of personal data, whether at the registration level or at the level of individual data fields, function as such flags.
The BC regards the above guidance to contracted parties who wish to differentiate as sufficient. No other fields or values are required.
As detailed above, the NIS2 legislation, when enacted, will offer further legal protection to Registries and Registrars about differentiation. Other countries active in the DNS -- i.e., Japan, the United States, the United Kingdom -- also may consider regulatory changes that would provide clarity to Registries and Registrars about possible legal exposure when differentiating between legal and natural persons, and how to minimize or even eliminate such exposure. As stated above, it is for this reason that the GNSO Council should continue to monitor legal and regulatory developments in the EU and elsewhere so the EPDP and SSAD can be appropriately updated.
Yes, this should be enforced. Failure to enforce risks undermining the guidance and opening the door to Registries/Registrars using other more stringent approaches that discourage Registrant disclosure and cause back-sliding and weakening of the overall framework of the EPDP.

The BC regards the above guidance to contracted parties who wish to differentiate as sufficient.
At ICANN 71, the chair of the EPDP Phase 2A team made clear that if community comments on EPDP Phase 2A do not provide the team with a path to consensus, the GNSO will discontinue this work in accordance with the GNSO’s new rules and parameters for PDPs. That outcome not only would be acutely disappointing to the BC and other SO/ACs, but also threaten the security and stability of the DNS. The absence of a framework that provides DNS users with timely access to accurate registration data and evolves as the regulatory and legislative landscape changes will create fertile ground for highly destabilizing cyber behavior. Issues with Guidance

The core of ICANN’s mission is to define consensus policy and rigorously enforce these obligations. The recent trend to rely heavily on “optional obligations” (i.e. SHOULDs and MAYs and Guidance) waters down and minimizes ICANN’s remit as it results in policy that cannot and will not be enforced by the ICANN compliance team.

EPDP Phase 2A team has spent a majority of its time debating “guidance” that will be ignored by most contracted parties and will never be enforced by the ICANN compliance team. This is clearly a waste of precious community resources - to no end. The BC believes that the ICANN community should spend time on policy that will apply to all registrars and registries - not just some undefined subset based on their whim.

Issues Related to Procedure

The EPDP Phase 2A inexplicably focused significant time on developing “guidance” rather than binding consensus policies, in violation of the ICANN Bylaws and the Charter of the EPDP Phase 2. The group “ran out the clock”, dedicating a majority of its efforts to creating guidance, thereby preventing a meaningful and robust discussion of how to create binding consensus policies. Discussion of proposals for binding consensus policies supported by multiple stakeholders were inexplicably delayed to the final weeks.
The ICANN Bylaws Annex 2-A specify the process for producing Guidance- that requires a Formal Initiation of a Guidance Process by the GNSO Council. This process was not followed and, as a result, cannot produce Guidance.

Nowhere in the Charter is the development of “guidance” specified. In fact, the GNSO Expedited PDP [gnso.icann.org] Manual referenced in the Bylaws does not state that Guidance is a possible outcome. Instead, it says that the EPDP will address either:

“(1) a narrowly defined policy issue that was identified and scoped after either the adoption of a GNSO policy recommendation by the ICANN Board or the implementation of such an adopted recommendation;
or (2) new or additional policy recommendations on a specific GNSO policy issue that had been scoped previously as part of a PDP that was not completed or other similar effort, including relevant supporting information.

Even a regular PDP outcome is limited to certain outcomes as listed in Section 10 in the GNSO PDP Process Manual [gnso.icann.org] which does not include Guidance. The GNSO Guidance Process Manual [gnso.icann.org] details the processes required to develop Guidance - which were clearly not followed here.

This is an expedited policy development process, governed by the Bylaws, and triggered by a Board vote on May 17th, 2018, where the Board Resolution states:

Resolved, that the Board hereby implements the consensus policy development process set forth in ICANN's Bylaws and will consult with the GNSO Council as soon as possible on the path forward to consider the development of a consensus policy on the issues within the Temporary Specification.

Finally, it is important to remember the Board’s rationale where it’s stated goals were:

· To ensure continued availability of the WHOIS service to the greatest extent possible and other processing of gTLD registration data while complying with the GDPR and avoid fragmentation of WHOIS,
· To continue this public service and maintain the security and stability of the Internet, the Temporary Specification will allow for continued provision of WHOIS services via ICANN's contracts with domain name registries and accredited registrars.

The development of guidance neither ensures nor accomplishes these goals.
19
7/19/2021 14:29:35Danielle Rutherford
ICANN Policy Support for the SSAC
Yes
I am providing input on behalf of the Security and Stability Advisory Committee (SSAC)
From a security practitioner’s perspective, the maximum amount of registration data needs to be available for investigation, either through an effective differentiated access system, or through making it available in the public RDDS.

The SSAC recommends the following regarding legal versus natural persons:

A. A data element should be defined that denotes the legal status of the registrant. Initially we propose three admissible values: Natural, Legal, and Unspecified. “Unspecified” would be the default value until the registrant identifies themselves as a natural or legal person. This field should be able to support status values depending upon future policy decisions.

B. This data element should be displayed as part of the publicly available data.

C. Registrants should be classified as either natural or legal persons. This should be required at the time of registration, for all new domain registrations. For existing registrations, the value can remain “Unspecified” until it is filled at a later time. Registrars should be required to ask at relevant times, such as upon domain renewal and/or the annual accuracy inquiry, whether the registrant is natural or legal, with the goal of eventually obtaining that data for all registrants, and reducing “Unspecified” to the lowest practical level.

D. Registrants currently are able to and should continue to have the option of making their contact data publicly available. Legal person registrants should also have the ability to protect their data via privacy and proxy services.

These recommendations are consistent with SSAC’s previous advice (See SAC104, section 3.6).
Yes.

From a security practitioner’s perspective, the maximum amount of registration data needs to be available for investigation, either through an effective differentiated access system, or through making it available in the public RDDS.
A data element should be defined that denotes the legal status of the registrant. Initially we propose three admissible values: Natural, Legal, and Unspecified. “Unspecified” would be the default value until the registrant identifies themselves as a natural or legal person. This field should be able to support status values depending upon future policy decisions.

Registrants should be classified as either natural or legal persons. This should be required at the time of registration for all new domain registrations. For existing registrations, the value can remain “Unspecified” until it is filled at a later time. Registrars should be required to ask at relevant times, such as upon domain renewal and/or the annual accuracy inquiry, whether the registrant is natural or legal, with the goal of eventually obtaining that data for all registrants, and reducing “Unspecified” to the lowest practical level.
From a security practitioner’s perspective, the maximum amount of registration data needs to be available for investigation, either through an effective differentiated access system, or through making it available in the public RDDS. Therefore, a Contracted Party must use a standardized data element.
From a security practitioner’s perspective, the maximum amount of registration data needs to be available for investigation, either through an effective differentiated access system, or through making it available in the public RDDS.

The SSAC recommends the following regarding legal versus natural persons:
A. A data element should be defined that denotes the legal status of the registrant. Initially we propose three admissible values: Natural, Legal, and Unspecified. “Unspecified” would be the default value until the registrant identifies themselves as a natural or legal person. This field should be able to support status values depending upon future policy decisions.

B. This data element should be displayed as part of the publicly available data.

C. Registrants should be classified as either natural or legal persons. This should be required at the time of registration, for all new domain registrations. For existing registrations, the value can remain “Unspecified” until it is filled at a later time. Registrars should be required to ask at relevant times, such as upon domain renewal and/or the annual accuracy inquiry, whether the registrant is natural or legal, with the goal of eventually obtaining that data for all registrants, and reducing “Unspecified” to the lowest practical level.

D. Registrants currently are able to and should continue to have the option of making their contact data publicly available. Legal person registrants should also have the ability to protect their data via privacy and proxy services.

These recommendations are consistent with SSAC’s previous advice (See SAC104, section 3.6).
Consistent with the SSAC’s recommendation in SAC118, the SSAC believes this guidance should be enforced.
The SSAC recommends the following regarding the feasibility of pseudonymous email contact:

The two policy objectives--namely (1) the ability to quickly and effectively contact the registrant without disclosing personal data, and (2) A common identifier that helps investigators to correlate registrations with common contacts should be considered separately.

To achieve policy objective (A1), registrars should deploy (or continue to deploy) methods to support registrant-based email contact (See section 2.1.2 discussion of the two methods). The SSAC further recommends uniform requirements for safeguards be developed for the registrant-based email contact. The requirements should include maintaining the privacy of the registrant as appropriate and service level commitments to set expectations for the use of the service. These safeguards are independent of the method chosen (e.g., unique email addresses or web-based forms).

To achieve policy objective (A2), additional research is needed on the methods, their efficacy, and their tradeoffs. We recommend the EPDP Phase 2A not specify a method for correlating registrations with a common contact at this time.
The SSAD is a new system proposed to centrally handle requests for non-public registration data, envisioned in Recommendations 1-18 of the Final Report of the GNSO Expedited Policy Development Process (EPDP) on the Temporary Specification for gTLD Registration Data Phase 2.

A well-designed access system will allow requesters with legitimate needs to gain access to non-public data, and to do so reliably, quickly, and inexpensively. At this time, it is uncertain if we can achieve a satisfactory differentiated access control system. Currently, the ICANN Board has requested a six-month Operational Design Phase (ODP) Assessment to inform its deliberations of the policy recommendations. The proposed SSAD does not yet have a scheduled date of delivery. The initial cost estimate has been criticized by the community as too expensive. There is also a lack of definition as to what data will be available to which requesters, and under what circumstances. Finally, Contracted Parties may be performing manual reviews of data requests, because the EPDP was unable to agree on automation cases. Due to the lack of clarity on SSAD, some of the participants in the EPDP appear to be assuming the only data they are likely to access for the foreseeable future is publicly available data, and they are pressing to keep the privacy protection to the minimum required by law. The result is an inability to resolve many questions in the EPDP.
20
7/19/2021 14:49:59Reg Levy
The Tucows family of registrars (Ascio (IANA 106), Enom (IANA 48), EPAG (IANA 85), and Tucows.com, Co. (IANA 69))
No
No, we are not aware of new information or inputs which the Phase 2A team should have but did not consider.
No. This recommendation is not necessary because ICANN Org is already tasked with tracking relevant legislative changes and providing updates to the Community on changes which may impact our policies and the GNSO Council is already expected to consider input or new information from GNSO GS/Cs as well as ICANN SO/ACs when appropriate.
Investment in this work results in very little value other than the ability to track information which we do not think ought to be tracked and, as such, we do not consider it to be in the best interests of the ICANN Community or Internet users as a whole. Harmonization of practices is not a benefit that overrides the drawbacks of excessive data collection and publication. Collection of this data element by either Registrar or Registry MUST always be optional.
If any indication of registrant type is created, there must always be an “unspecified” option.
Setting this data element MUST remain optional for any Contracted Party that chooses to differentiate (and Contracted Parties MUST NOT be required to differentiate.)
As we stated in our answer to Question 7, the work that would be necessary to implement either collection of this field or compliance with the strictures in Recommendation 4, is not a benefit that overrides the drawbacks of excessive data collection and publication.
Although this guidance covers the disclosure to the data subject about how their registration data is used, it does not do so adequately, especially in relation to the effect of differentiation on the publication of that data. It does not cover fundamental data protection requirements. Under the GDPR, the Controller has an obligation to identify and to clearly disclose the purpose of processing, none of which is contemplated in this guidance. There remain significant risks which are not considered in this guidance both to purpose limitation (post-publication processing that may be unknown to both the Controller and the data subject and thus cannot be sufficiently limited—especially in the case of a central SSAD) and storage limitation (when data is public and erasure is required, the Controller has an obligation to inform other Controllers and Processors that the data subject has requested erasure).
Regardless of whether the guidance is accepted or not, those Contracted Parties that choose to differentiate must still conduct in-depth reviews of their own specific legal and regulatory landscapes to ensure that they are fully compliant with those obligations.
If this guidance is intended to be a complete representation of GDPR Principles then it must include: Lawfulness, Fairness and Transparency; Purpose Limitation; Data Minimization; Accuracy; Storage Limitation; Integrity and Confidentiality; and Accountability. This guidance represents significant compromise to these principles. It is not realistic to suggest Community-led modifications, especially since each Contracted Party must still conduct its own legal review regardless of any guidance that may be provided.
Only the GDPR was considered in this guidance. There are many local and international legal and regulatory obligations that may affect a Contracted Party’s ability to differentiate or to adhere to this guidance. The GDPR can be used as a baseline for common practice, which is why we refer to it in our response to the preceding two questions, but each Contracted Party must still conduct its own legal review.
No. The guidance provides some information about processes a Contracted Party should follow as part of adhering to their legal obligations; enforcement of a Contracted Party’s actual legal obligations can only be done by its relevant Data Protection Authority (or other legal authority), not by ICANN Contractual Compliance.
No. It is impossible to encompass all possible legal and regulatory obligations for all Contracted Parties worldwide in one recommendation. It is appropriate for ICANN Org to provide non-binding guidance to aid Contracted Parties, including the legal advice from Bird & Bird to the EPDP Team.
Tucows is dismayed at the frequent and ongoing attempts by non-Contracted Party members of the Community to require that Contracted Parties knowingly put personal data at risk. Tucows appreciates the valiant efforts of the Registrar and Registry Members of the EPDP to prevent such requirements from being drafted into policy.

ICANN Contractual Compliance should never be placed in the position of determining the legality of a Contracted Party’s actions on that Contracted Party’s behalf or to threaten the validity of its contract with ICANN Org because of that Contracted Party’s adherence to its local laws and legal guidance above the relevant ICANN Org contract. Much of the EPDP Phase 2A’s Initial Report attempts to put into the ICANN Org contracts provisions that either force a Contracted Party to break the law to comply with the contract or to obey a law at the determination of ICANN Contractual Compliance.

We are grateful for the opportunity to provide our input to the EPDP Phase 2A’s Initial Report and would like to express our gratitude to all the members of the EPDP Phase 2A Team including the ICANN Staff who supported its ongoing work for their diligent work and long hours.
21
7/19/2021 15:55:31Zoe BonythonRrSGNo
The EPDP Phase 2a WG considered numerous inputs regarding the differentiation between legal and natural persons (see https://community.icann.org/display/EOTSFGRD/Legal+v.+Natural). This included the background briefing paper, ICANN Org study on Legal v Natural, and Bird & Bird legal memos. The RrSG believes that these constitute all relevant information and inputs and that the WG has made an appropriate and informed recommendation to maintain the Phase 1 recommendations on this topic.
The RrSG believes Preliminary Recommendation 2 is unnecessary and indeed misconceived.
This recommendation is unnecessary because Contracted Parties must already comply with applicable laws and regulations as well their contracts with ICANN (which incorporate all Consensus Policies by reference). If NIS2 or any future laws or regulations conflict with existing ICANN contractual requirements, Contracted Parties will have to comply with those laws and regulations, regardless of what the ICANN contractual requirements may be at the time.

This recommendation is misconceived because the GNSO Council has a specific and narrow remit under ICANN Bylaws Section 11.3(d). Nothing in the GNSO Operating Procedures contemplate the GNSO Council taking up the role and responsibility of monitoring

developments in relation to the adoption and implementation of legislative changes, nor is the GNSO Council equipped to do so.

This is a matter for ICANN Org (as confirmed by the GNSO council in their letter https://gnso.icann.org/sites/default/files/file/field-file-attach/gnso-council-to-carver-24jul19- en.pdf, because it is ICANN Org’s responsibility to “identify legislative and regulatory efforts across the globe that may have impacts on ICANN’s contracts with registries and registrars, consensus policies, and policies in effect or in development”.

The RrSG encourages ICANN Org to conduct standardized regulatory impact assessments so that the Community can understand the intended rationale for a law/regulation/directive, specific extracts of the proposed text that could have implications on ICANN’s contracts and Consensus Policies, and outline concretely what implications are anticipated. A timeline should be included so the Community can understand how imminent the law/regulation/directive is and when it is appropriate to take action. Once such a law or regulation has been adopted, ICANN Org should undertake a compliance assessment as soon as possible to ensure sufficient time to address any deficiencies or issues.
For Contracted Parties which choose to differentiate, the RrSG believes that a standardized data element should be available for use but must not be required because it is not an essential part of this optional functionality.

Harmonization of this data element should be available as an option because it provides the benefit of allowing for comparison or sharing of this information across providers.

However, harmonization of this data element can also be problematic because only the Contracted Party themselves can balance the costs against the benefits of using a standardized data element, especially regarding potentially-significant changes to infrastructure.

Additionally, there are concerns about what may occur when a domain is transferred from a registrar that does (or does not) use the standardized element, and how to enforce any obligations (contractually) as well as legal considerations. There may also be gTLDs that do not allow the registration of certain domain names by legal entities without requiring natural person data, leading to further complications for requiring a flag (as well as distinguishing between legal/natural to begin with).
Instead of specifying if the domain owner is a legal person or natural person, the question should be ‘Does the data include natural-person data?’ This is the information that would determine the type of data protection activities which are appropriate (e.g. redaction of data from public RDDS).

The proposed flags are intended to allow the automated publication in RDDS or disclosure via SSAD of legal-person registration data. This is problematic in part because the automatically- disclosed data may contain Personal Data which should be protected, rather than disclosed to all requestors or the public at large. The RrSG members of the EPDP team went into depth on this issue as well as other reasons why differentiation is problematic in general in this article on the topic: Privacy, Legal vs. Natural Persons, and the Never-Ending ICANN EPDP.

There are additional items that need to be addressed before this can be a requirement, such as what happens when a domain name transfers from a registrar that utilizes flags to one that does not (or vice versa): how will the flagged data be treated, what will need to be done to accommodate the flag, will the gaining registrar be obligated contractually and legally to the determinations made by the losing registrar, etc. Because of these complex issues which could result in substantial liability, such flags must remain optional.
As previously indicated, the RrSG believes that a standardized data element should be available for use but must not be required to be used by those Contracted Parties which do choose to differentiate.
The RrSG believes that the current guidance is regrettably not sufficient for a Registrar who wants to differentiate; it can supplement other information and the Registrar’s own internal legal analysis of how best to differentiate, but as a standalone document it does not cover all the required information and does not fully accommodate local-jurisdiction differences or contemplate all effects of possible personal data exposure resulting from incorrect differentiation.

The RrSG appreciates the community effort put into creating this guidance, but in its current form it will likely need to be supplemented with the CPH's own. The CPH would welcome feedback from the community as to whether this further guidance would indeed be useful as well as specific feedback on the guidance we provide when available.
See question 6 response
Members of the RrSG are currently adhering to and working within ICANN to establish ways to comply with GDPR as it currently stands. Other draft regulations, such as NIS2, have components that would potentially, as currently drafted, conflict with legal interpretations of GDPR. Therefore, it would be unwise to prematurely embrace aspects of the draft NIS 2 as it would put registrars at unacceptable liability risk.

As specified in Section 3.7.2 of the RAA (“Registrar shall abide by applicable laws and governmental regulations”), Registrars will conform to any and all laws that come into effect in their jurisdictions, but cannot always anticipate them in advance. Proposed and unadopted laws and regulations should not form the basis of Consensus Policy, as they are subject to significant change before finalization.
The RrSG Representatives (and indeed the EPDP Team as a whole) approached developing this guidance on the understanding that it was to be optional and provided as suggestions for those who find it helpful. Had this been intended as mandatory, we would have needed to approach developing the guidance with a more critical or conservative view, and been less able to accept inclusion of guidance that is not always relevant, feasible, or applicable. As such, the RrSG continues to require that this guidance remains voluntary and our membership does not support it becoming mandatory.
As with the Legal vs. Natural guidance, the RrSG appreciates the community effort put into creating this guidance, but if it stays in its current form it will likely need to be supplemented with the RrSG's own. The the guidance provided here does stand on its own for those Registrars which may choose to publish a registrant-based or registration-based email address in compliance with all relevant data protection laws; however, anything more specific would necessarily be too limited to be useful to Registrars around the world with individual business needs and varying legal/regulatory landscapes. A notification to Registrars that they should consult their own legal counsel or request information from their Data Protection Authority along with sharing the Bird & Bird legal memos does provide valuable assistance while remaining appropriate to the individual recipient of the guidance.

The RrSG would welcome feedback from the community as to whether this further guidance would indeed be useful as well as specific feedback on the guidance we provide when available.
The RrSG is concerned that the guidance the RrSG EPDP team provided on differentiation was not sufficiently incorporated, given CPs are best placed to give it, which is why we’re suggesting supplemented guidance from the CPH or RrSG (see responses to question 6 and 10.)
22
7/19/2021 16:07:46GAC
Governmental Advisory Committee (GAC)
No
[Original and full GAC Comment available at: https://gac.icann.org/statement/public/gac-input-epdp-phase2a-report-19jul21.pdf]

The GAC has concerns that the statement ‘No changes are required’ is not representative of both the substance of the discussion and the positions of the different stakeholders participating in Phase 2A.

During the Phase 2A deliberations to date, the GAC presented relevant statistics and information demonstrating the advantages of having publicly available registration data, in particular data that concerns legal persons. This input included legal considerations on the redaction of registration data that is not personal data (and thus not protected by GDPR) and, inter alia, complaints received from law enforcement authorities and data protection authorities on the unavailability of important information that is essential for these entities to perform their investigative and law enforcement responsibilities, including efforts to combat cybercrime. These considerations have not been properly assessed and accounted for in the EPDP Phase 2A Initial Report and should be included in the Final Report.

More generally (excerpts below are from the Introduction and Overall Comment of the GAC's input):

The GAC appreciates the efforts over the past 6 months and acknowledges the considerable time and commitment by the EPDP Phase 2A team leadership and ICANN support staff to develop these complex and important policy recommendations.

[...]

Regarding the differentiation of legal vs. natural persons' registration data, the GAC believes that Phase 2A has yet to achieve satisfactory results in assessing whether the recommendations from Phase 1 needed an update and this is reflected also in the way the Recommendations of the Initial Report in Phase 2A are phrased.

In summary, we maintain that a process of differentiation, by the Contracted Parties between data of legal persons and data of natural persons needs to be made mandatory. The GAC finds that further focus should now be placed on discussing the public interests and benefits of such differentiation against the known risks.

The Initial Report does not fully reflect the various interests at stake in the discussion on differentiation and the subsequent publication of non-protected information. It is necessary to balance commercial interests with the public interest, including the benefits that publicly available information would have for the stability, security and resilience of the DNS. Future Phase 2A discussions must clearly outline these different interests in order to arrive at an appropriate policy outcome

From the GAC’s perspective, it is essential to recall that the GDPR does not protect the contact information of legal persons. The GAC notes that there has not been an objective and acceptable justification provided so far as to why such unprotected information has been redacted by Contracted Parties in RDS/WHOIS outputs. The GAC believes that further information is needed as Phase 2A discussions continue to assess the benefits to law enforcement and other parties of properly differentiating between data of legal persons and data of natural persons in light of the different risks and costs for Contracted Parties. Based on the legal advice received by Bird & Bird, risks for Contracted Parties would be low so redaction of data not covered by data protection should have suitable justification..

The GAC does not support the phrasing of Recommendation #1:

“No changes are recommended, at this stage, to the EPDP Phase 1 recommendation on this topic (“Registrars and Registry Operators are permitted to differentiate between registrations of legal and natural persons, but are not obligated to do so“).”

The GAC had asked for this Recommendation to be rephrased to capture the reality that no consensus was achieved on this point. The Phase 2A Initial Report should reflect the fact that the majority of stakeholder groups were actually recommending changes and that it was mainly the Contracted Parties and the Non-Commercial Stakeholder Group (NCSG) opposing such changes.

Having said that, the GAC nonetheless believes that any final recommendations need to be implementable.

[...]
[Original and full GAC Comment available at: https://gac.icann.org/statement/public/gac-input-epdp-phase2a-report-19jul21.pdf]

The GAC understands the responsibility of the GNSO but finds that current processes should capture the need for additional policy scoping should new laws or regulations require it. To the extent there is further guidance and legislation that impacts topics within the EPDP the GNSO should be able to act via the existing processes.
[Original and full GAC Comment available at: https://gac.icann.org/statement/public/gac-input-epdp-phase2a-report-19jul21.pdf]

Yes, the final recommendation should require a standardized data element that allows for consistent identification and recording of the nature of the registrant (i.e. natural or legal). The use of this data element would comprise a necessary first step to inform how data should be treated by the Contracted Parties and provides the data subject and all other Contracted Parties processing the data the understanding of how the data is handled or the ability to handle the data in an appropriate manner. Providing this harmonized approach ensures that relevant protection for personal data is considered and applied consistently across all parties responsible for complying with this policy.
[Original and full GAC Comment available at: https://gac.icann.org/statement/public/gac-input-epdp-phase2a-report-19jul21.pdf]

The GAC understands the vast amount of data held by the Contracted Parties and has proposed dealing with new registration data first, and then existing data second, to avoid unduly burdening the Contracted Parties.

As such, before all data has been assessed there is the need for a third value to be used in a new Standardized Data Element and ‘Unspecified’ as proposed in the report would be acceptable. Allowing the value ‘Unspecified’ for this data element as envisioned in the report is a method for qualifying existing data that would not have been subject to a designation of natural or legal person, and the GAC would highlight the need for a timeline so that large proportions of registration data categorised as ‘Unspecified’ do not remain so indefinitely.
[Original and full GAC Comment available at: https://gac.icann.org/statement/public/gac-input-epdp-phase2a-report-19jul21.pdf]

The GAC supports the requirement being a MUST. Allowing contracted parties to decide, on a voluntary basis, which data protection measures to apply to registration data leads to variations in how data protections are handled across all the contracted parties. Voluntary use of the Standardised Data Element is inconsistent with the decisions in the previous phases of the EPDP where measures such as redactions of data were applied to the whole system rather than relying on the contracted parties to interpret which measures to take on data protection.
[Original and full GAC Comment available at: https://gac.icann.org/statement/public/gac-input-epdp-phase2a-report-19jul21.pdf]

Notwithstanding our view concerning Recommendation 1, the GAC welcomes this Recommendation but believes that the information contained in the recommendation should be referred to as “best practice” rather than mere “guidance”.

The output of the EPDP Phase 2A contains important elements of technically- and legally-sound means to ensure the publication of non-personal data. The output would thus effectively support Contracted Parties when implementing the differentiation between legal and natural registrants. Contracted Parties should be encouraged to make use of it.

The GAC considers that the guidance should be used as best practices (for Contracted Parties for differentiating between legal and natural registrants), and that it should be recognised as such.

The GAC has already maintained that the title ‘Best Practices’ would be more appropriate for the outcome of the work carried out under EPDP Phase 2A. The denomination of “Best practices” would also give more weight and visibility to the guidance while increasing the chances of its adoption.
[Original and full GAC Comment available at: https://gac.icann.org/statement/public/gac-input-epdp-phase2a-report-19jul21.pdf]

The Guidance should recognize more explicitly that the differentiation between legal and natural persons is not contrary to the EU GDPR, and indeed in general with data protection legislation, but actually in conformity with such legislation.
It should be highlighted that the protection afforded by the GDPR only applies to natural persons in relation to the processing of their personal data. It does not govern data about companies or any other legal entities. The GDPR protection only applies in cases where that data related to legal persons contain personal data (for example, information in relation to one-person companies may constitute personal data where it allows the identification of a natural person) or for the processing of personal data relating to natural persons in the course of a professional activity, such as the employees of a company/organization The Guidance should state the benefits of differentiating between data of legal persons and data of natural persons, in addition to the risks.
[Original and full GAC Comment available at: https://gac.icann.org/statement/public/gac-input-epdp-phase2a-report-19jul21.pdf]

The GAC notes that there is no legal requirement under the GDPR to protect the data of legal persons and there are benefits for releasing this data to the public.
[Original and full GAC Comment available at: https://gac.icann.org/statement/public/gac-input-epdp-phase2a-report-19jul21.pdf]

This Guidance has been generated to help reduce the risk to Contracted Parties who choose to differentiate. It is not a requirement to follow every item which then can be enforced. The GAC supports EPDP Phase 2A to require differentiation which could then be enforced.
[Original and full GAC Comment available at: https://gac.icann.org/statement/public/gac-input-epdp-phase2a-report-19jul21.pdf]

The guidance is a helpful first step for providing information to Contracted Parties, however more could be added to provide best practices better supporting those who do wish to publish an anonymized registrant-based or registration-based email address.

More generally (excerpt from the Introduction and Overall Comment of the GAC's Input):

[...]

Regarding unique contacts and anonymized emails addresses, the GAC welcomes steps to provide guidance on publishing an email address through the data protection method of anonymization and notes the reduced levels of risk this provides to publication as highlighted in the legal memos received by the EPDP team. However, the GAC calls for further consideration of a recommendation for publication of a uniform anonymized email address in light of the benefits that publication of such emails would provide, and considering the little to no impact experienced by many data subjects when such techniques are used in privacy/proxy services.
[Original and full GAC Comment available at: https://gac.icann.org/statement/public/gac-input-epdp-phase2a-report-19jul21.pdf]

The GAC looks forward to further engagement on whether Phase 2A has the potential to restore access to registration data that is not subject to GDPR.

Some analysis shows that a considerably larger set of registration information was redacted as compared to what is required by GDPR, i.e. “perhaps five times as much as is necessary”. Indeed, available data suggest that only around 11.5% of domains may belong to natural persons who are subject to GDPR, while contact data from 57.3% of all domains was redacted. The GAC believes that the publication of non-public domain name registration data concerning legal entities could increase the wealth of information available to the public and those entities tasked with protecting the public.

The GAC looks forward to engaging in further discussions, including the recently proposed mediation efforts to arrive at a consensus solution.

Full Introduction and Overall Comment to the GAC's Input:

Introduction and Overall Comment

The GAC appreciates the efforts over the past 6 months and acknowledges the considerable time and commitment by the EPDP Phase 2A team leadership and ICANN support staff to develop these complex and important policy recommendations.

The scope of the work under EPDP Phase 2A was to focus on two specific topics, namely: 1) the differentiation of legal vs. natural persons' registration data, and 2) the feasibility of unique contacts to have a uniform anonymized email address.

Under the first topic, the questions to be addressed were as follows:
Whether any updates are required to the EPDP Phase 1 recommendation on this topic (“Registrars and Registry Operators are permitted to differentiate between registrations of legal and natural persons, but are not obligated to do so “);
What guidance, if any, can be provided to Registrars and/or Registries who differentiate between registrations of legal and natural persons.

Under the second topic “feasibility of unique contacts to have a uniform anonymized email address”, the EPDP Team was supposed to address the questions of:
Whether or not unique contacts to have a uniform anonymized email address is feasible, and if feasible, whether it should be a requirement; and,
If feasible, but not a requirement, what guidance, if any, can be provided to Contracted Parties who may want to implement uniform anonymized email addresses.

Regarding the differentiation of legal vs. natural persons' registration data, the GAC believes that Phase 2A has yet to achieve satisfactory results in assessing whether the recommendations from Phase 1 needed an update and this is reflected also in the way the Recommendations of the Initial Report in Phase 2A are phrased.

In summary, we maintain that a process of differentiation, by the Contracted Parties between data of legal persons and data of natural persons needs to be made mandatory. The GAC finds that further focus should now be placed on discussing the public interests and benefits of such differentiation against the known risks.

The Initial Report does not fully reflect the various interests at stake in the discussion on differentiation and the subsequent publication of non-protected information. It is necessary to balance commercial interests with the public interest, including the benefits that publicly available information would have for the stability, security and resilience of the DNS. Future Phase 2A discussions must clearly outline these different interests in order to arrive at an appropriate policy outcome

From the GAC’s perspective, it is essential to recall that the GDPR does not protect the contact information of legal persons. The GAC notes that there has not been an objective and acceptable justification provided so far as to why such unprotected information has been redacted by Contracted Parties in RDS/WHOIS outputs. The GAC believes that further information is needed as Phase 2A discussions continue to assess the benefits to law enforcement and other parties of properly differentiating between data of legal persons and data of natural persons in light of the different risks and costs for Contracted Parties. Based on the legal advice received by Bird & Bird (2), risks for Contracted Parties would be low so redaction of data not covered by data protection should have suitable justification..


Footnotes:
(2) See in particular the discussion of “Legal vs. natural personhood” in the 6 April 2021 Bird & Bird Memorandum at: https://community.icann.org/display/EOTSFGRD/EPDP+-P2A+Legal+subteam?preview=/155191493/161808630/ICANN%20-%20EPDP%20Phase%202a%20-%20Memo%20re.%20VSC%20and%20consent%20options%20-%2020210406.docx
23
7/19/2021 17:19:16Brian KingIPCYesIPC
The IPC takes the position that because WHOIS/RDS data serves the public interest, redaction of legal entity data is not justified by data protection legislation, and because ICANN’s stated purpose in the Temporary Specification was “maintaining the former WHOIS system to the greatest extent possible,” (https://www.icann.org/en/system/files/files/gtld-registration-data-temp-spec-17may18-en.pdf) there is no legitimate basis for the burden to have shifted so that intellectual property owners, law enforcement, and other members of the public must now justify why redacting this data should not be allowed.

The EPDP Phase 1 Final Report (https://gnso.icann.org/sites/default/files/file/field-file-attach/epdp-gtld-registration-data-specs-final-20feb19-en.pdf) contemplates that contracted parties will provide WHOIS data in response to individual requests. Unfortunately, empirical evidence indicates this is not the case. Leading organizations requesting this data from contracted parties for consumer protection purposes report success rates in the range of 10 (https://www.appdetex.com/appdetex-whois-requestor-system-awrs-3/) to 14 (https://clarivate.com/markmonitor/blog/gdpr-whois-and-impacts-to-brand-protection-nine-months-later/) percent, indicating that legitimate requests are often not being considered in good faith. Moreover, in June 2021, the Messaging Malware Mobile Anti-Abuse Working Group (“M3AAWG”) and the Anti-Phishing Working Group (“APWG”) issued a report entitled “ICANN, GDPR, and the WHOIS: A Users Survery – Three Years Later.” The report states that the lack of access to WHOIS data following ICANN’s policy changes in an attempt to comply with the GDPR “continue to significantly impede cyber applications and forensic investigations and thus cause harm or loss to victims of phishing, malware or other cyber attacks.” (https://www.m3aawg.org/sites/default/files/m3aawg_apwg_whois_user_survey_report_2021.pdf) We note that some contracted parties have contended that criminals do not list legal entity data in WHOIS records, but this assertion is irrelevant to the consideration of whether information otherwise available through other public records should be redacted, and unfounded, as there are many instances of businesses infringing on intellectual property rights and other third-party rights online. While consumer protection and IP rights enforcement may be the primary uses of WHOIS data for IPC members, we note that all other legitimate uses (https://whois.icann.org/en/what-whois-data-used) of this data are also impeded when the data is unavailable.

The IPC also notes that making the distinction between legal and natural person data in the RDS is already required by the EPDP Phase 2 Recommendation 9.4.4. This present recommendation would merely make that requirement public. This would also help the public know whether an SSAD request would even be necessary, since the public RDS record would indicate whether the data was redacted because it contained natural person data or merely out of convenience to the registrar.
Yes, this recommendation for the GNSO Council in considering future policy work is necessary because it goes to the essence of the exercise... The Phase 1 and Phase 2 recommendations are predicated on compliance with privacy regulations... The primary regulation of concern is the EU’s General Data Privacy Regulation (GDPR) which formed the basis for analysis in the Temporary Specification and the Phase 1 and Phase 2 deliberations of the EPDP... While the EU has been the focus, there are many jurisdictions that have passed, or are considering passing, sweeping privacy laws, including Brazil, India and the U.S., to name but a few... Each and all of those laws could have effects on how data collection, access and processing are implemented through ICANN policy... The GDPR has been the main focus because of its extraterritorial reach. Further, the EU privacy standard, which essentially recognizes that individuals have a right to control their personal data( with some notable exceptions including for law enforcement and the performance of certain contracts) is viewed as a “gold standard” for privacy... With all of that said, the GDPR is very clear that the data of legal persons is exempt from the regulations... ICANN has chosen an interpretation of GDPR that goes far beyond the intention of the law… The confusion surrounding the issues of data collection from legal persons and the responsibility of accuracy has reached the such a heightened level that the European Union has proposed clarifications... They come within the context of its pending Directive on Cybersecurity known as NIS2... The proposals in Article 23 specifically address the open issues within the EPDP, and most particularly Phase 2 A... Monitoring the progress of the legislation, due for a vote on October 14th 2021, is critical to ICANN and the GNSO “getting it right”.

The NIS2 proposals affirm the applicability of GDPR and state unequivocally in proposed Article 23.4: “Member States shall ensure that the TLD registries and the entities providing domain name registration services for the TLD publish, without undue delay after the registration of a domain name, domain registration data which are not personal data.” It is further clarified in the preceding Article 23.3 that such data must be accurate ... The passing of this regulation will undoubtedly influence the work of the EPDP because there will be no doubt as to whether publishing the data of legal persons is optional... If the legislation passes, the publication of data of legal persons will not be optional, and must be accurate, which means accountability for ensuring accuracy will fall to those providing a domain name service as noted in NIS2 Article 4...

The policy discussions taking place within the ICANN community are not taking place in a bubble; they are a response to consequential, external regulation that continues to evolve... Failing to monitor the situation is a failure of due diligence... The GNSO can facilitate the monitoring of legislative initiatives through mechanisms that are already in place at ICANN, most notably, through its relationships with the GAC, ICANN Org’s government engagement team, and the Cross Community Engagement Group on Internet Governance (CCWGIG)... The GAC, Org and CCWGIG all have sponsored information sessions on pending legislation... Many GNSO councilors come from organizations that have mechanisms in place for such monitoring as well. These are all substantial resources, which, when fully utilized, ease the burden of tracking initiatives independently.
Yes. A standardized data element should be defined and be required to be published by Contracted Parties. Given future regulation (e.g., NIS2) that will require the distinction of legal and natural persons, a standardized RDS data element will ensure a consistent mechanism for RDS users to reliably ascertain if a Registrant is a legal or natural person.
The IPC believes that the “Registrant Legal Person” data element must be collected and published. We believe that Contracted Parties must be obligated to differentiate between registrations of legal and natural persons; if Contracted Parties are not obligated to do so, the existence of this field must still be required. In the case where a Contracted Party decides not to differentiate, the value of this field should be set to “Unspecified”.
This new data field is not personal information and thus must be published in the public RDDS. Redacting this new data field and using a disclosure mechanism (SSAD or otherwise) would be inappropriate.
Yes. A Contracted Party who differentiates must use this standardized data element. Allowing 2000 registrars to determine how this data should be displayed in the RDDS would be conflict with recent RDS policy work to ensure a consistent labeling and display of RDS data to RDS users.
The usefulness of a flagging mechanism was discussed in both the Phase 2 and Phase 2a EPDP discussions. In particular the use of a flag is important to streamline the processing of disclosure requests – be they performed manually or automated via a system such as the SSAD. For example, a flag can be updated once a disclosure request has been processed and the nature of the registration (legal vs. natural) and the absence or presence of personal information has been determined.
n/a
Registries and registrars should consider the benefits of embracing a minimum voluntary (binding through ICANN compliance) threshold for differentiation in the interest of eliminating the need for varying legislation across the various jurisdictions where they operate, which are sure to have different standards, requirements, and associated penalties for noncompliance. Registries and registrars should not invite a complex patchwork of regulation on a topic as simple as agreeing not to apply data protection measures where such measures have no legal justification. We invite registries and registrars to consider NIS 2 as the merely the first legislative development among others which may follow if they choose not to self-regulate as suggested by the European Commission via the GAC.
This should not be guidance. There should be a requirement to differentiate.
As an initial matter, the IPC is strongly in favor of a mandatory registrant-based email contact in public WHOIS data to facilitate cross-domain correlation, which as noted is essential for law enforcement and cybersecurity efforts, as well as online IP enforcement (which often overlaps with anti-phishing and similar anti-abuse efforts). As noted in the Bird & Bird Memoranda, in its Whois database, EURid publishes the email addresses of domain name registrants in the .eu TLD (both natural persons and legal entities). Similarly, RIPE-NCC publishes contact information, including email addresses, for its IP Address allocation recipients. We believe these approaches demonstrate the limited GDPR risk to Contracted Parties in publishing a registrant-based email contact in public WHOIS, so long as relevant registration agreements outline the legitimate purposes of such publication. We appreciate that publication of registrant-based email contacts is not the lowest possible degree of GDPR compliance risk, as outlined in the Bird & Bird Memo, but is also not flagged as a high risk. The several benefits of this approach for many parties in the ICANN community, as well as in serving ICANN’s own security, stability, and resiliency mission, easily counterbalance the potential risks.

Another concern raised is the possibility of using registrant-based email contacts for SPAM. We agree this is a reasonable concern, but question whether the desire to minimize SPAM email is on par with the ability to more effectively address networks of abusive domain names engaging in phishing, malware, fraud, or other abuse, which would be hugely improved through the availability of registrant-based email contacts. Systems are already in place to mitigate harvesting of public email addresses for SPAM, such as Captcha, and recipient email systems already engage fairly powerful filters to prevent true SPAM email from reaching domain name registrants. That said, we would support a registrant-based ID number that would allow cross-domain correlation without also serving as a direct point of contact to the registrant, which can continue to be served by a registration-based email or web form under current policy.

Per the above, we do not believe the EPDP’s recommendation here is appropriate. Nonetheless, if the EPDP Team refuses to reconsider the importance of publishing a registrant-based email contact or ID number, despite the relatively low risk of GDPR non-compliance compared to the substantial benefits to WHOIS users, the guidance provided by the Bird & Bird Memo MUST be distilled into more easily-implementable requirements and steps for any Contracted Parties who would voluntarily publish a registrant-based or registration-based email contact. As it stands, the Memo is disappointingly legalistic and formalistic, and does not provide much practical utility for creating or modifying technical systems. We would suggest the EPDP Team digest the legal guidance into a brief process / risk-assessment guide that Contracted Parties can more easily rely on should they wish to implement a registrant-based email contact approach.
24
7/19/2021 17:37:03Alan GreenbergN/AYesALAC
The ALAC objects to this recommendation. This is NOT a consensus recommendation and it must not be implied that it is.

Phase 2A team has not considered the public interest in assessing whether or not CPs are obligated to differentiate between legal and natural persons. The RDDS data is a public good associated with protecting the public as the GDPR and similar laws are a public good associated with protecting the data of the registrants. Therefore a balance between those two public goods is necessary. This balance cannot be achieved if more data is redacted than required by GDPR. The relative value of the availability of more RDDS data through differentiation should be evaluated against the relative value of ensuring registrant's personal data remain protected to the fullest extent mandated by GDPR. This line of thought is also consistent with possible new laws and legislation.
Perhaps it should not be needed, but given the high workload of the GNSO and the importance of this issue to many in the ICANN community and elsewhere, it is prudent to formally require that the GNSO do this.
Yes a standardized data element should be available for contracted parties to use because:

- A standardized data element is consistent with ICANN RDDS consistent labeling and Display consensus policy. The goal of the RDDS Consistent labeling and Display Policy is to align the way registries and registrars Label and Display registration data outputs.

- Data standardization improves the quality of the data, it creates consistency across the systems and makes it easy to use.

- It is possible that L/N differentiation may be necessary in the future, and formulating this element now means we will not need another PDP to create it at that time. In addition, according to the recommendations of EPDP phase one team, CPs are already going to make modifications to the existing fields, therefore adding this standardized data element during the implementation of EPDP phase one recommendations makes sense.

- Some registrars MAY choose to do differentiation, and having this element allows the SSAD or other tools to know that the distinction is made.
The field should specify whether the Registrant is a legal or natural entity. If the registrar chooses to not differentiate, or if the value is not known for whatever reason, the field is left blank.

- If the registrar differentiates, the field MUST be used for those registrations where differentiation is made.

- The data element MAY be transferred to Registries.

- The data element MUST be transferred to escrow providers if it is used for the particular registration (both registrars and registries).

- The Data element MUST be provided to the SSAD (or equivalent) and MUST be published in the public RDDS (not that these are two separate issues).
As noted above a standardized data element is consistent with ICANN RDDS Consistent Labeling and Display consensus policy. The goal of the RDDS Consistent labeling and Display Policy is to align the way registries and registrars Label and Display registration data outputs. Not obligating CPs who would like to differentiate between the data of legal and natural persons to use the standardized data element is in contradiction with the intent of the above-mentioned ICANN consensus policy and defies the logic behind the existence of a standardized data element. It is also worth noting that according to the recommendations of EPDP phase one team, CPs are going to make modifications to the existing fields, therefore adding this standardized data element during the implementation of EPDP phase one recommendations makes sense.

Therefore, the ALAC believes that if there is an element, it MUST be populated for registrations where a differentiation is made.
Obviously 3. Should be adjusted if based on the results of deliberations on questions 3-5.
N/A
The EU NIS2 may be approved by the EU Council and/or parliament by the time the final report is published. Any such decisions MUST be factored into the report, even if the timing of the report must be altered. For avoidance of doubt, if at the time of publication, there is more specificity on NIS2, it MUST be factored into the report.
No.
No, the report or additional information provided during implementation should give specific examples and best practices.
At this point, most registrars use web forms and some such forms do not allow a user to provide sufficient information to the registrant. The web form specifically must allow “communication” and not just a very small number of selected tick-options. The communications must include setting the majority of the resultant Subject Field and at the very least provide a minimal (256 characters perhaps) of text. The ALAC understands the need to NOT facilitate spam and these requirements do just that.

The ALAC believes that arguments that this or other issues such as the RDDS Legal/Natural element is out of scope for this PDP are mis-directed and incorrect. We are still operating under a Charter that FULLY covers all issues discussed within the full EPDP. Moreover, a narrow focus on a quasi-charter as set out in a GNSO Council letter sacrifices good and functioning policy for the sake of arbitrary rules. Some have said that not following rules leads to chaos. The chaos associated with poor and ill-functioning policy is far worse.
25
7/19/2021 18:43:34Owen SmigelskiNamecheap, Inc.No
Namecheap supports the RrSG’s comment that the EPDP Phase 2a WG considered all relevant information and inputs, and that no additional information or inputs should be considered for Phase 2a. This included inputs regarding the differentiation between legal and natural persons, including the background briefing paper, ICANN Org’s study on Legal vs. Natural, and the Bird & Bird legal memos. Any documents that are considered drafts (such as NIS2) should not be considered prematurely as they are subject to change (and may not even be adopted).
Namcheap does not believe that this recommendation is necessary. The GNSO “fashions (and over time, recommends changes to) policies for generic Top-Level Domains (e.g., .com, .org, .biz). The GNSO strives to keep gTLDs operating in a fair, orderly fashion across one global Internet, while promoting innovation and competition.” (see https://gnso.icann.org/en/about). This limited function does not include monitoring legislation or other obligations around the world. Additionally, ICANN Org already has a dedicated team that “is responsible for leading engagement and outreach with stakeholders on ICANN and its Mission around the world” (https://www.icann.org/resources/pages/gse-2012-02-25-en). As of FY18 (the last information accessible on icann.org), ICANN’s Global Stakeholder Engagement (GSE) team comprises 34 staff in 21 countries. ICANN Org should leverage the GSE team to monitor global legislative changes that will impact ICANN policies, and inform the GNSO Council accordingly.

Namecheap notes that the GNSO Council should not consider draft proposals such as NIS2, but should only consider those laws or regulations when they become enforceable (and may impact an ICANN consensus policy). Namecheap notes that under Section 3.7.2 of the RAA, registrars must “abide by applicable laws and governmental regulations” and will comply with such laws and regulations well before the GNSO Council has to develop or modify policy to comply with laws or regulations.
Namecheap believes that if Contracted Parties choose to differentiate between legal and natural persons, then a standardized element should be available- however there should be no obligation to use the standardized element or in which manner the element should be used.

Although multiple versions of flags were supported by several of the participants in EPDP Phase 2a, they were from SO/ACs that do not provide registrar or registry services. Making changes to systems to allow for the use of a standardized data element can be a significant undertaking- potentially requiring hundreds (if not thousands) of people hours. While most registrars and registries have sufficient resources to accomplish such a technical undertaking, this would provide absolutely no benefit to domain name registrants. Even for registrars that were to implement such a standardized element, the time to develop and implement would be measured in many months because a significant amount of resources and systems could be impacted (internal and external).

Such cost implications must be balanced against benefit to registrants when deciding whether or not to require something through an ICANN policy. Additionally, some registrars (including Namecheap) have estimated that no more than 15% of domain name registrants are by legal persons and thus such a change will affect a very small number of domain name registrations. Finally, a number of the SO/ACs that advocate for requiring this standardized data element for legal persons do so ostensibly to “reduce DNS abuse”. This is an absurd position, as Namecheap is not aware of any DNS abuse actors that utilize legal persons to register domain names for their abuse campaigns (nor did EPDP team participant provide a real-world example of this during EPDP Phase 2a).

The contracted parties repeatedly raised these concerns during EPDP Phase 2a, however it appears that these real-world concerns were dismissed as this issue is still being considered. It is disheartening to see the actual consequences and impact of these policy considerations be discounted despite the good faith participation of the CPH in this policy process.

For the reasons provided above, the costs far outweigh any benefit and thus should remain completely optional.
Namecheap supports the RrSG position that instead of specifying if the domain owner is a legal person or natural person, the question should be “Does the data include natural-person data?” This is the information that would determine the type of data protection activities which are appropriate (e.g. redaction of data from public RDDS). Legal person data can (and often does) include natural person data which in some situations should not be disclosed.
Please see the article published by the RrSG members of the EPDP team which considered this issue in depth: https://www.circleid.com/posts/20210607-privacy-legal-vs-natural-persons-and-never-ending-icann-epdp/
Please see Namecheap’s response above to question 3.
Namecheap supports the RrSG position that the current guidance is regrettably not sufficient for a Registrar which chooses to differentiate. This guidance can be a starting point, but is not a substitute for the Registrar’s own legal analysis and taking into consideration the various jurisdictions that the Registrar may be subject to enforcement of laws and regulations. Registrars are located in countries around the world, and may be subject to regional (e.g. the EU), national (e.g. Brazil), and local (e.g. California) regulations that need to be considered before differentiating (and potentially releasing the data). Some Registrars may focus solely on a specific local customer base, whereas others may market their services worldwide. The guidance required for such a diverse cross-section of Registrars exceeds what is in the Initial Report.

Namecheap additionally supports the RrSG position that the RrSG is best positioned, with extensive legal analysis and experience on these very issues across many jurisdictions, to propose guidance. Namecheap will participate in any RrSG effort to draft additional guidance to contracted parties regarding differentiation.
See Namecheap’s response above to question 6.
As indicated in Namecheap’s response above to question 1, Namecheap does not believe additional legal and regulatory considerations should be considered for this Initial Report. While registrars must abide by applicable laws and governmental regulations under Section 3.7.2 of the RAA, registrars must comply with adopted/effective laws and regulations- not ones that are under consideration or not yet in force.
Namecheap supports the RrSG’s position on this question: this entire EPDP Phase 2a was approached as developing guidance that would be optional and provided as suggestions for those entities which find it helpful. Had the deliberations considered mandatory guidance, then feedback and requirements of the RrSG (and other SO/ACs) would have been different. Making this last-minute change to the guidance would prejudice registrars, who would be bound by requirements that may not align with legal obligations. The guidance should remain voluntary.
Namecheap agrees with the RrSG comment on this question: “…the guidance provided here is regrettably not sufficient on its own for a Registrar who wants to publish a registrant-based or registration-based email address while maintaining full compliance with all relevant data protection laws; however, anything more specific would necessarily be too limited to be useful to all Registrars with their individual business needs and legal/regulatory landscapes.” Registrars should also consult their own legal counsel and consult any applicable data protection authorities (along with the Bird & Bird legal memos) which should provide additional guidance that will ensure the Registrar complies with applicable laws and governmental regulations. Additionally, similar to the Legal vs. Natural guidance, additional input from the RrSG is necessary to ensure comprehensive guidance. Namecheap is willing to participate in drafting this additional RrSG guidance.
Along with the RrSG, Namecheap is concerned that guidance, feedback, and recommendations from the CPH were not fully incorporated within this Interim Report. These positions came from legal and technical realities, and not from a wish or desire to change the status quo (as was much of the feedback from other SO/ACs). As those SO/ACs appear unwilling to consider the realities facing contracted parties, it is not constructive to discuss these issues further.
26
7/20/2021 9:40:40luis suarezno haveNonoyesokbeneficial*6yesall goodno no standyesyesvery good tool
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100