
48:57
Good <time of day at local location>

49:24
Hi, I sent an apology, but can make most of the call.

49:40
I will also be able to speak to the draft proposal I sent.

50:17
hello al

50:20
Noted Thomas

51:43
Out of principle, I don't think the agenda should be longer than 90 minutes. Sure, it might stretch, but we should at least aim for 90 minutes.

53:21
Julf that ship has sailed. Or putting it another way:we have drowned already.

54:26
Farzaneh: I can still grumble about it...

59:23
But so many times we have been discussing whether public authority can have access without relying on a national law… we have to wrap this discussion up one way or another.

01:00:55
I tend to agree. A user group doesn't assume anything other than they may have a legitimate interest based on their common goals/mission.

01:01:31
I think we are often conflating legitimate interest, purpose and user groups as if they are one in the same and they are not.

01:02:02
Agree, Ashley.

01:02:19
Very good point Ashley

01:02:24
sorry to join late

01:02:28
And for not muting audio

01:05:27
+1 Ashely. Legitimacy/Purpose isn’t inherited by all members of a user group.

01:05:39
Perhaps a doc that lists user groups (with the assumption that we are considering it), with another section for each user group that lists legitimate interest (kind of what this doc is doing), then another field for purpose. So it is all there (unless I'm missing something) and we won't get wrapped around the axle regarding what we are talking about because it will all be on the same page. I know folks won't like listing user groups at the outset, but let's perhaps take it as an informed exercise that can be changed as need be.

01:06:06
I like how you put that, James.

01:07:36
But each user group *could* have similar legitimate interests and purposes, so perhaps listing them as a menu as a first step? Recognizing that they don't automatically apply, but could apply. As it will all be determined per request, correct? And must be substantiated, correct?

01:07:40
so therefore makes more sense to categorise by legal basis - not by group

01:08:13
I don't care what order (I don't think), whether it starts with legal basis or group.

01:08:36
(sorry Ashley that was @Hadia)

01:08:54
Still a good point for me to consider. :-)

01:09:41
@Alan W. but who/how to determine whether a certain user group can make use of a certain legal basis? For some it is clearly defined, but for some there was disagreement during phase 1. If I recall well, in phase 1 it was left up to the controller what legal basis to apply, would it be the same here (the third party requestor determines which legal basis they want to use for their request and the controller assess whether or not it is deemed appropriate?)

01:10:40
true..... i think we are making this so much harder for ourselves. There are 6 legal bases. and we might drill down into potential groups but we must resist presupposing answers, unless the law removes the burden on the controller.

01:10:41
haha

01:10:53
Amen.

01:10:59
(laughing at Thomas' joke)

01:11:55
Makes sense, Alan W. Let's start from legal bases and purposes.

01:11:58
legitimate interest is not really a new GDPR thing. There are even court cases about it because of the 95 directive

01:13:50
Each disclosure has a clear logic thread comprising of legitimate interest/group/legal basis/data. We should not waist more time to see how they group or which gets precedence over the other and start working on concrete cases as Thomas does with his example. Then see whether we are comprehensive

01:14:14
@marika it is up to the the controller to set their legal basis for processing - we are talking about 3rd parties who are asking us to do something (disclosure to thme) which is outside of our specific purpose. (hence why Recommendation 1 purpose 2 was such a nightmare, as it is clear that people wanted to make it an 'ICANN purpose' as they knew that the law provides a limitation on disclosure to 3rd persons (balancing test - or legal obligation. Those requesting disclosure must establish their own legal basis - we cannot do it for them. My job is to register domains .... not figure out how the world and its mother can get access to the data i hold for that core purpose!

01:14:42
I agree with Thomas!

01:14:59
Thomas +1

01:16:49
@thomas if the purpose of LE is investigation then for sure it is not 6(1)f I was only saying that if public authorities could demonstrate that the processing is not part of performing your tasks as a public authority

01:18:01
@thomas if the purpose of LE is investigation then for sure it is not 6(1)f I was only saying that if public authorities could demonstrate that the processing is not part of performing their tasks as a public authority then it could be 6(1)f

01:18:19
@Hadia - how can a LEA investigation and associated disclosure requests possibly not the core task?

01:18:39
@Alan - thanks for that response. So do I understand correctly that you are suggesting that the group should be agnostic to which user group invokes which legal basis, but instead focus on what the process and steps are based on the legal basis invoked by the requestor?

01:19:15
Public authorities have their own rules on how they may process data, but ICANN is not a public authority. I don’t see how the status of public authorities has any relevance, if they are 3rd parties.

01:19:21
yes. That's the starting point in my mind

01:19:45
ok, thanks

01:20:17
@Thomas A LEA investigation is for sure a core task I was only thinking if there is another task that is not core and for which they need a disclosure

01:23:06
Agree, Margie and Mark.

01:23:10
+1 Margie re scope.

01:23:13
+1 Margie The purpose of the third parties will determine the legitimate interest and thus the lawful basis

01:23:29
@Hadia, I agree in theory, but cannot think of a real-life scenario in which this would apply.

01:23:30
It is good to start with the purposes of the third parties

01:23:50
slight reminder that i'm in the queue.........

01:25:07
Great points Greg

01:25:27
er? What is within ICANN scope? Non of these legitimate interests are. helping academic researchers etc? ICANN might be able to provide disclsure as a co-controller (I don’t know, have to look at it legally ) but these legitimate interests are not within ICANN scope

01:26:07
+1 Greg - defining these is important to ensure predictability and also to ensure we address the questions in the charter.

01:26:54
this is a global policy

01:27:10
Did you hear the shot? I hope everyone is fine

01:27:12
Oh now it is a global policy :)

01:27:32
Blast was in GVA outside my window

01:28:06
Alan W’s making a lot of sense to me today!!

01:28:07
oh yeah. GVA is the battlefield of bureaucrats

01:28:36
Georgios, can you help with the question / proposal I mentioned?

01:28:49
I have been agreeing with Alan since the past how many meetings? He has been repeating these points all the time.

01:30:01
Unfortunately, I think there is alot of talking past each other going on. :-(

01:30:18
roll on the face to face ... we work better in them! :D

01:30:36
See the EU Comments on the Final Report: For instance,an IPR rightholder might have a legitimate interest to gain access to WHOIS personaldata in order to ensure his/her IP right is protected and not abused. T

01:31:13
I think we need to do our best not to assume motivation. A huge hurdle is getting past what we think the other side is trying to do or thinking... and most of the time we are wrong in our assumptions.

01:31:15
yes ..... under 6(1)f -- do you suggest we ignore the balancing test margie?

01:31:24
+1 Alan G - we need to get to substantive discussion - we have yet to start working on our homework -

01:31:47
+ 1 Ashley

01:32:05
No - we have to look at the legal basis - 61f is just one - per EU letter

01:32:40
Indeed we need to get started

01:32:59
Margie, from the menu in Art 6, we are pretty much stuck with 6 I c and f for this one I am afraid

01:33:18
nope ... not you Mark! lol

01:33:27
@Margie: Your statement regarding IPR protections needs to be qualified by a few things, including the balancing test in 61f, as well as limiting abuse of IPR to the domain name registered. Also, shouldn’t we be referring to Trademarks, not IP?

01:33:57
Thomas - also public interest & consent

01:34:09
no it would not ... you are not the controller in our processing ... you are a requester

01:34:29
@amr - not at all. we must not limit our discussions to only TM.

01:34:38
let's!

01:34:40
Wait….if the Registrar isn’t a party to that contract?

01:34:59
exactly james ... confused separate spheres of processing

01:35:02
“Public Interest” is so vague. Better to be specific on what is being referred to.

01:35:34
@Margie - public interest would require a legal act vesting ICANN / cps with performing a task in the public interest. There does not seem to be any such legal act.

01:35:50
Yeah honestly Mark I am so confused by what you are saying. Registrars have a contract with registrants. You have another contract probably with the same domain name registrant but I don’t think that establishes 6Ib

01:35:56
On opt-in. That is an options we can build, yes.

01:35:58
that's your assumption Thomas - ask Bird & Bird

01:36:09
we should get legal advice on that

01:36:15
@Alex: I’m unaware of any ICANN policy that provides protections to IPRs other than Trademarks (even specific types of TMs). Have I missed anything?

01:36:22
@Margie - let’s do that, yes.

01:36:24
James, that's right - the RR is not subject to the contract under which I am requesting the data on behalf of my customer

01:36:25
which means threat to life - and of course law enforement can... as i have said a number of times now

01:36:39
6(1)(e) is the public interest basis

01:36:39
*enforcement

01:37:13
no-- threat to life is 6(1)(d)- vital interests of the data subject or of another natural person

01:37:24
And Mark - would you produce that contract as part of a disclosure request? I’m not clear how we would guard against those claiming they were serving a contract, but it was confidential...

01:37:57
@amr - I fully understand you (and others) believe only TM in “in scope”. I don’t agree.

01:37:58
+1 Janis.

01:38:15
the existence of you having a contract with the data subject is a) separate to our data processg and b) a pretty good basis for a legitimate interest .......

01:39:11
James - I did mention that challenge in my intervention :) and its the same challenge we have in 61f - what do you know about the requestor and their circumstance

01:39:43
I'm happy if Thomas is available to discuss the approach

01:39:54
I don’t want to dismiss the idea Mark. As you probably know, we activate a LOT of Office365 for our customers (esp. email). But I don’t know how that separate contract would govern a disclosure request.

01:40:00
We'll get more into the substance in due time of course

01:40:02
Need some more work on that.

01:40:34
James and MarkSv, sounds like something the Birdies might be able to help clarify too.

01:50:58
@ Thomas can we also forsee what is under safeguards is considered in codes of conduct as in GDPR art.40?

01:54:23
@Thomas I like your approach and I think i could work

01:54:29
it

01:54:55
@Georgios - I think writing this up properly, i.e. filling it with life might probably be enough.

02:02:01
I also think i would be helpful to map the charter questions to the sections in thomas’s doc. this will ensure we end up with the answers we need at the end of the process.

02:06:47
in other words Janis we don’t agree with all of it :)

02:06:50
@Janis: Great. Thanks.

02:08:32
I thought that Janis was asking for volunteers to work on THIS use case.

02:08:38
Agree with Marc that taking this one all the way through might be a better path forward

02:08:48
In all honesty, and I am sorry to be the antagonist here but I think use cases are the wrong approach. We need to discuss principles of establishing legitimate interest

02:09:05
As I said, I think this is a learning exercise and not one we can use to "boil the ocean"

02:10:06
I am all for learning. I love to learn (new things)

02:10:25
Speaking for myself, I’d like to focus on one use case, at least for a while, until we understand how our work will progress. Alan G raised a concern regarding how to generalize this, which is fair.

02:11:24
Correct, I volunteer.

02:11:43
yeah. Speaking for myself I don’t think working on use case is a starting point.

02:11:45
I'll take as much help as I can get, feel free to DM me.

02:12:27
agreed Chris ... that seems very prudent!

02:12:37
For those wanting to work on use cases, we will post an empty version of the template on the wiki.

02:13:12
@Alan enough to cover all legal basis’s

02:13:20
+1 Alan makes sense

02:14:07
Yes. The idea is to be able to group and broaden them later.

02:14:42
Agree with Amr…I don’t think tackling an unlimited number of use cases right now would be prudent

02:16:43
I just want to record my opinion about this approach: I don’t agree with it. We have been documenting use cases since RDS! We even have a sheetstaff provided. We need to discuss the use cases eliminate or keep them based on the principles of establishing legitimate interest

02:18:20
Yup. The use cases on the RDS PDP proved pretty pointless, and a ton of time was spent on them.

02:19:33
Note that the deadline for input is tomorrow (21 June), so far no input has been received.

02:19:48
For the ISPCP I can say we will need more time to provide input.

02:19:50
Oh tomorrow? Why did I think Monday

02:20:31
IPC my also need more time.

02:22:39
BC may need more time

02:22:54
NCSG too, as usual.

02:22:54
GAC too...

02:24:15
Note that this is intended to be early input - the further the EPDP Team has gone along in its deliberations, the more difficult it may be to review and factor in this input, or it may require going backwards on what was already discussed.

02:24:47
Our issue is getting a draft ok'd by the broader GAC. That takes time and right before an ICANN meeting is very difficult.

02:25:33
Yeah +1 Alan

02:26:08
let's maximize the value of our limited time together

02:27:16
Oh wow. GAC is on top of things … :)

02:28:44
TBQH - you are required to ask for early input. You have done that now so we can tick that off the list. I would prefer not to to provide it at this stage.

02:29:09
Yes, it is a required step as this EPDP is in two phases, but there is no requirement for anyone to provide input if they are of the view that their input has already been provided.

02:29:17
So the requirement is to ask, not for groups to provide :-)

02:29:24
It is very difficult to come up with comprehensive answers at this stage, this is different than the phase 1 triage. To provide full answers now to the charter questions is quite impossible, that means doing all the work now. As work proceeds those answers can be provided. General comments are possible though.

02:34:56
Need to catch a flight, will stay on audio. thanks all and see you in Marrakech.

02:36:02
So next week meeting will be in Morocco?

02:36:29
Correct

02:36:29
Amr +1

02:36:37
Need to drop off. Bye all!

02:37:10
Then I won’t be there yippie. Might appoint an alternate or be the remote participant champion. There is RP right?

02:37:11
+1 Amr

02:37:12
I think we are trying to rush through this, and results suffer.

02:38:16
yeah workstreams and dozens of sheets and use cases

02:39:41
Slowing down doesn’t necessarily mean achieving the outcome late. but we need to focus one one issue at the time.

02:40:04
I think it’s less about adding calls, and more about using our call time more efficiently.

02:40:09
Yes

02:42:12
Agree with James. I'd rather keep the same schedule and focus more on making progress.

02:42:26
+1

02:43:07
@james - agree. Hopefully our decision to get to work on Thomas’ template will allow us to make good progress on real issues.

02:43:24
Thank you all - bye

02:43:24
Safe travels all
Zoom would like to update your account settings. When joining a meeting or webinar by entering a meeting ID, participants will be required to enter a password. Participants joining using a meeting invite link will not be required to enter a password. Learn More
This change will be effective on . If approved or declined, the change will take effect immediately.