Fwd: No Guidance?

[Stephanie E Perrin]

yes to no guidance!  Thanks to Tomslin for calling us to order on this 
issue!

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.

cheers Stephanie

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