<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>yes to no guidance! Thanks to Tomslin for calling us to order on
this issue!<br>
</p>
<div class="moz-forward-container">
We had a very successful meeting of the EPDP today, thanks to
everybody who worked together to reach that compromise. Many
thanks to Milton for looking at the matter through a different
lens, and helping put together a common position. Thanks to all
our members who weighed in, and to Manju who kept trying to
clarify what we were talking about, as Milton and I occasionally
talked past each other. And special thanks to Kathy, who deserved
a holiday after slaving on her groups for so long, for diving into
EPDP stuff and reliving the (shudder) experience of PPSAI to help
us sort out our position. As she says, this is the way we should
work out our position, but it is often difficult, given the pace
of work in these pdps.
<p>cheers Stephanie<br>
</p>
<div class="moz-cite-prefix">On 2021-05-06 7:51 a.m., <a class="moz-txt-link-abbreviated" href="mailto:kathy@DNRC.TECH" moz-do-not-send="true">kathy@DNRC.TECH</a> wrote:<br>
</div>
<blockquote type="cite" cite="mid:20210506045133.Horde.09B8iWdzqEGf86XMvHiAS5R@a2plcpnl0836.prod.iad2.secureserver.net">
<title></title>
<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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">milton@gatech.edu</a><mailto:<a href="mailto:milton@gatech.edu>>:" moz-do-not-send="true">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" moz-do-not-send="true">https://internetgovernance.org/</a>><br>
>><br>
>><br>
>><br>
>> From: NCSG-Discuss<br>
>> <<a href="mailto:NCSG-DISCUSS@LISTSERV.SYR.EDU" moz-do-not-send="true">NCSG-DISCUSS@LISTSERV.SYR.EDU</a><mailto:<a href="mailto:NCSG-DISCUSS@LISTSERV.SYR.EDU>>" moz-do-not-send="true">NCSG-DISCUSS@LISTSERV.SYR.EDU>></a>
On<br>
>> Behalf Of<br>
>> <a href="mailto:kathy@DNRC.TECH" moz-do-not-send="true">kathy@DNRC.TECH</a><mailto:<a href="mailto:kathy@DNRC.TECH>" moz-do-not-send="true">kathy@DNRC.TECH></a><br>
>> Sent: Tuesday, May 4, 2021 5:35 PM<br>
>> To: <a href="mailto:NCSG-DISCUSS@LISTSERV.SYR.EDU" moz-do-not-send="true">NCSG-DISCUSS@LISTSERV.SYR.EDU</a><mailto:<a href="mailto:NCSG-DISCUSS@LISTSERV.SYR.EDU>" moz-do-not-send="true">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>
</blockquote>
</div>
</body>
</html>