[GNSO-Accuracy-ST] Potential Additional Questions to ICANN Org

Volker Greimann volker.greimann at centralnic.com
Wed Mar 2 22:35:03 UTC 2022 

Hi Michael,

so what you are looking for (and shouldn't be as a neutral chair!) is a
system where the registrant is required to respond to these messages? Or
else?
Do you have any idea how much problems such a process would cause?
Apparently not...

No registrar has the capacity to trigger a verification process if such a
process is triggered every time a registrant neglects to confirm his data
as accurate.
Requiring registrants to click to confirm on messages in emails also goes
against years of anti-phishing training.
Finally, the only sanction we as registrars have would be the suspension of
the domain. Can you imagine how many domains would needlessly go dark over
such a process that ultimately has no tangible benefits?

You say you do not have trust with the accuracy of the registrant data
depending upon a malicious registrant being expected to tell the truth.
Well, we don't either. No malicious registrant is going to tell the truth,
ever. And no feasible process in the world we can conjure up is going to
prevent them from finding ways around that process unless you are proposing
to rewrite the entire internet ecosystem.

Following your statement: " I think it is fair to characterize the
Registrar’s position as follows", you are actually misrepresenting our
position. Our position is that if there is evidence of a widespread
accuracy issue, we are happy to investigate further. We do not see such an
issue however, as the ARS clearly showed that the 2013 RAA has brought
changes that over the course of the ARS have improved the accuracy of
registrant data significantly. The data we have does not bear out the
claims of widespread inaccuracy issues. And the data we have is also
significantly outdated. If ICANN can find a way to restart ARS in a way
that is compliant with GDPR and other applicable data protection laws, they
should go for it. It would require them finally accepting that they are a
data controller, but we would welcome that too.

You then go on to state that " What I find odd is the almost universal
support of Registries and Registrars to look at a DNS Abuse subset of
domains to make a “malicious / comprised” determination, yet the mere
suggestion that this same subset of data could be analyzed through the lens
of “accuracy” is somehow verboten.". I am trying to wrap my head around
that statement, but am failing. How can you find this odd? Domains flagged
for DNS abuse are naturally considered to be either malicious or
compromised. If they were not, they would not be flagged for DNS Abuse now,
would they? That is just basic logic. But then to go ahead and propose we
should be basing our view of the accuracy issue in a subset of domains that
have been demonstrated to be problematic is disingenuous because that
subset will always be skewed toward the inaccurate because of the facts
outlined above. That is like bringing your own stacked decks or loaded dice
to the casino. It does not provide a neutral and objective view of the
overall status of accuracy in the gTLD DNS ecosystem. I do not think anyone
can fail to see that.

Finally, we need to come to an agreement on the definition of accuracy.
Without first completing that work, all other discussions are futile as we
will just be talking past each other. Our baseline is the definition that
results from our contracts. Another workable definition would be accuracy
in the context of the GDPR, e.g. accurately reflecting the data provided by
the data subject.

Our job as a scoping team is not to deliver what some groups may want, ut
to provide a neutral and objective overall scope of the issue that can be
the baseline for future policy work, if such work is required. This scope
cannot be biased as that would compromise the entire subsequent work.

Our work is simple:
A) Define Accuracy
B) Review status quo
C) Identify issues with the status quo based on objective facts and data.


-- 
Volker A. Greimann
General Counsel and Policy Manager
*KEY-SYSTEMS GMBH*

T: +49 6894 9396901
M: +49 6894 9396851
F: +49 6894 9396851
W: www.key-systems.net

Key-Systems GmbH is a company registered at the local court of
Saarbruecken, Germany with the registration no. HR B 18835
CEO: Oliver Fries and Robert Birkner

Part of the CentralNic Group PLC (LON: CNIC) a company registered in
England and Wales with company number 8576358.

This email and any files transmitted are confidential and intended only for
the person(s) directly addressed. If you are not the intended recipient,
any use, copying, transmission, distribution, or other forms of
dissemination is strictly prohibited. If you have received this email in
error, please notify the sender immediately and permanently delete this
email with any files that may be attached.


On Wed, Mar 2, 2022 at 6:20 PM Michael Palage <michael at palage.com> wrote:

> Sarah,
>
>
>
> I think your response actually hits the nail on the head regarding the
> concerns of the BC, IPC, ALAC, SSAC, and GAC.
>
>
>
> When I get my annual notification from GoDaddy at my email address, I do
> nothing because I know the data is accurate and I know there is no need to
> respond. I think there is group consensus that this is the right outcome.
>
>
>
> However, when malicious registrant uses mickey.mouse at protonmail.com to
> register an abusive domain name, and their Registrar sends an annual email
> that does not bounce, under the contractual requirements in the 2013 RAA
> that data is deemed accurate. I think that is the break down between both
> camps.  Further complicating matters is that a point in time operational
> verification of an email could have happened years in the past. Finally, I
> think the BC, IPC, ALAC, SSAC, and GAC also have a trust issue with the
> accuracy of the registrant data depending upon a malicious registrant being
> expected to tell the truth.
>
>
>
> Thanks for your contribution and moving this discussion forward.
>
>
>
> Best regards,
>
>
>
> Michael
>
>
>
>
>
> *From:* Sarah Wyld <swyld at tucows.com>
> *Sent:* Wednesday, March 2, 2022 10:42 AM
> *To:* michael at palage.com; 'Roger D Carney via GNSO-Accuracy-ST' <
> gnso-accuracy-st at icann.org>
> *Subject:* RE: [GNSO-Accuracy-ST] Potential Additional Questions to ICANN
> Org
>
>
>
> Hi Michael,
>
>
>
> Indeed, if the data is accurate, the RNH has no obligation to respond. If
> it’s inaccurate they must update it. For all we know, you don’t check that
> account because it forwards to your primary email address.
>
>
>
>
>
> --
>
> *Sarah Wyld*, CIPP/E
>
>
>
> Policy & Privacy Manager
>
> Pronouns: she/they
>
>
>
> swyld at tucows.com
>
>
>
>
>
> *From: *Michael Palage <michael at palage.com>
> *Sent: *March 2, 2022 9:44 AM
> *To: *'Sarah Wyld' <swyld at tucows.com>; 'Roger D Carney via
> GNSO-Accuracy-ST' <gnso-accuracy-st at icann.org>
> *Subject: *RE: [GNSO-Accuracy-ST] Potential Additional Questions to ICANN
> Org
>
>
>
> Hello Sarah,
>
>
>
> Please correct me if I am wrong but the current requirement is for
> Registrars to send an annual email reminder, however, there is NO
> requirement for the Registrant to affirmatively respond. Moreover, if there
> is NO bounce the Registrar is permitted to assume that all is good.  When I
> get my annual GoDaddy email I largely ignore it, and sometimes find it in
> my spam folder.
>
>
>
> Therefore, if I was to register a domain name with the email
> MickeyMouse at protonmail.com and never check that email account, as long as
> the Registrar NEVER received a bounced email it would be considered
> accurate under your reference to the annual email notification.  Would you
> agree with this statement?
>
>
>
> I guess the more important insight is what are the Registries and
> Registrars participating in the malicious v. compromises domain name study
> doing to make this determination. Could the Registrars and Registries
> perhaps share any insight on how this research is being undertaken?
>
>
>
> Best regards,
>
>
>
> Michael
>
>
>
>
>
>
>
> *From:* GNSO-Accuracy-ST <gnso-accuracy-st-bounces at icann.org> *On Behalf
> Of *Sarah Wyld
> *Sent:* Wednesday, March 2, 2022 9:27 AM
> *To:* Roger D Carney via GNSO-Accuracy-ST <gnso-accuracy-st at icann.org>
> *Subject:* Re: [GNSO-Accuracy-ST] Potential Additional Questions to ICANN
> Org
>
>
>
> Hello all,
>
>
>
> There’s a lot going on in this thread which I am not able to respond to at
> this time, but I do want to respond to one specific suggestion:
>
> > Would it be that much of an additional burden to ask the Registrants if
> the information contained in the Whois/RDDS is accurate and share those
> results with the group?
>
>
>
> There is an annual Whois data confirmation email sent out to all
> registrants, which includes the current registration data and asks them if
> it is accurate, along with an explanation that they are required to provide
> accurate and up-to-date information and instructions for how to update it
> if necessary.
>
>
>
> Does that not match up with this idea of asking Registrants if their Whois
> info is accurate?
>
>
>
> Thanks,
>
>
>
>
>
> --
>
> *Sarah Wyld*, CIPP/E
>
>
>
> Policy & Privacy Manager
>
> Pronouns: she/they
>
>
>
> swyld at tucows.com
>
>
>
>
>
> *From: *Michael Palage <michael at palage.com>
> *Sent: *March 2, 2022 9:10 AM
> *To: *'Becky Burr' <BBurr at hwglaw.com>; 'STROUNGI Melina'
> <Melina.STROUNGI at ec.europa.eu>; 'Becky Burr' <becky.burr at board.icann.org>
> *Cc: *gnso-accuracy-st at icann.org
> *Subject: *Re: [GNSO-Accuracy-ST] Potential Additional Questions to ICANN
> Org
>
>
>
> Hello Becky,
>
>
>
> In my capacity as the Chair, I view my responsibilities as trying to
> balance the respective perspectives of all participants and making sure
> that we document all of these perspectives in our work product.  As noted
> before, I would like to avoid some of the holes identified in the SSAD ODA,
> by making sure that we look at all sides of issues (both popular and
> unpopular).
>
>
>
> I think most will agree with me, that there have been some deeply held and
> divergent viewpoints that were crystal clear at the start of this Group’s
> work, see
> https://mm.icann.org/pipermail/gnso-accuracy-st/attachments/20211005/46ce22c7/AccuracyScopingTeam-InitialInput-5October2021-0001.pdf
> I think it is fair to characterize the Registrar’s position as follows: the
> 2013 RAA provides a black and white guidance as to the term accuracy;
> recent ICANN Compliance reports indicate that there are a de minimis number
> of accuracy complaints; therefore there is no problem let’s move on. I also
> think it is fair to characterize the BC, IPC, ALAC, SSAC and GAC respective
> positions as the 2013 RAA definition is over narrow; the recent ICANN
> Compliance reports are under-reporting inaccuracy because legitimate third
> party access has largely gone dark, therefore we need to reinitiate some
> type of accuracy survey to see the scope of the problem (if any) and
> propose a new definition (if necessary).
>
>
>
> So as Chair, I started out with the proposition that the 2013 RAA was a
> rebuttal status quo baseline for defining accuracy. Initially, there were
> several groups that rebutted that definition.  In fact, the push back was
> so hard we did not even use the term “definition” for a couple of weeks.
> However, after ICANN Compliance provided their feedback it was clear that
> the scope of accuracy was not simply a 2013 RAA black and white syntactical
> and operational exercise.  My job as Chair was then to help define the
> scope of that “grey” for purposes of our working definition as well as
> potential studies that might be undertaken to help document any accuracy
> problem.
>
>
>
> In response to calls from a number of members that wanted to restart the
> ARS, which was unilaterally suspended by ICANN Org after the GDPR went into
> effect, my job as Chair was to help find a potential middle ground if
> possible. While being respectful of contracting parties data privacy
> concerns, including the lack of no DPA with ICANN, I wanted to find the
> optimal path forward for a potential new ARS that would be in compliant
> with Article 6.1.(f) of the GDPR:
>
>
>
> processing is necessary for the purposes of the legitimate interests
> pursued by the controller or by a third party, except where such interests
> are overridden by the interests or fundamental rights and freedoms of the
> data subject which require protection of personal data, in particular where
> the data subject is a child.
>
>
>
> So instead of processing data from a universe of over 200 million gTLD
> domain registrations, I thought ICANN Org would be able to maximize its
> legitimate interest (while also taking into account the interests of the
> registrant) by focusing on a much narrower class of domain names associated
> with documented DNS abuse. Now there is almost universal recognition that
> there is a DNS Abuse problem, see DNS Abuse Institute, topDNS, Global Cyber
> Alliance, EU DNS Abuser Report, and CoCCA DSI. In fact the Registries and
> Registrars are both supportive of the upcoming DNS Abuse session that will
> undertake an analysis between maliciously registered domain names and
> compromised domain names.
>
>
>
> What I find odd is the almost universal support of Registries and
> Registrars to look at a DNS Abuse subset of domains to make a “malicious /
> comprised” determination, yet the mere suggestion that this same subset of
> data could be analyzed through the lens of “accuracy” is somehow verboten.
> I think you would agree with me that to an objective outside observer, the
> Registrar pushback appears less likely tied to statistical purity and
> potentially more likely because of what those results may reveal.  To those
> Registries and Registrars that may be participating in the malicious v
> compromised domain name study, I assume you are contacting Registrants.
> Would it be that much of an additional burden to ask the Registrants if the
> information contained in the Whois/RDDS is accurate and share those results
> with the group?
>
>
>
> In respond to your comment about “understand[ing] the interest in asking
> ICANN about its legal advice, but I am skeptical that will prove
> particularly enlightening.” Perhaps if ICANN Legal just provided a legal
> basis to the community instead of making self-serving proclamations about
> its role that would help out from a trust building exercise.  These are the
> concerns that I heard on the call last week when Thomas raised the issue
> about the lack of a DPA and Stephanie’s repeated request for ICANN to file
> a DPIA over the past several years.  Additionally, there have been other
> members that have raised similar concerns, so as Chair I will continue to
> push for these voices within the Working Group to be heard and to obtain
> the data for this group to make a factual determination.
>
>
>
> Best regards,
>
>
>
> Michael
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *From:* Becky Burr <BBurr at hwglaw.com>
> *Sent:* Tuesday, March 1, 2022 1:29 PM
> *To:* 'STROUNGI Melina' <Melina.STROUNGI at ec.europa.eu>; 'Becky Burr' <
> becky.burr at board.icann.org>; michael at palage.com
> *Cc:* gnso-accuracy-st at icann.org
> *Subject:* Re: [GNSO-Accuracy-ST] Potential Additional Questions to ICANN
> Org
>
>
>
> Re "clearing the bar" for legitimate interests not outweighed by the data
> subjects' privacy rights, what I think is probably not particularly
> relevant.  In the end, it will fall to the party granting access to the
> data (i.e., the Contracted Party) to make that call.  But in general I do
> agree that processing based on a specific cause for concern will usually be
> easier to justify under GDPR.
>
>
>
> That said, I do agree with the CPs who expressed concern about skewed
> results.  If we want to actually understand the volume and nature of
> inaccuracy across the entire data set and we wanted an answer that
> cannot be dismissed by one group of stakeholders or another, then a
> proactive audit that looks at registrant data across domains and across
> sponsoring registrars is likely necessary.  I'm not a statistics guru, but
> I suspect you could design a study that looked at a subset of the data, but
> looking only at the subset of data that has already been identified as
> inaccurate seems very problematic to me.
>
>
>
> I understand the interest in asking ICANN about its legal advice, but I am
> skeptical that will prove particularly enlightening.
>
>
>
> While I'd prefer to use the actual language from the 6.1(f) exception
> (legitimate interests not overridden by the interests/rights/freedoms of
> the data subject) using "under the GDPR" rather than "proportionate" also
> works.
>
>
>
> *J. Beckwith Burr*
>
> HARRIS, WILTSHIRE & GRANNIS LLP
>
> 1919 M Street NW/8th Floor
>
> Washington DC 20036
>
> 202.730.1316 (P) 202.352.6367 (M)
>
>
>
> *From:* GNSO-Accuracy-ST <gnso-accuracy-st-bounces at icann.org> on behalf
> of Michael Palage <michael at palage.com>
> *Sent:* Tuesday, March 1, 2022 12:14:56 PM
> *To:* 'STROUNGI Melina'; 'Becky Burr'
> *Cc:* gnso-accuracy-st at icann.org
> *Subject:* Re: [GNSO-Accuracy-ST] Potential Additional Questions to ICANN
> Org
>
>
>
> Hello Becky,
>
>
>
> I think we are in agreement that the processing/disclosing of non-public
> PII involves a two part test: legitimate interest and proportionate
> interest.  As you and others may recall this is why I have proposed that
> any limited restart of the ARS program involve a sampling of the data from
> the monthly DAAR reporting.
>
>
>
> From a legitimate interest standpoint, the domains reported in DAAR (e.g.
> malware, phishing, SPAM) are clearly involved in illegal activity in most
> jurisdictions. I do not see any situation in which ICANN would not easily
> clear this bar. Would you agree?
>
>
>
> With regard to the proportionality (balancing test), as will be discussed
> in the upcoming ICANN73 meeting, there are two types of potential
> registrations involving abusive domains, maliciously registered domain
> names and compromised domain names. From a “balancing test” ICANN easily
> clears any proportionality bar when looking at maliciously registered
> domain names.  Would you agree?
>
>
>
> With regard to compromised domains, while this balancing test is a little
> more substantive than with malicious domain names, I believe this is a bar
> that ICANN Org and the Contracting Parties should easily be able to clear
> in almost every scenario. Unlike the old Whois/RDDS that made registrant
> data publicly available for scraping, this proposed audit would be limited
> to a restrictive number of parties, ICANN, third-party vendor, and
> contracting party. Would you agree?
>
>
>
> I am also in agreement with your comments distinguishing between targeted
> processing/disclosure versus bulk processing/disclosure.  This is why I
> made the specific proposal to restart ADR on a limited scale targeting just
> Abusive Domain Names reported via DAAR. This targeted focus should address
> your bulk processing claims. Would you agree?
>
>
>
> What I found disappointing when I brought this to the consideration of the
> entire Working Group is that several Contracting Parties opposed this
> potential reasonable path forward because they thought that this would
> potentially skew the accuracy results. These Contracting Parties instead
> were adamant that any survey would need to involve the entire data set. My
> concern with this position is that any demands to include the entire set is
> potentially a non-start for processing in a legal compliant manner per the
> GDPR.
>
>
>
> In order to further explore your claim that the DPA is a red hearing,
> perhaps the Registry and Registrars representatives could go back to their
> respective stakeholders groups and ask for scenarios in which they would be
> willing to transfer data to ICANN or a designated vendor to check the
> accuracy of data. Would you agree with me that this data point would be
> extremely helpful in resolving potential ambiguity between the parties and
> their respective roles?
>
>
>
> In closing, I want to thank both Becky and Melina for your respective
> feedback and I look forward to additional constructive feedback going
> forward.
>
>
>
> Best regards,
>
>
>
> Michael
>
>
>
> *From:* STROUNGI Melina <Melina.STROUNGI at ec.europa.eu>
> *Sent:* Tuesday, March 1, 2022 11:13 AM
> *To:* Becky Burr <becky.burr at board.icann.org>; michael at palage.com
> *Cc:* gnso-accuracy-st at icann.org
> *Subject:* RE: [GNSO-Accuracy-ST] Potential Additional Questions to ICANN
> Org
>
>
>
> Dear Becky, all,
>
>
>
> many thanks for your additional suggestions.
>
>
>
> my two cents on the below:
>
>
>
> I support the distinction proposed by Becky, but would recommend replacing
> ‘proportionate’ with ‘under the GDPR’ so we are fully covered.
>
>
>
> The original question raised was “*Is ICANN able to access registration
> data under the GDPR on the basis that it has a legitimate interest in
> checking the accuracy of the data? “*
>
> The reference alone to the GDPR means that indeed the balancing test has
> been taken into account. As you rightly point out the GDPR requires a
> balancing test when ‘legitimate interests’ is used as a legal basis. So in
> my view as long as there is a reference to the GDPR there is no need to
> explicitly add the proportionate part. It is already implied. Plus, a more
> general reference is more encompassing in the sense that it takes into
> account the totality of the balancing test (i.e., data subjects’ interests
> etc.)
>
>
>
> Having said that I am all supportive of asking all of these questions (in
> general I am in favor of asking as many questions as we can think of as
> this is at the heart of our scoping tasks), but I would maintain –on top of
> what you suggest –the specific question on whether ICANN ever received or
> plans to receive legal advice on this particular topic.
>
> If I recall correctly this had been discussed in our accuracy scoping
> meeting  of 17 February and was proposed as a question to be addressed to
> Brian so he can forward it to ICANN compliance.
>
>
>
> In order to be able to progress with our discussions, it is important to
> know where exactly ICANN would base their assessment on these questions
> (i.e., whether they have received specific in-house or external legal
> advice, including but not limited to any correspondence with the EDPB).
>
>
>
> I have now tried to integrate Becky’s suggestion to the original
> questions. Hope this helps.
>
>
>
>
>
> *Question 1*
>
>    1. Does ICANN have a legitimate interest under the GDPR in accessing *domain
>    name registration data in response to complaints* that the data is
>    inaccurate? Has ICANN ever received or plans to receive legal advice on
>    this particular topic?
>    2. Does ICANN have a legitimate interest under the GDPR in *proactively
>    *acquiring *bulk access* to domain name registration data to undertake
>    an accuracy audit, even with respect to data for which it has no basis to
>    question its accuracy? Has ICANN ever received or plans to receive legal
>    advice on this particular topic?
>
> *Question 2*
>
> *For either scenario a or b under question 1*: Does ICANN believe that a
> Data Protection Agreement between itself and the Contracted Parties is a
> necessary legal requirement for requesting and receiving this data, and if
> so for what legal reason? What happens if the registrar receiving the
> access request disagrees with ICANN's application of the balancing test,
> i.e., does ICANN have the contractual authority to enforce its access
> request?
>
> Best,
>
> Melina
>
>
>
>
>
> *From:* GNSO-Accuracy-ST <gnso-accuracy-st-bounces at icann.org> *On Behalf
> Of *Becky Burr
> *Sent:* Tuesday, March 1, 2022 4:27 PM
> *To:* michael at palage.com
> *Cc:* gnso-accuracy-st at icann.org
> *Subject:* Re: [GNSO-Accuracy-ST] Potential Additional Questions to ICANN
> Org
>
>
>
> Michael -
>
>
>
> Respectfully, and without taking a position on whether these questions are
> relevant or timely, I think the questions need to be more nuanced to
> produce useful answers.
>
>    1. Does ICANN have a legitimate *and proportionate *interest in
>    accessing *individual registration records in response to credible
>    complaints* that the data is inaccurate? If so, is a DPA required to
>    access data in such situations?  What happens if the registrar receiving
>    the access request disagrees with ICANN's application of the balancing
>    test, i.e., does ICANN have the contractual authority to enforce its access
>    request?
>    2. Does ICANN have a legitimate *and proportionate* interest in *proactively
>    *acquiring *bulk access* to registrant data to undertake an accuracy
>    audit, even with respect to data for which it has no basis to question its
>    accuracy?  If so, is a DPA necessary to do so?  What happens if the
>    registrar receiving the access request disagrees with ICANN's application
>    of the balancing test, i.e., does ICANN have the contractual authority to
>    enforce its access request?
>
> It is important to keep in mind that a legitimate interest is necessary *but
> not sufficient* under GDPR.  The processing necessary to satisfy a
> legitimate interest must be proportionate, i.e., not outweighed by the
> privacy rights of the individual data subject(s).  As a result, the two
> situations (access to a single record based on reasonable grounds to
> believe the data is inaccurate v. proactive access without individualized
> suspicion) are quite different from a data protection perspective, with the
> first being far less complicated to defend.  In addition, a CP's
> contractual obligations, e.g., under the RAA, may be different in those
> situations.
>
>
>
> FWIW, I think the DPA issue is a bit of a red herring here.   Presumably,
> ICANN's requests for one-off data can be handled in the same way that
> anyone else's access request is handled, e.g., if the data is to be
> transferred outside of the EU by imposing controller to controller Standard
> Contractual Clauses as the terms and conditions of such access on a
> case-by-case basis.  If the EDPB were to confirm that ICANN's* bulk
> access* to data for proactive checking was legitimate and proportionate,
> it's clear to me that a narrowly focused DPA between ICANN and CPs
> applicable to data access for the specific purpose of checking accuracy
> (e.g., prohibiting onward transfer, etc.) could be crafted.  The real
> question is whether (i) the temp spec /epdp phase 1 policy obligating CPs
> to provide reasonable access for legitimate and proportionate purposes
> encompasses bulk access or (ii) some other provision of the agreements
> produces an obligation to provide bulk access.
>
>
>
> Apologies for being pedantic here.  None of us can say with any certainty
> what GDPR does or does not permit as that determination is ultimately made
> by individual data protection authorities and/or the EDPB.  We are asking
> ICANN for its views on what GDPR would permit in specific circumstances, so
> the relevant circumstances should be articulated precisely to produce
> useful answers.
>
>
>
> b
>
>
>
>
>
> On Thu, Feb 24, 2022 at 5:12 PM Michael Palage <michael at palage.com> wrote:
>
> Hello Everyone,
>
>
>
> Over the past couple of weeks there has been a recurring theme in our
> calls and in some of the side discussions that I have had with some members
> regarding about how the potential lack of a Data Processing Agreement
> between ICANN Org and the Contracting Parties might negatively impact our
> future work and/or recommendations.
>
>
>
> Therefore I would like to propose to the group for their consideration the
> following additional questions that we may want to propose to ICANN Org as
> we continue our work:
>
>
>
> •            “Is ICANN able to access registration data under the GDPR on
> the basis that it has a legitimate interest in checking the accuracy of the
> data?  Has ICANN ever received or plans to receive legal advice on this
> particular topic?
>
>
>
> •            Does ICANN believe that the Data Protection Agreement between
> itself and the Contracted Parties is a necessary legal requirement for
> requesting and receiving this data, and if so for what legal reason?"
>
>
>
> As always I welcome any thoughts and or considerations?
>
>
>
> Best regards,
>
>
>
> Michael
>
>
>
>
>
> _______________________________________________
> GNSO-Accuracy-ST mailing list
> GNSO-Accuracy-ST at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-accuracy-st
> <https://urldefense.com/v3/__https:/mm.icann.org/mailman/listinfo/gnso-accuracy-st__;!!DOxrgLBm!UNIutLhtKN79DDAyXMFbwLBM5YmXBcSEX_Z4GrdQYmzW9hzoy8-8tEvp-nQ58gfd3kyLTw-r$>
>
> _______________________________________________
> By submitting your personal data, you consent to the processing of your
> personal data for purposes of subscribing to this mailing list accordance
> with the ICANN Privacy Policy (https://www.icann.org/privacy/policy
> <https://urldefense.com/v3/__https:/www.icann.org/privacy/policy__;!!DOxrgLBm!UNIutLhtKN79DDAyXMFbwLBM5YmXBcSEX_Z4GrdQYmzW9hzoy8-8tEvp-nQ58gfd3uHvF4Qg$>)
> and the website Terms of Service (https://www.icann.org/privacy/tos
> <https://urldefense.com/v3/__https:/www.icann.org/privacy/tos__;!!DOxrgLBm!UNIutLhtKN79DDAyXMFbwLBM5YmXBcSEX_Z4GrdQYmzW9hzoy8-8tEvp-nQ58gfd3p4iJdXc$>).
> You can visit the Mailman link above to change your membership status or
> configuration, including unsubscribing, setting digest-style delivery or
> disabling delivery altogether (e.g., for a vacation), and so on.
>
>
>
>
> _______________________________________________
> GNSO-Accuracy-ST mailing list
> GNSO-Accuracy-ST at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-accuracy-st
>
> _______________________________________________
> By submitting your personal data, you consent to the processing of your
> personal data for purposes of subscribing to this mailing list accordance
> with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and
> the website Terms of Service (https://www.icann.org/privacy/tos). You can
> visit the Mailman link above to change your membership status or
> configuration, including unsubscribing, setting digest-style delivery or
> disabling delivery altogether (e.g., for a vacation), and so on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-accuracy-st/attachments/20220302/71dedb8b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 15054 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/gnso-accuracy-st/attachments/20220302/71dedb8b/image001-0001.png>

More information about the GNSO-Accuracy-ST mailing list