<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
"http://www.w3.org/TR/REC-html40/loose.dtd">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<title></title>
</head>
<body style="font-family:Arial;font-size:14px">
<p>Then we are in agreement. Option 1 – no guidance.<br>
<br>
I support the arguments Milton laid out below. I’m sure Stephanie and Manju will have more arguments and support.<br>
<br>
In just a few minutes, in the NCUC Webinar, Farzi will lead a discussion of “how to develop a policy position” for our community at ICANN. This is how it’s done – together, with a lot of discussion, and people listening to the substance, issues and concerns.<br>
<br>
And people spending enormous time in the policy development process working groups like EPDP.<br>
<br>
Huge thanks to Stephanie, Manju, Milton, our NCSG. <br>
<br>
Best, Kathy<br>
<br>
Quoting "Mueller, Milton L" <<a href="mailto:milton@gatech.edu">milton@gatech.edu</a>>:<br>
<br>
> Actually, this is a fairly convincing argument,<br>
><br>
> If we as a matter of policy create guidance, it will be examined by<br>
> any DPA investigating a complaint about the SSAD. The co-controllers<br>
> will be held accountable for whether or not they adhere to it. It<br>
> may be reference in the Registrars Accreditation Agreements,<br>
> negotiations for which are going on as we argue about this. There is<br>
> no reason that I can see to include the guidance that has been<br>
> developed in our policy, I do not agree that this particular ship has<br>
> sailed. As far as I am concerned, it is still in drydock.<br>
><br>
> OK, so finally you are confronting the issue of Guidance. Although I<br>
> think your reasoning about DPAs is invalid, “No change, no guidance”<br>
> is a coherent position – ASSUMING the ship has not sailed. So are you<br>
> prepared to come to the EPDP meeting tomorrow, and announce with me,<br>
> that NCSG are abandoning the ship, and no longer want to see any<br>
> guidance developed? I will go along with that, once/if we receive<br>
> confirmation from the PC or the vote of this list.<br>
><br>
> We can justify our shift in the following way:<br>
><br>
> 1. If there is guidance, NCSG have proven to be completely<br>
> unable to agree on what it should be. It is safer for Registrants not<br>
> to have any, and rely on market choices among CPs to protect<br>
> registrants<br>
><br>
> 2. We are concerned about legal obligations or liabilities that<br>
> might be incurred by registrants self-identification as a company or<br>
> legal person.<br>
><br>
> 3. We don’t want the guidance to be mandatory, but if it’s not<br>
> mandatory why do we need it?<br>
><br>
> 4. There is a chance that it might become a de facto standard<br>
><br>
> So I cast my vote: NO on guidance (yes this is a shift)<br>
><br>
> Now tell me what you propose to do if they go ahead and develop<br>
> guidance? Here is what you say:<br>
><br>
> What we have been discussing in the EPDP is the guidance that the<br>
> registrars have already developed on a voluntary basis. We can<br>
> simply leave them to do this. There is no need to treat the<br>
> deliberations of this EPDP as holy writ that cannot be set aside, we<br>
> have debated all kinds of nonsense over the past three years. <br>
> Putting it in a google doc does not mean it cannot land on the<br>
> cutting room floor.<br>
><br>
> This would be a fail, in my opinion. If the CPs develop guidance, it<br>
> will become part of the Phase 2a report. All the arguments you make<br>
> against guidance would still apply. A more desirable idea is that we<br>
> get the CPs to abandon guidance as well, or at least enough of them<br>
> to block consensus. From Volcker’s statement on behalf of Registrars<br>
> I got the idea they are going along with guidance because they think<br>
> everyone wants it.<br>
> --MM<br>
><br>
><br>
><br>
><br>
><br>
> This chart provides guidance for how a Registrar could comply with<br>
> GDPR principles in each of the three example scenarios (see section<br>
> below), along with some notes about risks present for various options.<br>
><br>
><br>
> Principle<br>
><br>
> Data subject self-identification at time of data collection resulting<br>
> in publication of non-personal data<br>
><br>
> Data subject self-identification after initial data collection<br>
> resulting in publication of non-personal data<br>
><br>
> Registrar determines type based on data provided resulting in<br>
> publication of non-personal data<br>
><br>
> Lawfulness, Fairness and Transparency:<br>
><br>
> Controller must identify their legal basis (or bases) for processing<br>
> data and ensure the data subject is aware of the processing prior to<br>
> when it occurs. If the legal basis is consent, then consent must be<br>
> obtained prior to the processing.<br>
><br>
><br>
> See also:<br>
><br>
> Transparency: RAA 3.7.7.4<br>
><br>
> Consent: RAA 3.7.7.5<br>
><br>
> Identify and document legal basis for each processing activity<br>
> (collection, retention, publication, erasure); provide explanation to<br>
> data subject when data is collected and data subject selects person<br>
> type.<br>
><br>
><br>
> Risk: Data subject identifies person type/provides consent on behalf<br>
> of a third party (Bird & Bird Memo II on Consent)<br>
><br>
> Identify and document legal basis for each processing activity<br>
> (collection, retention, publication, erasure); provide explanation at<br>
> the time when data subject self-identifies (post collection) and when<br>
> option to change or correct self-designation is provided.<br>
><br>
><br>
> Risk: Data subject identifies person type/provides consent on behalf<br>
> of a third party (Bird & Bird Memo II on Consent)<br>
><br>
> Identify and document legal basis for each processing activity<br>
> (collection, retention, publication, erasure); provide explanation at<br>
> the time when data is collected and person type is inferred.<br>
><br>
><br>
> Risk: Registrar identification post-collection does not allow for<br>
> pre-processing disclosure to data subject.<br>
><br>
> Purpose Limitation: Controller must ensure that data is not processed<br>
> beyond the purposes disclosed to the data subject<br>
><br>
><br>
> See also: RAA 3.7.7.4.1, 3.7.7.4.2, EPDP Phase 1 and Phase 2 Addendum<br>
> Purposes<br>
><br>
> All relevant processing activities (including post-publication<br>
> activities) must be included in the explanation to the data subject.<br>
><br>
><br>
> Risk: post-publication processing may be unknown to both the<br>
> controller and the data subject and thus cannot be adequately<br>
> disclosed<br>
><br>
> All relevant processing activities (including post-publication<br>
> activities) must be included in the explanation to the data subject.<br>
><br>
><br>
> Risk: post-publication processing may be unknown to both the<br>
> controller and the data subject and thus cannot be adequately<br>
> disclosed<br>
><br>
> All relevant processing activities (including post-publication<br>
> activities) must be included in the explanation to the data subject.<br>
><br>
><br>
> Risk: post-publication processing may be unknown to both the<br>
> controller and the data subject and thus cannot be adequately<br>
> disclosed<br>
><br>
> Data Minimisation:<br>
><br>
> Controller must ensure that no data is collected/processed beyond<br>
> what is required to achieve the identified purpose(s)<br>
><br>
><br>
> See also: RAA 3.7.7.4.3, EPDP Phase 1 exercise justifying all data<br>
> elements collected<br>
><br>
> Only the minimum required data must be collected and published.<br>
><br>
> Only the minimum required data must be collected and published.<br>
><br>
> Only the minimum required data must be collected and published.<br>
><br>
> Accuracy:<br>
><br>
> Controller must take all reasonable steps to ensure data subject can<br>
> keep person type data updated and accurate<br>
><br>
><br>
><br>
> See also: WHOIS Accuracy Program Specification<br>
><br>
> Allow the data subject to provide person type information and make<br>
> updates when needed.<br>
><br>
> Allow the data subject to provide person type information and make<br>
> updates when needed.<br>
><br>
> Allow the data subject to view their inferred person type designation<br>
> and make updates when needed.<br>
><br>
><br>
> Risk: registrar incorrectly infers data subject person type,<br>
> resulting in improper publication of natural person data<br>
><br>
> Storage Limitation:<br>
><br>
> Controller must retain data only as long as is necessary for the<br>
> purposes for which the data are processed<br>
><br>
><br>
> See also: RAA 3.4, EPDP Phase 1 data retention requirement<br>
><br>
> Ensure that personal data is erased as soon as it is no longer<br>
> required to fulfill the processing purposes<br>
><br>
><br>
> Risk: When data is public and erasure is required, controller has<br>
> obligation to inform other controllers that the data subject has<br>
> requested erasure.<br>
><br>
> Ensure that personal data is erased as soon as it is no longer<br>
> required to fulfill the processing purposes<br>
><br>
><br>
> Risk: When data is public and erasure is required, controller has<br>
> obligation to inform other controllers that the data subject has<br>
> requested erasure.<br>
><br>
> Ensure that personal data is erased as soon as it is no longer<br>
> required to fulfill the processing purposes<br>
><br>
><br>
> Risk: registrar incorrectly infers data subject person type,<br>
> resulting in disclosure of data which cannot be recalled and<br>
> redacted; when data is public and erasure is required, controller has<br>
> obligation to inform other controllers that the data subject has<br>
> requested erasure.<br>
><br>
> Integrity and Confidentiality: Controller must process personal data<br>
> in a way that ensures security, protects against unlawful processing<br>
><br>
><br>
> See also: RAA 3.4.1 “securely maintain, in its own electronic database…”<br>
><br>
> Ensure that only non-personal data is published<br>
><br>
> Ensure that only non-personal data is published<br>
><br>
> Ensure that only non-personal data is published.<br>
><br>
><br>
> Risk: publishing personal data due to mis-identification<br>
><br>
> Accountability:<br>
><br>
> Controller must be able to demonstrate that they comply with GDPR Principles<br>
><br>
> Document processing activities with explanation of how the chosen<br>
> implementation complies with GDPR Principles for processing data<br>
><br>
> Document processing activities with explanation of how the chosen<br>
> implementation complies with GDPR Principles for processing data<br>
><br>
> Document processing activities with explanation of how the chosen<br>
> implementation complies with GDPR Principles for processing data<br>
><br>
><br>
><br>
><br>
><br>
> Example scenarios<br>
><br>
><br>
><br>
> The EPDP Team has identified three different high-level scenarios for<br>
> how differentiation could occur based on who is responsible and the<br>
> timing of such differentiation. It should be noted that other<br>
> approaches and/or a combination of these may be possible.<br>
><br>
><br>
><br>
> 1. Data subject self-identification at time of data collection /<br>
> registration<br>
><br>
> a. The Registrar informs the Registrant (per guidance #3 above)<br>
> and requests the Registrant (data subject) at the moment of<br>
> Registration data collection to designate legal or natural person<br>
> type. The Registrar must also request the Registrant to confirm<br>
> whether only non-personal data is provided for legal person type.<br>
><br>
> b. If the Registrant (data subject) has selected legal person<br>
> and has provided a confirmation that the registration data does not<br>
> include any personal data, the Registrar should (i) contact the<br>
> provided contact details to verify the Registrant claim (ii) sets the<br>
> registration data set to automated disclosure in response to SSAD<br>
> queries and (iii) Ppublishes the data (to provide Registration Data<br>
> in the publicly accessible Registration Data Directory Services).<br>
><br>
> c. If the Registrant (data subject) has selected natural person<br>
> or has confirmed that personal data is present, the Registrar does<br>
> not set that registration data to automated Disclosure and<br>
> Publication, unless the data subject consents to Publication.<br>
><br>
> d. If the Registrant (data subject) makes any substantive<br>
> change to the registration data, the Registrar is expected to confirm<br>
> that these updates do not result in changes to the registrant type or<br>
> the previous confirmation of whether only non-personal data is<br>
> provided for legal person type. If the updates do result in changes,<br>
> Registrar must repeat Steps a-c above.<br>
><br>
><br>
><br>
> 2. Data subject self-identification after initial collection<br>
><br>
> a. The Registrar collects Registration Data and provisionally<br>
> redacts the data.<br>
><br>
> b. The Registrar informs the Registrant (per guidance #3 above)<br>
> and requests the Registrant (data subject) to designate legal or<br>
> natural person type. The Registrar must also request the Registrant<br>
> to confirm whether only non-personal data is provided for legal<br>
> person type.<br>
><br>
> c. Registrant (data subject) indicates legal or natural person<br>
> type and whether or not the registration contains personal<br>
> information after registration is completed. For example, the<br>
> Registrant may confirm person type at the time of initial data<br>
> verification, in response to its receipt of the Whois data reminder<br>
> email for existing registrations, or through a separate notice<br>
> requesting self-identification.<br>
><br>
> d. If the data subject identifies as a legal person and confirms<br>
> that the registration data does not include personal data, the<br>
> Registrar should (i) contact the provided contact details to verify<br>
> the Registrant claim (ii) (i) sets the registration data set to<br>
> automated disclosure in response to SSAD queries and (iii) pPublishes<br>
> the data.<br>
><br>
><br>
><br>
> 3. Registrar determines type based on data provided<br>
><br>
> a. The Registrar collects Registration Data and provisionally<br>
> redacts the data.<br>
><br>
> b. The Registrar uses collected data to infer legal or natural<br>
> person type.<br>
><br>
> c. If legal person is inferred by the Registrar and<br>
> subsequently the Registrant (data subject) is informed (per guidance<br>
> #3 above) and confirms that no personal data is present, the<br>
> Registrar should (i) contact the provided contact details to verify<br>
> the Registrant claim (ii) (i) sets the registration data set to<br>
> automated disclosure in response to SSAD queries and (iii) Ppublishes<br>
> the data.<br>
><br>
> d. If the Registrar has inferred natural person or has detected<br>
> personal data, the Registrar must not disclose registration data<br>
> unless the Registrant provides consent for publication or the<br>
> Registrar Discloses the data in response to a legitimate disclosure<br>
> request.<br>
><br>
><br>
> Registrars shall not be prohibited from voluntarily utilizing a third<br>
> party to verify that a registrant has correctly identified its data,<br>
> provided that provided such verification is compliant with applicable<br>
> data protection regulations.<br>
><br>
><br>
> The EPDP Team recognizes that in all of the above scenarios, there is<br>
> the possibility of misidentification, which may result in the<br>
> inadvertent disclosure of personal data. In this regard, Bird &<br>
> Bird<<a href="https://community.icann.org/download/attachments/155191493/ICANN%20-%20EPDP%20Phase%202a%20-%20Memo%20re.%20VSC%20and%20consent%20options%20-%2020210406.docx?version=1&modificationDate=1617804552000&api=v2" target="_blank">https://community.icann.org/download/attachments/155191493/ICANN%20-%20EPDP%20Phase%202a%20-%20Memo%20re.%20VSC%20and%20consent%20options%20-%2020210406.docx?version=1&modificationDate=1617804552000&api=v2</a>> has noted the<br>
> following:<br>
><br>
><br>
><br>
><br>
><br>
> 11.11.1 If the (person representing the) Registrant incorrectly<br>
> characterises personal data as non-personal, then the verification<br>
> process this triggers should confer reasonable protection against<br>
> GDPR Accuracy Principle liability for Contracted Parties, as<br>
> explained at paragraph 11.7 above, as might the legal argument set<br>
> out at paragraph 11.8 above.<br>
><br>
> 11.11.2 Alternatively, if the (person representing the) Registrant<br>
> incorrectly characterises non-personal data as personal data, then<br>
> whether or not they subsequently consent to its publication, the data<br>
> would still not actually be personal data, so GDPR liability cannot<br>
> arise.<br>
><br>
><br>
> (…)<br>
><br>
><br>
> 13. However, in our view the risk to Contracted Parties seems low, if<br>
> they take the measures described in the question presented, to avoid<br>
> personal data being (or if reported, staying) published in<br>
> Registration Data.<br>
><br>
><br>
> (…)<br>
><br>
><br>
> 14.3 The data in question is likely to be low sensitivity. The<br>
> scenario being envisaged here (mistaken inclusion of personal data in<br>
> published Registration Data) seems to be most likely to occur when a<br>
> legal entity (e.g. a company or non-profit organisation) is<br>
> registering / maintaining its own domains. In those scenarios, we<br>
> assume the personal data that could be disclosed would ordinarily<br>
> relate to an employee’s work details (e.g. a company email address),<br>
> not an individual’s private life. Although the GDPR confers<br>
> protection even in the workplace, the data in question here may<br>
> arguably be less capable of causing harm to an individual than data<br>
> relating to the data subject’s private life.<br>
><br>
><br>
> (…)<br>
><br>
><br>
> 18. We cannot exclude the possibility of some courts or regulators<br>
> seeing things differently. Even then, an order to correct the issue<br>
> (likely accompanied by a reasonable period in which to implement<br>
> changes), rather than a fine, seems most likely, having regard to the<br>
> GDPR Article 83(2) factors discussed at paragraph 8 above. Having<br>
> checked in a selection of Member States, we can find no examples of<br>
> enforcement in relation to this. Accordingly, there is little<br>
> guidance available besides what is set out in the GDPR itself.<br>
><br>
><br>
><br>
> On 2021-05-05 12:01 p.m., Mueller, Milton L wrote:<br>
><br>
> Kathy,<br>
><br>
>> You have given us options and we chose not to differentiate legal<br>
>> and natural persons.<br>
><br>
> Sorry if you misinterpreted this. As I explained, no differentiation<br>
> is _not_ an option anymore.<br>
><br>
> The actual choice is, Do contracted parties get to decide entirely on<br>
> their own whether and how to differentiate? Or do we offer them<br>
> guidance?<br>
><br>
>> . As Stephanie says, “The moment you drag anything into policy, it<br>
>> will become mandatory.”<br>
><br>
> Nope. The EPDP will develop guidance. After it does so, there will be<br>
> a vote on whether it should be mandatory or not. We, the CPs, and<br>
> ISPs will vote against that, the other crew will vote for it. There<br>
> will not be consensus, ergo it will not be mandatory. There is no way<br>
> guidance that has been explicitly deemed not mandatory can suddenly<br>
> become mandatory without a new PDP.<br>
><br>
> Technically, it is possible for NCSG to suddenly turn against<br>
> offering any guidance, but I don’t think there is NCSG support for<br>
> that. Both Manju and I have opposed it. Anyone else on the EPDP care<br>
> to speak up?<br>
><br>
> --------------------------------------------------------------------<br>
><br>
> Quoting "Mueller, Milton L" <<a href="mailto:milton@gatech.edu">milton@gatech.edu</a><mailto:<a href="mailto:milton@gatech.edu>>:">milton@gatech.edu>>:</a><br>
><br>
>> Kathy, Stephanie, and NCSG members:<br>
>><br>
>> Personally, I would have no problem falling in line with your<br>
>> position. But there are two fatal flaws that you need to address.<br>
>> First, you are describing only what _we_ want and not thinking at all<br>
>> about how you get consensus. Second, your description of what we want<br>
>> does NOT correspond to what will actually happen if we “hold the<br>
>> line.” As much as I would like to promote harmony and unity among<br>
>> NCSG EPDP representatives, I don’t think you have thought things<br>
>> through.<br>
>><br>
>> I know perfectly well that we don’t want any differentiation and that<br>
>> the registrars don’t either. What you are overlooking is that the<br>
>> other half of the EPDP does want it, and the board will see the EPDP<br>
>> as deadlocked. So Option 1 will make you feel very self-righteous in<br>
>> the short term, but what happens next? You are, as I will show,<br>
>> leading us down a blind alley.<br>
>><br>
>> I can think of 3 scenarios we can discuss as a basis for action.<br>
>><br>
>> Scenario 1.<br>
>> We “hold the line,” and we revert to Phase 1 recommendations<br>
>> unchanged. There is _no guidance_. The other half of the EPDP just<br>
>> gives up and accepts it. This result is not bad, I admit, if that<br>
>> last bit happens.<br>
>> But what are the Phase 1 recommendations? You have misrepresented the<br>
>> “status quo” as not differentiating legal and natural. WRONG. What<br>
>> will happen under this option is that any registrar or registry can<br>
>> choose to differentiate in any way they like. And there will be no<br>
>> guidance that you can appeal to if they do it wrong. You say you<br>
>> don’t want registrars asking users whether they are legal or natural.<br>
>> Well, sorry, that can happen under your Option 1. A deadlock on EPDP<br>
>> means that differentiation is neither prohibited or required, it is<br>
>> up to the contracted parties. Many registrars won’t do it, but some<br>
>> will. Registries could do it, too. This is the “let the market<br>
>> decide” option. Stephanie has become a libertarian, I guess.<br>
>><br>
>> Scenario 2<br>
>> Scenario 1 assumes the other side accepts defeat. But what if we<br>
>> “hold the line,” and the other half of the EPDP doesn’t accept it?<br>
>> The European Commission, the US justice department, the GAC, SSAC,<br>
>> and of course the IPC/BC and ALAC join a strong chorus telling the<br>
>> board “something must be done.” The Board is influenced, and refuses<br>
>> to accept the recommendation, as it has done with the SSAD (which the<br>
>> same group of stakeholders opposed). We have seen the Board cave to<br>
>> GAC and governmental demands again and again, the latest example<br>
>> being “curative rights” for IGO acronyms, which the GNSO never<br>
>> approved. Worse, the EC may modify its NIS2 legislation to require<br>
>> ICANN to differentiate. The US congress could intervene. The issue<br>
>> festers for another three – five years. Several powerful players<br>
>> start attacking the multistakeholder process. Maybe ICANN corrupts<br>
>> its process once again.<br>
>><br>
>> Scenario 3<br>
>> Scenario 3 is that we don’t require differentiation of legal persons,<br>
>> but we develop consensus guidance on how contracted parties should do<br>
>> it if they choose to do it. This is the most likely scenario, and<br>
>> it’s one that your position paper completely ignores. If you do want<br>
>> guidance, the approach to guidance that I have suggested is best,<br>
>> because it is a very lightweight process of self-identification by<br>
>> registrants. By offering some differentiation it may defuse the<br>
>> opposition of the other stakeholders. On the other hand Stephanie’s<br>
>> complicated, expensive and power-surrendering approach is not the<br>
>> kind of guidance we want.<br>
>><br>
>> By now it should be clear to anyone who’s read this far that Scenario<br>
>> 1 is not as wonderful as you say and may not be possible. The EPDP is<br>
>> already deeply invested in developing guidance about how registrars<br>
>> should and should not differentiate. We have been working on it for<br>
>> weeks. Unless something changes radically in the next week, we will<br>
>> actually produce some guidance about differentiation. So, I suggest<br>
>> that we confine our debate to Scenario 2: the developing of<br>
>> nonbinding guidance. I suggest again that allowing registrants to<br>
>> choose to identify their registration as one of a legal person, with<br>
>> their data published or automatically available via SSAD, creates a<br>
>> path to consensus and to resolving the issue, whereas your preferred<br>
>> path does not.<br>
>><br>
>> To conclude, I call your attention to a pathology that is paralyzing<br>
>> nearly all of ICANN’s working groups. Defining your position and<br>
>> “holding the line” is a strategy that all the SGs and ACs seem to<br>
>> adopt now. It turns all these deliberations into a bunch of people<br>
>> re-stating their position again and again for 3-4 years,<br>
>> re-litigating issues endlessly, avoiding any serious middle ground.<br>
>> No thought is given to finding a solution that achieves a critical<br>
>> mass of consensus.<br>
>><br>
>> Anyone who wants to be a serious participant in developing the NCSG’s<br>
>> position in EPDP has to answer a very basic question:<br>
>><br>
>> How does this end?<br>
>> What is your scenario for achieving the level of agreement needed to<br>
>> pass a policy?<br>
>><br>
>> Looking forward to your response.<br>
>><br>
>> Dr. Milton L Mueller<br>
>> Georgia Institute of Technology<br>
>> School of Public Policy<br>
>> Internet Governance Project<<a href="https://internetgovernance.org/" target="_blank">https://internetgovernance.org/</a>><br>
>><br>
>><br>
>><br>
>> From: NCSG-Discuss<br>
>> <<a href="mailto:NCSG-DISCUSS@LISTSERV.SYR.EDU">NCSG-DISCUSS@LISTSERV.SYR.EDU</a><mailto:<a href="mailto:NCSG-DISCUSS@LISTSERV.SYR.EDU>>">NCSG-DISCUSS@LISTSERV.SYR.EDU>></a> On<br>
>> Behalf Of<br>
>> <a href="mailto:kathy@DNRC.TECH">kathy@DNRC.TECH</a><mailto:<a href="mailto:kathy@DNRC.TECH>">kathy@DNRC.TECH></a><br>
>> Sent: Tuesday, May 4, 2021 5:35 PM<br>
>> To: <a href="mailto:NCSG-DISCUSS@LISTSERV.SYR.EDU">NCSG-DISCUSS@LISTSERV.SYR.EDU</a><mailto:<a href="mailto:NCSG-DISCUSS@LISTSERV.SYR.EDU>">NCSG-DISCUSS@LISTSERV.SYR.EDU></a><br>
>> Subject: Option 1<br>
>><br>
>><br>
>> Tx to Milton, Stephanie, Manju, Tapani, Farzi, Mark Leiser, Kim von<br>
>> Arx and everyone else who commented on our dicussion of options for<br>
>> the EPDP.<br>
>><br>
>> As it's time to wrap up this issue so our EPDP members can present<br>
>> our view to the EPDP Group, I co-wrote the email Stephanie posted<br>
>> earlier today (attached below too). Best regards, Kathy<br>
>> ------------------------------------------------------------------------<br>
>><br>
>> Fellow NCSG members,<br>
>><br>
>>> We would like to work together to share our rationale for Option 1 –<br>
>><br>
>> maintaining the status quo and not asking further follow-up<br>
>> questions, mandatory or otherwise, about legal and natural persons.<br>
>> While the EPDP phase 2a discussions have been an educational and<br>
>> interesting exercise, we are not under any obligation to change the<br>
>> existing policy, or further complicate it.<br>
>><br>
>> As we have all discussed, legal/natural person questions are very<br>
>> complicated for many of our members who are often noncommercial and<br>
>> non-profit organizations whose structure and ways of obtaining domain<br>
>> names do not resemble those of the large corporations other<br>
>> stakeholder groups represent. Our members may have many layers of<br>
>> privacy protection in less-well-known sections of the GDPR, other<br>
>> local law, Constitutions and international conventions.<br>
>><br>
>> We learned that recent studies show that 50% of gTLD domain name<br>
>> registrations are for natural persons – and at least 25% more have<br>
>> overlapping entity and personal data (e.g., the organization name has<br>
>> personal data in it and is thus protected as personal data).<br>
>><br>
>> Stephanie and Kathy shared their concerns for legal/natural person<br>
>> questions during our long work on the Proxy and Privacy<br>
>> Accreditation Working Group. We worked closely with the Registrars<br>
>> Stakeholder Group to protect registrant privacy – including Battered<br>
>> Women’s Shelters, family planning clinics, and girls educational<br>
>> institutions – all of which may be legal entities, but have<br>
>> protectable data due to obvious danger from disclosure in certain<br>
>> countries.<br>
>><br>
>> In light of the complicated world around us, we support Option 1- the<br>
>> Status Quo. We ask the NCSG to adopt this as our stance. Based on<br>
>> the existing policy which makes differentiation of legal/natural<br>
>> persons optional for each registrar, we believe we already have the<br>
>><br>
>> - best way to fight DNS Abuse,<br>
>><br>
>> - best way to protect individuals and noncommercial<br>
>> organizations, and<br>
>><br>
>> - best way to follow GDPR and other applicable human rights<br>
>> and free speech laws<br>
>><br>
>> Therefore, we recommend NCSG “hold the line” and stick with Option 1.<br>
>><br>
>> As the Registrars wrote in their EPDP Statement on Thursday April 29:<br>
>> We have heard plenty of vocal support in this group to<br>
>> [differentiate between legal and natural persons in a mandatory<br>
>> fashion], but to date the RrSG have not heard any compelling reason<br>
>> to create policy that makes this dramatic shift to the domain<br>
>> registration landscape.<br>
>><br>
>> We agree. Nothing will stop other stakeholder groups from demanding<br>
>> further disclosure of data, and lobbying other parties including<br>
>> governments. What we can do in ICANN is come up with the best<br>
>> solution for us at this time.<br>
>><br>
>> Many thanks to the members of our NCSG EPDP Team for your hard work.<br>
>> This has been a long road. With new studies, new information and<br>
>> legal opinions, we think we have a clear and strategic path forward.<br>
>> We believe our position to be closely aligned with that of the<br>
>> Registrar Stakeholder Group, which they articulated on April 29 (see<br>
>> below).<br>
>><br>
>> Best, Kathy Kleiman and Stephanie Perrin<br>
>><br>
>> ---------------------------------------------------------<br>
>> The Registrar Stakeholder Group issued their position statement on<br>
>> Thursday (4/29):<br>
>><br>
>> The members of the RrSG EPDP team have participated in this process<br>
>> in good faith since day one and will continue to do so; however, we<br>
>> need to be crystal clear that members of our Stakeholder Group, whom<br>
>> we are here to represent, have voiced and recently reconfirmed their<br>
>> strong opposition to any policy coming out of this group that makes<br>
>> differentiation between natural and legal persons for domain<br>
>> registrations mandatory.<br>
>><br>
>> We have heard plenty of vocal support in this group to do just that,<br>
>> but to date the RrSG have not heard any compelling reason to create<br>
>> policy that makes this dramatic shift to the domain registration<br>
>> landscape. The Contracted Party can make the most accurate assessment<br>
>> of their own legal, technical, and commercial risks and obligations,<br>
>> and is the only party that can determine what level of risk they<br>
>> should assume. The scope of this EPDP Phase 2a is to consider if<br>
>> changes are required for the relevant Recommendation; it has become<br>
>> clear through this process that no such changes are required<br>
>><br>
>> To the extent this group can focus its energies on guidance to<br>
>> contracted parties which choose on their own to make this<br>
>> differentiation, we continue to believe that is a worthwhile<br>
>> exercise. We believe that guidance materials including educational<br>
>> information provided by ICANN in multiple languages would help<br>
>> contracted parties educate registrants and this would be a valuable<br>
>> effort.<br>
>><br>
>> That said, based on analysis done by our stakeholder group's members,<br>
>> we reject the notion that the majority of registered domain names are<br>
>> registered to legal entities. We further remind this team that we<br>
>> have not yet seen evidence that increased publication of registration<br>
>> data will address any of the problems which have been mentioned so<br>
>> far in this phase, and that the registration data is reliably and<br>
>> promptly available to those who do have a legitimate reason to access<br>
>> it.<br>
>><br>
>> Finally we note that this statement represents the official position<br>
>> of the Registrar Stakeholder group, and statements from members of<br>
>> other groups participating in the EPDP do not represent our group’s<br>
>> position.<br>
>><br>
>> (Source: Transcript of EPDP-Phase 2A Team Call, 29 April 2021,<br>
>> Statement of Volker Greimann on behalf of the Registrars Stakeholder<br>
>> Group read into the record)<br>
<br></p>
</body>
</html>