Hi Hadia,

I agree that requestors need to have confidence that a process works; where I disagree is that ICANN's Compliance department needs to be involved in order for that to happen. Yesterday I shared some language on the list that I think can accomplish this goal - ensuring there is uniform, statistical data available - which is not incumbent on ICANN Compliance "auditing" the contracted parties. That is, if you will, my 'red line' here. There are many ways to incentivize the contracted parties to provide this data short of adding it to the contracts.

Ayden

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, February 7, 2019 9:09 AM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg> wrote:

All,

 

First and for most the intention is not to expand ICANN’s compliance role, the objective is to simply allow a trusted system to exist. I am surprised by the mention of words like” we have agreed to minimum requirements and compromised” while it is obvious that a transparent auditable system is the only means by which you can assert the functionality of any process. Transparency and trust is what our wider Internet community needs, it does not matter which stakeholder you represent or what interests you are fighting for if our processes are not built on transparent trusted systems then we are making big mistakes here. The community being requesters, domain holders or users whether simple end users or as mentioned by Ayden civil society or others need to have faith in the process.

The recommendation sent today by Dianne, Sarah and others I believe addresses many of our concerns.

 

Hadia

From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Ayden Férdeline
Sent: Thursday, February 07, 2019 3:56 PM
To: farzaneh badii
Cc: gnso-epdp-team@icann.org
Subject: Re: [Gnso-epdp-team] Recommendation 12 - Reasonable Access

 

I agree with Farzaneh; I have difficulty accepting this recommendation in general, but the compromise that I have reluctantly come to accept is a set of minimum requirements. The continued demand to expand the role of ICANN Compliance, which I note remains in the latest version of the text circulated by Diane, is a bridge too far, at least for me. I would like to see an acknowledgement of these concerns please.

 

Ayden 

 

 

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Wednesday, February 6, 2019 6:46 PM, farzaneh badii <farzaneh.badii@gmail.com> wrote:

 

Well I don't think you can implicitly or explicitly expand the "role of ICANN compliance". ICANN compliance has to make sure that the agreement that has been reached and the contract that has been drafted is not breached. So in effect, you are talking about an implementation issue which does not belong here. The fact that we have agreed to the "minimum requirements" is an actual compromise. If we are going to talk about auditing and enforcement of the rules, I would like to see a  cap on the number of  "requests for access" within a certain period of time. Even sometimes legitimate lawful access doesn't need to be responded to immediately especially when there are other avenues for asserting rights. 

 

Are my criteria unreasonable and not GDPR compliant? Nothing new really, mimicking the approach some in this group have taken for too long. 

 

 

Farzaneh

 

 

On Wed, Feb 6, 2019 at 5:27 PM Alan Greenberg <alan.greenberg@mcgill.ca> wrote:

Ayden, prior to the Temp Spec, contracted parties had no need to reply to such requests because the information was public. With the Temp Spec and with the policy and Purposes we are recommending, contracted parties have a new obligation. Thus we are implicitly "expanding the role of Contractual Compliance" since their role is to ensure that contracted parties are fully fulfilling their obligations and we are adding obligations!

 

Alan

 

At 06/02/2019 03:19 PM, Ayden Férdeline wrote:

 

 

I oppose the edit put
forward by our colleagues in the ALAC that seeks to expand the role of
Contractual Compliance.
 
However, if the desire is more along the lines of (2) and the tool was
funded on a cost-recovery basis by those seeking to utilize it, and not
indirectly or directly by registrants, I would not object to language
along the following lines:
 
--
The EPDP Team recommends that ICANN org and the contracted parties
develop a mechanism that provides third party requestors with uniform
statistical information on the 1) nature of submitted requests, 2)
average processing time, and 3) the number of requests approved or
rejected, with rationale appropriately coded for information purposes.
Such a mechanism must be funded on a cost-recovery basis by those private
sector third parties who make access requests and seek to have access to
these records.
--
 
Ayden
 
 
 Original Message
On Wednesday, February 6, 2019 2:59 PM, Mark Svancarek \(CELA\) via
Gnso-epdp-team
<
gnso-epdp-team at icann.org> wrote:
 
> Hopefully there is some language which properly reflects the
variability of request responses while recognizing that nothing can be
judged successful or improved without measuring it.
> 
> For example, in our online services (1) we offer a firm SLA to
our customers and reimburse them when we miss it, regardless why we
missed it... but (2) internally we generate more interesting metrics to
better understand the root causes, opportunities to improve, and the
relative frequency of the various issues. Also, this reduces
finger-pointing between teams.
> 
> CPs cannot agree to language which implies (1); ALAC is
requesting something like (2).
> 
> /marksv
> 
> -----Original Message-----
> From: Gnso-epdp-team

gnso-epdp-team-bounces at icann.org On Behalf Of Hadia Abdelsalam
Mokhtar EL miniawi
> Sent: Wednesday, February 6, 2019 11:36
> To: Alan Woods
alan at
donuts.email
> Cc:

gnso-epdp-team at icann.org
> Subject: Re: [Gnso-epdp-team] Recommendation 12 - Reasonable
Access
> 
> Hi Alan,
> 
> I am sorry that this is how you feel about our suggestion with
regard to compliance, certainly there was no intention to having a stick
to beat the contracted parties. Usually auditing is something that both
parties benefit from. In what sense does our suggestion put new
obligations on the contracted parties? It is just a means of verifying
the process and this is good for the CPs as well because it ascertains
the functionality of their system. Moreover how does the suggestion of
having some kind of auditing contradict with the fact that every single
request received must be considered individually? Additionally, we never
said that existing complaints' processes can not be used we only said
that you need to agree on the auditing mechanisms/means or whatever you
want to call it. This is merely a suggestion to implement a sense of
trust into the system, rather than having that trust something as
intangible as good faith between the parties involved.
> 
> Finally I invite you to put a few lines that speak about using
existing complaints processes in this regard.
> 
> Hadia
> 
> From: Alan Woods
alan at
donuts.email
> Sent: 06 February 2019 19:01
> To: Hadia Abdelsalam Mokhtar EL miniawi
> Cc: Marika Konings; Sarah Wyld;

gnso-epdp-team at icann.org
> Subject: Re: [Gnso-epdp-team] Recommendation 12 - Reasonable
Access
> 
> To be perfectly honest, I think that Hadia & Alan's
suggestions, are perilously close to going against the the very nature of
the tentative agreements we have on Recommendation 12. If their point of
view is that ICANN compliance must be used as a stick to beat the
Contracted parties into submission/compliance, I find that exceptionally
unhelpful. It is not the role of the ePDP to create new obligations for
CPs outside of that which is necessary for GDPR compliance!
> 
> The repeated issue of the parties is that it is nigh on
impossible to set this in stone; every single request received must be
considered individually, on its own merits (as the GDPR, which supersedes
all our machinations, requires). The CPs are coming to the table in
goodwill noting that we understand the need for predictability for 3rd
party requests. We have discussed at length the impossibility of setting
a strict timeline on such requests, I simply think this squanders the
goodwill in this agreement in now suggesting a frankly unimplementable,
or more likely a utterly ad hoc and random audit system, rather than
accepting that the contracted parties are acting in good faith, and will
continue to do so. For those CPs who do not act in good faith, I have a
feeling that a poor audit result regarding response to disclosure
requests will be the least of the issues.
> 
> There are elements that are tangible and capable of ICANN review
upon complaints regarding same, using existing complaints processes.
Let's not reinvent the wheel here!
> 
> So to be clear. The RYSG strongly opposes the ALAC addition.
> 
> Alan
> 
> [Donuts
Inc.]
https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02|01|marksv%40microsoft.com|a9079d3d169b43325b3f08d68c6aa4ce|72f988bf86f141af91ab2d7cd011db47|1|0|636850787006891055&sdata=qNzaAlOZg%2FMQWGew0BAhQsiEgNSJWm93KQLay7KeXJM%3D&reserved=0
> Alan Woods
> Senior Compliance & Policy Manager, Donuts Inc.
> 
> The Victorians,
> 15-18 Earlsfort Terrace
> Dublin 2, County Dublin
> Ireland
> 
> 
[
https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fstorage.googleapis.com%2Fsignaturesatori%2Ficons%2Ffacebook.png&data=02|01|marksv%40microsoft.com|a9079d3d169b43325b3f08d68c6aa4ce|72f988bf86f141af91ab2d7cd011db47|1|0|636850787006891055&sdata=zgvRrc4%2F2R4vEiotdSdqRqyFG768vmONrHXOs1ENVoI%3D&reserved=0
]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.facebook.com%2Fdonutstlds&data=02|01|marksv%40microsoft.com|a9079d3d169b43325b3f08d68c6aa4ce|72f988bf86f141af91ab2d7cd011db47|1|0|636850787006891055&sdata=ZeISVoj4mLSFO8K0S27Nh5xZL2%2FVm5q9pYcz1SvfphI%3D&reserved=0
 [https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fstorage.googleapis.com%2Fsignaturesatori%2Ficons%2Ftwitter.png&data=02|01|marksv%40microsoft.com|a9079d3d169b43325b3f08d68c6aa4ce|72f988bf86f141af91ab2d7cd011db47|1|0|636850787006891055&sdata=4JUZEzvlQHSFB7n7JYasT%2Byjs4cafuTysVYL%2Fn%2F7gZU%3D&reserved=0]

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2FDonutsInc&data=02|01|marksv%40microsoft.com|a9079d3d169b43325b3f08d68c6aa4ce|72f988bf86f141af91ab2d7cd011db47|1|0|636850787006891055&sdata=yEwpQ7m%2F%2BrcZT2rqa8zZ%2BCi6YfD3fYgz%2Fdwj0sSZp%2F0%3D&reserved=0
 [https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fstorage.googleapis.com%2Fsignaturesatori%2Ficons%2Flinkedin.png&data=02|01|marksv%40microsoft.com|a9079d3d169b43325b3f08d68c6aa4ce|72f988bf86f141af91ab2d7cd011db47|1|0|636850787006901063&sdata=Jq7W2sADswmiY%2Bbw%2F0fQArEE6zdKO7%2FvsbAzbr494jU%3D&reserved=0]

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fcompany%2Fdonuts-inc&data=02|01|marksv%40microsoft.com|a9079d3d169b43325b3f08d68c6aa4ce|72f988bf86f141af91ab2d7cd011db47|1|0|636850787006901063&sdata=kxVuIPK4uDWls1FB8gb9gUz5lXQ58EM1yVZNavPBUyw%3D&reserved=0
> 
> Please NOTE: This electronic message, including any attachments,
may include privileged, confidential and/or inside information owned by
Donuts Inc. . Any distribution or use of this communication by anyone
other than the intended recipient(s) is strictly prohibited and may be
unlawful. If you are not the intended recipient, please notify the sender
by replying to this message and then delete it from your system. Thank
you.
> 
> On Wed, Feb 6, 2019 at 12:10 PM Hadia Abdelsalam Mokhtar EL
miniawi
<Hadia
at
tra.gov.egmailto
:Hadia at
tra.gov.eg> wrote:
> Hi all , I have added a few words about compliance and the
implantation of the policy and hence propose the following minor edits to
recommendation number 12
> 
> "
> The EPDP Team recommends that ICANN org and the contracted
parties develop a mechanism that allows ICANN Contractual Compliance to
audit response times to the requests.
> The EPDP recommends that the implementation of this policy
includes requirements of acknowledgement of recipient of requests and the
response to such requests, criteria for a " Reasonable Request for
lawful Disclosure" and a mechanism that allows ICANN Contractual
Compliance to audit response time to the requests.
> 
> The implementation of this policy will include at a minimum
"
> 
> The above is to replace
> 
> "The EPDP Team recommends that criteria for a “Reasonable
Request for Lawful Disclosure” and the requirements for acknowledging
receipt of a request and response to such request will be defined as part
of the implementation[Kristina 1] of these policy recommendations but
will include at a minimum: "
> 
> Hadia
> 
> From: Gnso-epdp-team
[
mailto:gnso-epdp-team-bounces at
icann.orgmailto:gnso-epdp-team-bounces at icann.org] On Behalf Of Hadia
Abdelsalam Mokhtar EL miniawi
> Sent: Wednesday, February 06, 2019 12:32 PM
> To: Marika Konings; Sarah Wyld;

gnso-epdp-team at
icann.orgmailto
:
gnso-epdp-team at icann.org
> Subject: Re: [Gnso-epdp-team] Recommendation 12 - Reasonable
Access
> 
> Hi all, the below comments are on behalf of Alan G
> 
> the proposal.
> 
> 1.  still does not set an expectation that although SOME
requests may take the specified limit, not all should. Nor does it seem
to imply that the Contractual Compliance has any ability to audit
response times.
> 2.  I find the reference to "GDPR legal bases"
problematic. For example, under the current proposals, a registrar who is
operating full outside of the EU mat redact information for legal persons
and for natural persons not subject to the GDPR. What is the GDPR legal
basis for requesting information on such registrations. According to GDPR
there was no need for redaction to begin with, so a registrar can refuse
to provide any results with full impunity.
> 
>     From: Gnso-epdp-team
[
mailto:gnso-epdp-team-bounces at icann.orgmailto:gnso-epdp-team-bounces
at icann.org] On Behalf Of Marika Konings
> 
> 
> Sent: Tuesday, February 05, 2019 11:43 PM
> To: Sarah Wyld;

gnso-epdp-team at
icann.orgmailto
:
gnso-epdp-team at icann.org
> Subject: Re: [Gnso-epdp-team] Recommendation 12 - Reasonable
Access
> 
> Thanks, Sarah.
> 
> EPDP Team members, as this topic is included in the agenda for
tomorrow’s meeting, please share any issues or concerns your group may
have with the modified language prior to the meeting, if possible. Staff
has taken the liberty to fix some formatting issues in the attached
version (some of the sub-bullets did not appear properly).
> 
> Best regards,
> 
> Caitlin, Berry and Marika
> 
> From: Gnso-epdp-team
<
gnso-epdp-team-bounces at
icann.orgmailto
:
gnso-epdp-team-bounces at icann.org> on behalf of Sarah Wyld
<swyld
at
tucows.commailto
:swyld at
tucows.com>
> Organization: Tucows
> Date: Tuesday, February 5, 2019 at 12:31
> To:
"
gnso-epdp-team at
icann.orgmailto
:
gnso-epdp-team at icann.org"
<
gnso-epdp-team at
icann.orgmailto
:
gnso-epdp-team at icann.org>
> 
> Subject: [Gnso-epdp-team] Recommendation 12 - Reasonable Access
> 
> Hello All,
> 
> As discussed on today's call, here is the proposed revised Rec.
12 from RySG/RrSG. Thank you.
> 
> 
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> 
> Sarah Wyld
> 
> Domains Product Team
> 
> Tucows
> 
> +1.416 535 0123 Ext. 1392
> 
> On 1/31/2019 11:31 PM, Kurt Pritz wrote:
> 
> Hello Everyone:
> 
> Thanks again for your perseverance. And - thank you in advance
for your spirit of cooperation and compromise in considering the
attached. We have spent the last few days reviewing the transcripts and
other records of our recent discussions and then amending the Final
Report Recommendations - taking into account the Initial Report
Recommendations, the small team work, the conclusions in Toronto and
these last several meetings.
> 
> The Recommendations included here are:
> 
> Recommendation 5 - Data elements to be transferred from
Registrars to Registries
> 
> Recommendation 10 - Email communication
> 
> Recommendation 12 - Reasonable Access
> 
> Recommendation 14 - Responsible Parties
> 
> [Not included are Rec. 13 (sent earlier) and Rec. 11 and the
Research Purpose (to be sent tomorrow.]
> 
> Each of these documents has a brief forward containing a
description of the pertinent discussion and an explanation for choosing
the wording in the Recommendations. They each then contain the
Recommendation as originally written and a redline of the proposed
recommendation based on the most recent discussions. Please read the
entire documents (they are not long), and not just the recommendation
itself.
> 
> I am certainly not asking for you to stand silently by if you
disagree with these Recommendations because they would negatively impact
GDPR compliance. I am asking that you study the balancing that went into
this and be ready to accept wording in cases where it does not match your
own choice.
> 
> Please review with your groups and return to us by Monday so
that we can put any of these on the Tues/Wed/Thur agendas.
> 
> Sincerely,
> 
> Kurt
> 
> Gnso-epdp-team mailing list
> 
> 

Gnso-epdp-team at
icann.orgmailto
:
Gnso-epdp-team at icann.org
> 
> 

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02|01|marksv%40microsoft.com|a9079d3d169b43325b3f08d68c6aa4ce|72f988bf86f141af91ab2d7cd011db47|1|0|636850787006901063&sdata=ztu02eOXYqmlM6hkr5cySLY7%2B08r5qpe4L5JXi%2F%2B%2B%2Fs%3D&reserved=0
> 
> [Kristina 1]see previous comment about IRT/actor
_______________________________________________
> Gnso-epdp-team mailing list
> 

Gnso-epdp-team at
icann.orgmailto
:
Gnso-epdp-team at icann.org
> 

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02|01|marksv%40microsoft.com|a9079d3d169b43325b3f08d68c6aa4ce|72f988bf86f141af91ab2d7cd011db47|1|0|636850787006901063&sdata=ztu02eOXYqmlM6hkr5cySLY7%2B08r5qpe4L5JXi%2F%2B%2B%2Fs%3D&reserved=0
> 
> Gnso-epdp-team mailing list
> 

Gnso-epdp-team at icann.org
> 

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02|01|marksv%40microsoft.com|a9079d3d169b43325b3f08d68c6aa4ce|72f988bf86f141af91ab2d7cd011db47|1|0|636850787006901063&sdata=ztu02eOXYqmlM6hkr5cySLY7%2B08r5qpe4L5JXi%2F%2B%2B%2Fs%3D&reserved=0
> 
> Gnso-epdp-team mailing list
> 

Gnso-epdp-team at icann.org
> 

https://mm.icann.org/mailman/listinfo/gnso-epdp-team
 

_______________________________________________

Gnso-epdp-team mailing list