Logo

Julie Bisland's Personal Meeting Room
Sarah Wyld (RrSG)
40:40
Hi, all
Alan Woods (Donuts)
44:54
sorry for the tardiness
Chris Disspain
45:03
greetings all
Berry Cobb
46:20
https://docs.google.com/document/d/1XeHP_YZN7fR0LwQ4DzRuY9PqB39uOzHXot-yH0fcvbc/edit
Sarah Wyld (RrSG)
47:35
I think that assessment comes up lower down in this doc though?
Caitlin Tubergen
50:49
As a reminder, the language beginning in Paragraph 5 comes from the balancing test framework doc provided by Alan W. and Matthew C.
Mark Svancarek (BC) (marksv)
53:47
I can take it
Stephanie Perrin (NCSG)
54:37
unusual definition of the word necessary. Just saying….
Matthew Crossman (RySG)
55:37
Stephanie - I believe we pulled that from the BIrd & Bird advice
Stephanie Perrin (NCSG)
56:34
I would suggest replacing necessary with required.for the requestor’s stated purpose
Stephanie Perrin (NCSG)
57:13
It would be nice to see the reference from which this was extracted.
Stephanie Perrin (NCSG)
58:05
It is easier to get your head around the distinction between required and indispensable, rather than necessary and absolutely necessary
Sarah Wyld (RrSG)
58:21
They could be implementation advice?
Stephanie Perrin (NCSG)
58:55
depends on where we want the policy to stipulate how to do data minimzation
Stephanie Perrin (NCSG)
01:00:08
my feeling is not here because I agree with what Franck is saying
Caitlin Tubergen
01:00:22
To confirm a comment from Matthew, this language came from a citation from the Bird & Bird opinion on automation (p. 7) - “A gloss provided by the UK Court of Appeal can be helpful, which suggests that this means"more than desirable but less than indispensable or absolutely necessary"
Mark Svancarek (BC) (marksv)
01:00:25
I think the use cases could be implementation advice
Margie Milam (BC)
01:00:51
+1 Mark
Sarah Wyld (RrSG)
01:00:52
The use cases didn't actually outline which data elements are required, though - they left it TBD depending on the circumstance, selecting from the full list of possible elements
Caitlin Tubergen
01:00:53
Memo for Question 3: https://community.icann.org/display/EOTSFGRD/EPDP+-P2+Legal+subteam
Amr Elsadr (NCSG)
01:01:45
@Janis: Am I in the queue?
Stephanie Perrin (NCSG)
01:02:06
in context, the quote makes sense, cited here baldly it makes less sense….
Hadia Elminiawi (ALAC)
01:03:15
according to ICO "necessary" means that the processing must be targeted and proportionate way of achieving the purpose
Amr Elsadr (NCSG)
01:03:23
@AlanW: +1
Stephanie Perrin (NCSG)
01:03:28
+1 Alan W
Amr Elsadr (NCSG)
01:03:37
EDPS on “necessary”: Necessity implies the need for a combined, fact-based assessment of the effectiveness of the measure for the objective pursued and of whether it is less intrusive compared to other options for achieving the same goal.
Margie Milam (BC)
01:03:40
the use cases gave the maximum data elements, but requestors should ask for less if they don't need them
Amr Elsadr (NCSG)
01:03:51
https://edps.europa.eu/sites/edp/files/publication/17-04-11_necessity_toolkit_en_0.pdf
Margie Milam (BC)
01:04:44
+1 Hadia
Alan Woods (RySG) (Donuts)
01:05:11
https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/lawful-basis-for-processing/legitimate-interests/
Alan Woods (RySG) (Donuts)
01:05:26
Thanks Laureen
Stephanie Perrin (NCSG)
01:05:30
in a proper form (which we would generate in implementation) there would be justification blanks for why you need each element. In some cases, un-necessary data elements can be justified to ensure that you have the correct registrant. (I hesitate to use the dreaded word accuracy here)
Alan Woods (RySG) (Donuts)
01:06:08
However I do note that the bar is actually higher when it comes to LEA. Because if there are Legal routes that LEA SHOULD be following .. the may be slower, but they should be dosing so.
Alan Woods (RySG) (Donuts)
01:06:35
Also … such are the joys of being a controller being asked to disclose their data to a 3rd party
Alan Woods (RySG) (Donuts)
01:06:44
They are expected to make these calls.
Sarah Wyld (RrSG)
01:06:47
I could see that sometimes this is a reasonable concern, but there could be a case where the requestor simply wants to contact the domain owner, and doesn't know that they can use the publicly available information to do so. I would want to be able to deny the disclosure request and inform the requestor how to contact the RNH by the publicly available info.
James Bladel (RrSG)
01:07:02
Agreed, Alan. SSAD isn’t intended to be a bypass for Due Process or to conduct fishing exercises.
Alan Woods (RySG) (Donuts)
01:07:06
Also Faster does not equal most appropriate … and LEA’s should really be more concerned with due process, not speed
Stephanie Perrin (NCSG)
01:07:23
Sarah raises a very valid point
Matt Serlin (RrSG)
01:07:26
+1 Sarah
Sarah Wyld (RrSG)
01:07:31
Agreed, ALan
Stephanie Perrin (NCSG)
01:08:47
It is indeed the case that a few more detailed RNH data requests is better than a broader fishing expedition looking for fewer data elements. So this is, as Alan W has pointed out, all context related
James Bladel (RrSG)
01:09:04
This could also be determined & enforced by the fee structure. If the cost per request is set sufficiently high, it will incentivize folks to use less invasive (cheaper/free) methods
Sarah Wyld (RrSG)
01:09:08
Right, context is key. The specific circumstances of each request must be considered.
Caitlin Tubergen
01:09:37
In Building Block A, the following text is used: c) Information about the legal rights of the requestor specific to the request and specific rationale and/or justification for the request, (e.g., What is the basis or reason for the request; Why is it necessary for the requestor to ask for this data?);
Berry Cobb
01:09:45
Staff could add "explanation that there is no less intrusive way to obtain this information"?
Hadia Elminiawi (ALAC)
01:09:59
@Amr exactly the law defines this why do we need to define it here
Caitlin Tubergen
01:10:13
https://docs.google.com/document/d/1bl7GY496uqJ93TIC-39PLB22ZVP0ecW0Bdo91jk1UDI/edit
Alan Woods (RySG) (Donuts)
01:10:15
Agreed Berry
Alan Woods (RySG) (Donuts)
01:11:25
Hadia … because there is a necessary element of education required here too - and again we are talking about principle based, and the interpretation of the controller also …. This goes to transparency in our process.
Amr Elsadr (NCSG)
01:11:39
@Hadia: I’m fine not defining it. Not sure we’re qualified to do so, anyway. It has its meaning in the Regulation, and assessment of any request to disclose data needs to take Regulation into account, not just whatever policy recommendations we come up with.
Stephanie Perrin (NCSG)
01:12:23
Normally the detail on how to do the balancing test, proportionality test and data minimization decision would be done in a guidance document or internal staff instruction manual, in my opinion. Not the policy. We might want to think about providing such a model for data controllers governed by this policy.
Stephanie Perrin (NCSG)
01:12:29
manual, not model
Hadia Elminiawi (ALAC)
01:12:36
@Alan all interpretations in this regard are similar thro - you cannot fool the law
Hadia Elminiawi (ALAC)
01:13:15
@Alan in addition we have put it where it belongs
Mark Svancarek (BC) (marksv)
01:13:18
I could support it
Amr Elsadr (NCSG)
01:13:19
@AlanW: Agree that, to the extent possible, we need to all be on the same page re: educating ourselves, and setting principles. My chief concern is that the meaning of “necessary” as per GDPR should not be negotiated by us. It is what it is. We can’t cherry-pick which parts of its meaning we will drop, like the second bullet.
Laureen Kapin (GAC)
01:13:55
I would support Janis's approach also.
Alan Woods (RySG) (Donuts)
01:14:00
Agreed. What is necessary is .. is what is necessary in the circumstances.
zzzVolker Greimann (RrSG Alternate)
01:14:26
Fully agree
zzzVolker Greimann (RrSG Alternate)
01:14:33
This is basic GDPR
Alan Woods (RySG) (Donuts)
01:14:40
Also - I’m intrigued by the subtle change by everyone stating - perhaps just a slip - that the CPs will be making these decisions now?
Alan Woods (RySG) (Donuts)
01:14:55
Have I missed something? Lol
Amr Elsadr (NCSG)
01:14:59
@Hadia: There’s an argument to be made that most of what we’re doing is an attempt to fool or find ways to circumvent the law. Wether we admit (even to ourselves) this, or not, it’s fairly clear to me.
zzzVolker Greimann (RrSG Alternate)
01:15:06
Demanding to strike this basic principle basically demonstrates bad faith
Stephanie Perrin (NCSG)
01:15:18
some of us have been arguing all along that you are the only guys capable of making these decisions....
James Bladel (RrSG)
01:15:28
I’m also surprised that this is controversial, basically asking Requestors to behave responsibly and do their homework. But we can fix this when establishing the fee structure.
Stephanie Perrin (NCSG)
01:15:31
(in response to Alan W)
Alan Woods (RySG) (Donuts)
01:16:09
@Stephanie don’t disagree at all … I’m just noting a subtle framing change from some parties.
Laureen Kapin (GAC)
01:16:24
Volker, the tone of your comment is not constructive.
Alan Greenberg (ALAC)
01:16:24
"Necessary" already implies the next bullet.
Amr Elsadr (NCSG)
01:16:32
@MarkSV: What you’re saying is simply not true.
Amr Elsadr (NCSG)
01:17:18
@MarkSV: Again…, quoted from the EDPS toolkit on “Necessity”: Necessity implies the need for a combined, fact-based assessment of the effectiveness of the measure for the objective pursued and of whether it is less intrusive compared to other options for achieving the same goal.
Mark Svancarek (BC) (marksv)
01:17:22
@Amr, how so?
Amr Elsadr (NCSG)
01:17:32
See the language I just pasted.
Hadia Elminiawi (ALAC)
01:17:37
@Marc so why not keep the main bullet "are the data elements requested necessary to the requestor's stated purpose" and delete the other two sub bullets
Amr Elsadr (NCSG)
01:17:43
You can find it here: https://edps.europa.eu/sites/edp/files/publication/17-04-11_necessity_toolkit_en_0.pdf
Marc Anderson (Verisign / RySG)
01:17:52
the two bullet points are different concepts
Stephanie Perrin (NCSG)
01:17:53
I would actually support “determine whether less invasive means would achieve the same goals” . That is the legal requirement, no? Considering sounds a wee bit contemplative to me….this is an obligation, data minimization.
zzzVolker Greimann (RrSG Alternate)
01:17:55
Apologies I just remembered I am an alt today. Shutting up now
Marc Anderson (Verisign / RySG)
01:18:36
as a data requestor, if you had a less invasive means of getting the data, wouldn't you take that less invasive means? Either way you have the data
Alan Woods (RySG) (Donuts)
01:19:24
Ultimately - what is necessary is the call of the controller. Our policy should not define it anyway.
Amr Elsadr (NCSG)
01:19:53
@AlanW: +1000!!
Laureen Kapin (GAC)
01:20:12
I think the issue here is not the propriety of pursuing a less intrusive means but more a question of who is best positioned to assess that issue, the requestor or the entity making the decision of wheher to disclose.
Sarah Wyld (RrSG)
01:21:01
The disclosing entity has to be assured that providing the data is the appropriate decision, and if there is a less invasive means available is a factor in that decision
Alan Woods (RySG) (Donuts)
01:21:01
Franck - this is literally what 6(1)f requires of the disclosing controller - someone will have to make that call and will be liable …..
Stephanie Perrin (NCSG)
01:21:07
The onus is on the requestor to present their case.
Franck Journoud (IPC)
01:21:31
Janis: a central authorization provider could maybe do that. thousands of CPs, many of them small, won't.
Alan Woods (RySG) (Donuts)
01:21:33
Agreed Stephanie … if the controller is not provided with enough to justify disclosure - it should not disclose
Stephanie Perrin (NCSG)
01:21:37
See earlier comments on the form we will be using…it is important if we are trying to streamline the process
Alan Woods (RySG) (Donuts)
01:22:02
Franck - what you are saying here is that controllers are not competent to be controllers . I’m rather confused by that?
Alan Woods (RySG) (Donuts)
01:22:17
*!
Franck Journoud (IPC)
01:22:49
Alan W: it is their responsibility, the question is how can they discharge it. Providing them guidance to minimize their compliance costs is important.
Stephanie Perrin (NCSG)
01:23:06
Smaller controllers need guidance on how to do this. Comes in a guidance document, supplemented by audit from a qualified entity …..which is why a data trust is a good model to achieve this goal.
Alan Woods (RySG) (Donuts)
01:23:37
Well speaking as one of those controllers - if a DPA asks me why I took an action to disclose - and my answer is because ICANN told me - then I’m gonna get fined HARD
Amr Elsadr (NCSG)
01:23:50
Are we considering non-uniformity in policy recommendations again?
Sarah Wyld (RrSG)
01:24:04
Indeed, we should not be; we should remove the EEA mentions and apply one policy for all.
Stephanie Perrin (NCSG)
01:24:16
Alan has of course put his finger on the precise liability question that we do not have an answer to….and won’t get.
Alan Woods (RySG) (Donuts)
01:24:28
A controllers obligations should be guided by legal advice and DPA guidance …
Amr Elsadr (NCSG)
01:24:42
@James: +1
Sarah Wyld (RrSG)
01:25:10
Thanks James
Matt Serlin (RrSG)
01:25:17
+1 James
Matthew Crossman (RySG)
01:25:17
I went back and tracked down the source for the "invasive" language. It is in ICO guidance (as intrusive rather than invasive): "When is processing 'necessary'?Many of the lawful bases for processing depend on the processing being “necessary”. This does not mean that processing has to be absolutely essential. However, it must be more than just useful, and more than just standard practice. It must be a targeted and proportionate way of achieving a specific purpose. The lawful basis will not apply if you can reasonably achieve the purpose by some other less intrusive means, or by processing less data."
Matthew Crossman (RySG)
01:25:27
https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/lawful-basis-for-processing/
Sarah Wyld (RrSG)
01:25:31
Thanks Matthew, this is useful info
Amr Elsadr (NCSG)
01:25:58
Thanks, Matthew.
James Bladel (RrSG)
01:26:29
It seems consistent with ICANN’s mission that we would provide all registrants (globally) with the same privacy protections afforded under the most restrictive privacy law, which might be GDPR (or maybe CCPA or something else)
Matt Serlin (RrSG)
01:26:30
GDPR was the driver behind our work but the goal is to create a policy that isn’t specific to any one privacy policy that may be out there
Stephanie Perrin (NCSG)
01:26:52
Has to be read with the gloss that we are talking about disclosure. We are determining where the proposed processor plans on getting the data they wish to process. A proposed processor may have valid reasons to process, that does not mean that I have to give them my customer data.
Sarah Wyld (RrSG)
01:27:01
Plus, it's not only a question of where the RNH is, right? It also matters where the Registrar is, and the Registry, or other parties involved in the processing - if any of them are in the EU then the GDPR applies, right?
Sarah Wyld (RrSG)
01:27:09
+1 Matt S
James Bladel (RrSG)
01:27:42
Yeah, good point Sarah. And if the data is stored in a 3rd country (say, rented hosting provider)....
Amr Elsadr (NCSG)
01:27:49
@Sarah: Exactly. Location of data subject, controller or any processor factors in to this.
Stephanie Perrin (NCSG)
01:28:19
I wish we could kill off this TBDF question once and for all. We are creating a uniform policy. We cannot afford an engine that differentiates based on local law. Think municipal, sector specific, regional......
Stephanie Perrin (NCSG)
01:29:51
If we had done a freaking data map and DPIA we would see what a mess this is globally, what with back end providers, mobility of RNHs, insecure destinations like the Caribbean that would preclude the data leaving EU or Canada or several other countries.
Stephanie Perrin (NCSG)
01:29:59
Can we please make it stop?
James Bladel (RrSG)
01:30:26
Ok, that makes sense, but then this bullet kinda cancels out the other three. Because our product managers aren’t going to chase every jurisdiction, we’ll just apply the most restrictive law globally.
Becky Burr (ICANN Board Liaison)
01:32:04
What is “non-EEA data”? Does that take into account the location of the registry and registrar as well as the registrant?
Sarah Wyld (RrSG)
01:32:36
Becky this is what I'm asking also!
Becky Burr (ICANN Board Liaison)
01:32:48
the location of the source is irrelevant I think
Becky Burr (ICANN Board Liaison)
01:33:01
Source of the request
Amr Elsadr (NCSG)
01:33:34
@Sarah: Sounds good. +1
Stephanie Perrin (NCSG)
01:33:35
Can we draw ourselves back to look at the big picture here? We are trying to develop a policy whose goal is not ostensibly just to remove liability from the contracted parties. We are supposed to be providing uniform data protection rights for RNHs.
Amr Elsadr (NCSG)
01:34:08
@Stephanie: Yes, that’s what we’re supposed to be doing, but it isn’t actually what we ARE doing. :-(
Stephanie Perrin (NCSG)
01:34:19
It just so happens that the two aims align rather nicely with not exploring geographic distinctions, because of the global nature of ICANN’s remit.
Stephanie Perrin (NCSG)
01:34:45
And the deeply nested and integrated nature of the DNS marketplace
Stephanie Perrin (NCSG)
01:36:18
Same applies to the legal person natural person distinction, although I hesitate to wave that red flag in front of the bulls at this juncture in the discussion.
Becky Burr (ICANN Board Liaison)
01:38:28
To Stephanie’s point - and this is a personal perspective only - I would be very cautious about the competitive effects of setting up a system that applies different rules based on geography.
Alan Woods (RySG)
01:38:40
NO
Sarah Wyld (RrSG)
01:39:14
Don't we have to give this discretion to the authorization provider?
Hadia Elminiawi (ALAC)
01:39:17
+1 Alan G
Franck Journoud (IPC)
01:39:26
should be must, alan g +1
Margie Milam (BC)
01:39:33
+1 Alan G
Alan Woods (RySG)
01:39:42
The controller / disclosing party should always retain that discretion. How are you going to enforce this.
Matt Serlin (RrSG)
01:39:44
Should be may as opposed to must I’d think
Ayden Férdeline (NCSG)
01:39:45
Yes, I object. I prefer “May”. The contracted parties should have discretion.
Sarah Wyld (RrSG)
01:39:51
this should remain a MAY
Alan Woods (RySG)
01:39:58
+1 agree
Sarah Wyld (RrSG)
01:40:34
Well, the response should include an explanation of why it was denied, so there's that
Berry Cobb
01:40:42
This is a MIC check. Several of you have faint mics today. Please make sure to check your settings.
Matt Serlin (RrSG)
01:40:47
to the earlier point, it can be a reasonable request but if the data is available elsewhere, the would be a situation where MAY applies
Sarah Wyld (RrSG)
01:40:52
goodpoint matt s
Sarah Wyld (RrSG)
01:41:24
I agree that the data will likely be disclosed after this evaluation is done, but it should remain a MAY so that the auth provider retains the discretion that is required
James Bladel (RrSG)
01:41:32
+1 Sarah.
Alan Greenberg (ALAC)
01:42:45
If available elesewhere, it is not necessary.
Matt Serlin (RrSG)
01:43:32
+1 Sarah
Sarah Wyld (RrSG)
01:43:38
And this is but one example, there may be others
Alan Greenberg (ALAC)
01:43:39
If publicly availanle it is NOT necessary and didn't meet that test.
Sarah Wyld (RrSG)
01:43:50
Hm, ok.
Becky Burr (ICANN Board Liaison)
01:44:02
wouldn’t those considerations be part of the balance?
Hadia Elminiawi (ALAC)
01:44:13
@Sarah but being able to achieve it through another method is part of the balancing test
Alan Woods (RySG)
01:44:13
If there is an edge case perhaps? discretion is necessary. It may objectively balance - but subjectively, or based on legal opinion that the data should not be disclosed.
Stephanie Perrin (NCSG)
01:44:37
Publicly available data is frequently explicitly exempted under DP laws. Convenience of the requestor is not a criterion for disclosure of personal data.
Jennifer Gore (IPC)
01:44:41
I agree with Mark , I support the word ‘must’
Margie Milam (BC)
01:44:44
We need certainty - without it we have nothing to enforce
Chris Lewis-Evans (GAC)
01:45:02
+1 Mark think we should have caught everything else before this point
Sarah Wyld (RrSG)
01:45:18
We already have the opening text saying "The authorization provider should evaluate at least the following factors" - "At least" tells us that there could be more factors to consider
Sarah Wyld (RrSG)
01:45:24
so we know that this is not a complete list of factors
Alan Woods (RySG)
01:45:35
Can we please clear that the requester is not actually ENTITLED, the controller may process data (disclose) where the controller feels it is warranted. This is not a right to disclosure friends - it is.a request for disclosure.
Stephanie Perrin (NCSG)
01:45:55
+1000 Alan Woods
Mark Svancarek (BC) (marksv)
01:46:02
I did state my discomfort with "entitled"
Mark Svancarek (BC) (marksv)
01:46:13
I was struggling for the word in the moment
Alan Woods (RySG)
01:46:13
Agreed . You did … but … clarity demanded lol
Stephanie Perrin (NCSG)
01:46:19
WE rather need a whole page on this point at the beginning of this report.
Alan Greenberg (ALAC)
01:46:23
@AlanW, wby the time we get to this point, the controller has already decided the data is disclosable.
Stephanie Perrin (NCSG)
01:46:32
It is fundamental to the discussion and we keep losing track of it
Amr Elsadr (NCSG)
01:46:40
@AlanW: +1000
Franck Journoud (IPC)
01:46:54
I've lost audio
Hadia Elminiawi (ALAC)
01:47:04
In case of some unforeseen reason that we cannot think of now. the decision maker could still not disclose and then if it goes to compliance the decision maker can make its point to not disclosing
Becky Burr (ICANN Board Liaison)
01:47:10
I agree Alan Woods re data protection law analysis, but we are talking about a policy choice here.
Becky Burr (ICANN Board Liaison)
01:47:16
And stephanie
Jennifer Gore (IPC)
01:47:50
+1 Laureen
Sarah Wyld (RrSG)
01:48:01
We will have transparency becuase the response requirements building block requires it
Hadia Elminiawi (ALAC)
01:48:12
+1 Laureen
Stephanie Perrin (NCSG)
01:48:37
This is the time where I remind everyone of the fundamental charter rights of registrants. I can think of quite a few cases where a registrar or registry might be inclined to refuse disclosure based on protection of political and other charter protected rights
Sarah Wyld (RrSG)
01:48:52
+1 Stephanie. There are too many factors to mandate this
Alan Woods (RySG)
01:49:29
Agreed Becky - and I am very much concerned with the ability to enforcer this. ICANN Compliance will be in a very difficult position here, and as long as the response is reasonable - we should not be supporting a black and white delineation in our policy.
Alan Woods (RySG)
01:49:36
*enforce
Stephanie Perrin (NCSG)
01:49:39
It is not fair to assume bad faith of contracted parties. The bad actors need to be disciplined through other means, using the disclosure instrument is not the right remedy
Stephanie Perrin (NCSG)
01:50:14
In other words, go for the criminal elements through other means.
Stephanie Perrin (NCSG)
01:50:33
We are assuming compliance is the enforcer???
Laureen Kapin (GAC)
01:50:53
To be clear, I assume good faith but there must be some clear criteria so requestors have reasonable expectations about how to proceed.
Sarah Wyld (RrSG)
01:51:35
I don't think a centralized auth provider could evaluate the factors in section 7, but we can deal with that when we're selecting a Model...
Franck Journoud (IPC)
01:52:35
61f already requires consideration of fundamental rights of data subject.
Sarah Wyld (RrSG)
01:53:04
Sure Franck, but not every request falls under 61f and they can still require meaningful human review
Alan Greenberg (ALAC)
01:53:34
"must normally be disclosed" and adding a process for documenting why an exception is made.
Sarah Wyld (RrSG)
01:54:45
I will point out again that our intro text for section 7 acknowledges there could be other factors to consider, so we have already confirmed that this is an incomplete list and there could be other reasons to deny the request.
Franck Journoud (IPC)
01:55:32
@sarah: so which of the 61a thru 61e would jeopardize the fundamental rights of the data subject?
Hadia Elminiawi (ALAC)
01:56:34
@Sarah all the other reasons that we mentioned before happen before the balancing test NOT after
James Bladel (RrSG)
01:57:00
Bad actor registrar won’t bend the knee to Compliance. They’ll lawyer up and we’ll lose the whole burrito
Caitlin Tubergen
01:57:26
For reference, the response requirements building block includes the following language: d) Responses where disclosure of data (in whole or in part) has been denied should include: rationale sufficient for the requestor to understand the reasons for the decision, including, for example, an analysis and explanation of how the balancing test was applied (if applicable). Additionally, in its response, the entity receiving the access/disclosure request must include information on how public registration data can be obtained.
Stephanie Perrin (NCSG)
01:57:37
Please James, no food analogies.
Mark Svancarek (BC) (marksv)
01:57:43
lol
Mark Svancarek (BC) (marksv)
01:58:34
@James, please explain. I think you are saying that the legal resistance of a noncompliant data controller puts the whole system at risk?
Amr Elsadr (NCSG)
01:58:44
@Alan: +1
Becky Burr (ICANN Board Liaison)
01:59:04
Doesn’t current policy require disclosure to serve legitimate and proportionate interests? FWIW, if decision-making is dispersed, I am not sure “may” or “must” matters.
Alan Greenberg (ALAC)
02:00:29
@BEcky, yes, and now we are trying to write policy to do that.
Alan Woods (RySG)
02:00:37
Because we don’t feel like it - Sigh - I we get it wrong … we get fined ….
Alan Woods (RySG)
02:00:59
*if
Alan Greenberg (ALAC)
02:01:10
Law saying something can not be enforced by Compliance. It requires our policy to say it.
Sarah Wyld (RrSG)
02:01:51
We could consider using "SHOULD" instead of "MAY"? SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
Alan Woods (RySG)
02:02:01
+1 Sarah
Becky Burr (ICANN Board Liaison)
02:02:17
I understand Alan G., my point is that from a compliance perspective it is awfully difficult to second guess a controller’s call on the balancing test.
Becky Burr (ICANN Board Liaison)
02:02:31
As the controller is on the hook
Matt Serlin (RrSG)
02:02:32
I would suggest we take this to the mailing list to try and resolve this as it feels like we could go round and round on may/must forever
Matt Serlin (RrSG)
02:02:44
And Sarah’s proposal is reasonable and should be considered
Alan Greenberg (ALAC)
02:03:15
@Becky, we are not tring to second guess the balancing test in this section.
Stephanie Perrin (NCSG)
02:03:18
+1 Becky, +1 Sarah
Stephanie Perrin (NCSG)
02:03:24
Should is a good word.
Franck Journoud (IPC)
02:03:40
+1 @hadia
Mark Svancarek (BC) (marksv)
02:04:03
SHOULD is helpful to me, as defined in IETF. Is it well-understood in this context by this community? (does it need a footnote to define?)
Stephanie Perrin (NCSG)
02:04:22
It is well understood in the standards community.
Sarah Wyld (RrSG)
02:04:34
I don't think it needs a footnote, our policy incorporates the ietf definitions, right?
Sarah Wyld (RrSG)
02:04:49
We have that in the response requirements already
Sarah Wyld (RrSG)
02:04:55
we should not duplicate things between sections
Mark Svancarek (BC) (marksv)
02:05:20
In that case I like SHOULD.
Alan Greenberg (ALAC)
02:06:07
+1 Margie
Laureen Kapin (GAC)
02:06:27
+1 we need a policy that's enforceable.
Sarah Wyld (RrSG)
02:08:09
I would actually propose that we remove everything from this block about providing rationale
Sarah Wyld (RrSG)
02:08:13
it is covered in the response rquirements
Sarah Wyld (RrSG)
02:08:15
and we should not duplicate
Sarah Wyld (RrSG)
02:10:01
You bet, thanks Janis.
Alan Greenberg (ALAC)
02:10:06
@Sarah, disagree. These rationales may not be in response.
Hadia Elminiawi (ALAC)
02:10:16
+1 the policy must be enforceable, using must is the best way here even with Margie's suggestion
Sarah Wyld (RrSG)
02:10:20
@Alan it says "Responses where disclosure of data (in whole or in part) has been denied should include: rationale sufficient for the requestor to understand the reasons for the decision, including, for example, an analysis and explanation of how the balancing test was applied (if applicable). "
Sarah Wyld (RrSG)
02:10:21
pretty clear
Alan Greenberg (ALAC)
02:11:40
@Sarah. Correct. But we are discussing a case where the balancing test passed but data not released for other reasons (requestor is know to be slimy... ;-) )
Stephanie Perrin (NCSG)
02:12:03
We need first of all a policy that complies with law.
Stephanie Perrin (NCSG)
02:12:31
We can measure the non-compliance with disclosure requests once it is up and running, and figure out how to deal with it then.
Hadia Elminiawi (ALAC)
02:12:34
if the requestor is known to be slimy.. the balancing test should not take place
Hadia Elminiawi (ALAC)
02:13:27
why would you do a balancing test when you know the requestor is a bad actor?
Alan Woods (RySG)
02:13:32
Because it will be weeded out by the accreditation .. right … because accreditation can never be wrong?
Stephanie Perrin (NCSG)
02:14:15
Complaints about non-compliance with disclosure requests could form the basis of a decent research project that analyzes the requests and whether they are proportionate, properly formatted, etc. We needed this research prior to commencing the project but better late than never. Current evidence provided in presentations to the GAC (which by the way is hard to dig out of the records) is quite inadequate
Stephanie Perrin (NCSG)
02:17:05
Purposes of an accreditation process: cut costs, reduce burden on legitimate requesting parties and legitimate complying parties (controllers), promote trust. This whole SSAD…..it should not be predicated on removing liability (as it has been IMHO) it should be based on the goal of promoting trust and compliance with law and fundamental rights. And I mean all law, not just DP law.
Becky Burr (ICANN Board Liaison)
02:17:31
I do not understand what is meant by the origin of the requested data
Sarah Wyld (RrSG)
02:18:03
+1 Becky
Sarah Wyld (RrSG)
02:18:14
I think it may refer to the data subject's apparent location based on registrant country?
Becky Burr (ICANN Board Liaison)
02:18:39
But the residence of the registrant is not determinative
Sarah Wyld (RrSG)
02:18:42
Agreed
Sarah Wyld (RrSG)
02:18:54
(That's why CPH flagged it as a question)
Matt Serlin (RrSG)
02:18:56
the goal here is a global policy…
zzzVolker Greimann (RrSG Alternate)
02:19:02
The origin of the data obviously is the data subject.
Ayden Férdeline (NCSG)
02:19:03
No, there is no ruling about the GDPR only being applicable to citizens - it is applicable to “residents” of the EU. But I agree with Amr that we should be developing policy recommendations with global effect.
zzzVolker Greimann (RrSG Alternate)
02:19:18
oops
zzzVolker Greimann (RrSG Alternate)
02:19:25
Please disregard this alt
Becky Burr (ICANN Board Liaison)
02:19:40
Strongly agree that the goal is a global policy
Alan Woods (RySG)
02:19:42
Yup I wouldn’t say only the GDPR - but apply principles that are … reminiscent of the GDPR perhaps
Alan Woods (RySG)
02:20:10
High water marks with carve outs when more ‘restrictive’ or comprehensive’ rule may / do exist?
Alan Woods (RySG)
02:21:55
+100 James!
Becky Burr (ICANN Board Liaison)
02:22:23
Yes, as I said, the market implications of a geo-specific policy are very worrisome.
Amr Elsadr (NCSG)
02:22:30
@James: +1000…, and we covered all of this yesterday.
Sarah Wyld (RrSG)
02:23:05
I would suggest removing all the bullet points about EEA vs non-EEA.
Matt Serlin (RrSG)
02:23:19
Agreed
James Bladel (RrSG)
02:23:40
@Sarah - that would certainly make things simpler
Stephanie Perrin (NCSG)
02:29:24
+1000 Alan W
Chris Lewis-Evans (GAC)
02:29:30
+1
Amr Elsadr (NCSG)
02:32:52
Having 2 calls/week is very challenging/burdensome. Just sayin’.
Sarah Wyld (RrSG)
02:33:38
Thanks, all.
Hadia Elminiawi (ALAC)
02:33:46
thank you all bye
Chris Lewis-Evans (GAC)
02:33:51
Thanks bye
Marc Anderson (Verisign / RySG)
02:33:54
thanks all