Logo

Julie Bisland's Personal Meeting Room
Chris Lewis-Evans (GAC)
51:58
sorry for being late
Becky Burr (ICANN Board Liaison)
01:03:00
Just trying to understand - is the message to the board that lack of clarity is more likely to result in the current situation being cemented? Perhaps this should be clearer so the board fully understands?
James Bladel (RrSG)
01:03:07
Thanks, Janis. Anything edits that capture the intent without being adversarial are welcome.
Amr Elsadr (NCSG)
01:04:26
Speaking for myself, I like the letter. Addresses a very straight forward and narrow scope, and seeking a clear answer with rationale on why the answer is important.
Ashley Heineman (GAC)
01:04:29
Can we ask clearly for a response in writing (either from Board or Org) that articulates what ICANN is willing to do vis-à-vis responsibilities and liability?
Amr Elsadr (NCSG)
01:04:43
Also…, I kinda like that ultimatum at the end. :-)
Amr Elsadr (NCSG)
01:05:13
@Ashley: Good suggestion. +1
Ashley Heineman (GAC)
01:07:20
Further to last point, and Chris' intervention, it might be good to attach the questions for Org as well. Make it very clear that we need answers and/or understanding from ICANN as to what they are willing to take on (in writing)
James Bladel (RrSG)
01:08:11
I like where Chris is going but he’s breaking up a bit
James Bladel (RrSG)
01:08:24
(Or maybe just on my end)
James Bladel (RrSG)
01:10:10
The key is to be direct in our questioning, without coming across as confrontational.
Becky Burr (ICANN Board Liaison)
01:11:46
Happy to help
James Bladel (RrSG)
01:12:10
Thanks all.
Brian King (IPC)
01:12:44
James and Becky, feel free to take this and either scrap it or redline from here: "We appreciate the board’s constructive engagement with the EPDP to date, and we thank you in advance for this necessary guidance to ensure our policy recommendations are acceptable to the board.”
James Bladel (RrSG)
01:13:40
Copied, thanks Brian.
Marika Konings
01:14:10
You can find building block d and h also here: https://docs.google.com/document/d/1irlBo_oE5WqxTir5URaxlpPWTn17cnjDz72L79gOjOI/edit
Brian King (IPC)
01:19:16
+1 Margie, incorporate the auditing building block by reference here would be good
Margie Milam (BC)
01:19:33
yes
Marika Konings
01:19:49
The accreditation building block also has some auditing requirements that could be moved to the new building block (and referenced)
Brian King (IPC)
01:20:01
that's the smart way to do it because it keeps this building block focused on its intended topic
Matt Serlin (RrSG)
01:20:03
I think the more clarity and guidance we can provide around what our intentions are regarding audits would certainly be good
Becky Burr (ICANN Board Liaison)
01:20:43
Record of processing activities is a GDPR requirement
Amr Elsadr (NCSG)
01:22:27
Are we still using “purposes with the purpose for which the data was requested”?!
Amr Elsadr (NCSG)
01:22:57
Sorry…, left out the most important word “Are we still using “purposes consistent with the purpose for which the data was requested”?!
Volker Greimann (RrSG)
01:23:39
To Becky, it is, but we are trying to be privacy law neutral, so we may need to spell certain requirements out to ensure our process meets certain requirements.
Becky Burr (ICANN Board Liaison)
01:25:32
GDPR language - “not processed further in a manner that is incompatible with” the specified purpose
Hadia Elminiawi (ALAC)
01:25:57
+1Becky
Becky Burr (ICANN Board Liaison)
01:25:59
Agree @Volker, wasn’t saying it was not necessary
Volker Greimann (RrSG)
01:26:08
+1 Becky
Amr Elsadr (NCSG)
01:26:13
@Becky: My understanding is that the language you’ve quoted is applicable to data controllers, not 3rd parties.
Georgios Tselentis (GAC)
01:26:19
Agree with Brian currently there is a pleonasm +1 to Becky as alternative
Becky Burr (ICANN Board Liaison)
01:27:05
@Amr, this is from Article 5, principles, and my understanding is that it should be applicable to all processing.
Margie Milam (BC)
01:27:57
Section 5 a.b
Margie Milam (BC)
01:28:01
1b
Brian King (IPC)
01:28:07
+1 to "incompatible"
Becky Burr (ICANN Board Liaison)
01:28:17
if a controller is transferring data to a service provider, then you would likely require a “for the specified purpose and no other.” But here the transfer would be C2C
Brian King (IPC)
01:28:23
right, "compatible" in this context
Becky Burr (ICANN Board Liaison)
01:29:07
I would use “incompatible” rather than compatible
Amr Elsadr (NCSG)
01:29:40
@Becky: The reason Article 5.(b) is not applicable here is that it refers to original purposes for which the data was COLLECTED (which to me also implies purposes of the controller). We’re talking about entirely different purposes now that are exclusive to 3rd parties seeking disclosure.
Amr Elsadr (NCSG)
01:30:43
3rd parties do not determine the purposes for which a controller collects data.
Becky Burr (ICANN Board Liaison)
01:31:22
@Amr, goes back to purpose 2 issues
Margie Milam (BC)
01:31:31
yes
Amr Elsadr (NCSG)
01:31:35
@Janis: Sure.
Alan Woods (RySG)
01:31:51
absoultely agreed Volker .... but we are fast getting into that the disclosee is 'compliant' with data protection law as applicable to them. That is a huge ask for us to 'audit' or confirm - we can only recommend obligations that we are able to achieve...
Amr Elsadr (NCSG)
01:32:06
@Becky: And we’ve heard that purpose 2 cannot be a purpose, haven’t we?
Amr Elsadr (NCSG)
01:32:21
At least not a legitimate one with sound legal basis.
Becky Burr (ICANN Board Liaison)
01:32:32
@Amr, I think we’ve heard very confusing things about purpose 2 ...
Amr Elsadr (NCSG)
01:33:09
I think we were all confused when we came up with it. :-) It was more of a failed attempt at a compromise than anything anybody actually liked.
Ashley Heineman (GAC)
01:33:17
@Amr, I believe we were asked to reword it, not that it couldn't be a purpose outright.
Becky Burr (ICANN Board Liaison)
01:33:40
And @Ashley, I think that is what the second communication from the Commission suggested.
Becky Burr (ICANN Board Liaison)
01:33:48
the clarification
Amr Elsadr (NCSG)
01:33:58
@Ashley: That’s correct. If I may, I’d say we were asked to spin it to make it more legally appealing.
Hadia Elminiawi (ALAC)
01:34:13
@Amr no we have heard that purpose 2 is an activity associated with a purpose and not a purpose on its own.
Amr Elsadr (NCSG)
01:34:29
Yup. Needs some spin.
Marc Anderson (RySG)
01:35:38
He's not on the call
Alan Greenberg
01:36:50
I am on the call now. Sorry to be late.
Amr Elsadr (NCSG)
01:39:53
Same here. I think the staff comment is very helpful.
Hadia Elminiawi (ALAC)
01:39:56
Welcome Alan
Alan Woods (RySG)
01:40:13
+1 Marc
Alan Woods (RySG)
01:43:57
If it was that clear Hadia .... we'd have been finished months ago!
Alan Woods (RySG)
01:45:14
From a 'code of conduct; point of view - we need more than - must follow the law. Specificity is vital.
Hadia Elminiawi (ALAC)
01:47:31
@Alan I am fine with leaving it - I was just thinking there are two other required tests in relation to the legitimate interests
Matt Serlin (RrSG)
01:48:57
Yeah I had the same question…how would this work in practice?
Brian King (IPC)
01:50:17
Deletion would be preferable
Alan Woods (RySG)
01:51:57
https://gdpr-info.eu/art-21-gdpr/ right to object
Amr Elsadr (NCSG)
01:52:17
@Janis: That’s fine by me, so long as we don’t lose this. Doesn’t really matter where it is, does it?
Alan Woods (RySG)
01:52:47
not to point at the elephant in the room - but the inclusion here doe really depend on who the data controller(s) is/are
Alan Woods (RySG)
01:52:52
*does
Amr Elsadr (NCSG)
01:53:35
@Alan W: Thanks for that link. @Staff: Could we capture this as a reference to review in attempting to work this out?
Hadia Elminiawi (ALAC)
01:53:41
https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/individual-rights/right-to-object/ right to object
Alan Woods (RySG)
01:54:23
Well if I was the data subject ..... I' probably just take it up with the DPA ... but ...
Chris Lewis-Evans (GAC)
01:54:28
+1 Brian
Amr Elsadr (NCSG)
01:54:40
@Staff: As well as the ICO link that Hadia posted?
Marika Konings
01:54:50
Will do!
Amr Elsadr (NCSG)
01:55:10
Thanks.
Georgios Tselentis (GAC)
01:55:16
yes the right to object is the key artcle here
Brian King (IPC)
01:55:44
ha, I got ahead of myself, sorry
Margie Milam (BC)
01:56:28
going offline to drive - but will be on the phone
Amr Elsadr (NCSG)
01:57:04
@Marc: Indeed.
Brian King (IPC)
01:58:36
I'm not aware of any such provision
Alan Woods (RySG)
01:58:38
correct.
Alan Woods (RySG)
01:59:04
art 10 (1) e)
Mark Svancarek (BC) (marksv)
01:59:10
My understanding is the same as Becky's
Alan Woods (RySG)
01:59:13
sorry art 13 (1) e
Alan Woods (RySG)
01:59:14
the recipients or categories of recipients of the personal data, if any;
Chris Lewis-Evans (GAC)
01:59:17
+1
Chris Lewis-Evans (GAC)
01:59:23
to becky
Chris Lewis-Evans (GAC)
02:00:47
CAnt hear Alan
Mark Svancarek (BC) (marksv)
02:00:55
Alan is breaking up
Hadia Elminiawi (ALAC)
02:01:18
Alan W still breaking
Alan Woods (RySG)
02:01:34
i'll put it in chat
Alan Woods (RySG)
02:01:38
:)
Brian King (IPC)
02:04:36
Perhaps James would be happy if this was noted as an exception to the logging requirement?
Ayden Férdeline (NCSG)
02:07:50
+1 James - we cannot fix the problems with MLATs; if they are slow or dysfunctional, that is something for law enforcement to solve
James Bladel (RrSG)
02:13:44
Noting that SSAD is an extra-legal system for accessing public data. If LEA requests are out of balance with data subject rights (GDPR or the US Bill of Rights), then the query doesn’t belong in SSAD.
Amr Elsadr (NCSG)
02:13:59
@James: +1
James Bladel (RrSG)
02:14:23
sorry..non-public data.
Chris Lewis-Evans (GAC)
02:14:27
sure
James Bladel (RrSG)
02:15:27
Yes, would welcome Staff help in keeping track of everything I’ve agreed to
Alan Woods (RySG)
02:16:19
completely disagree with Mark there. Telling the data subject that someone, at some time MAY want your data, and we may disclose - is running riot over data subject rights.
James Bladel (RrSG)
02:16:24
Amr - some laws also would/could require transparency reports from Registrars. This provision might cause us to break those obligations.
Mark Svancarek (BC) (marksv)
02:16:30
I agree with Amr, those are different things
Amr Elsadr (NCSG)
02:16:43
@James: Another issue to consider. Agree.
Alan Woods (RySG)
02:17:03
(sorry my comment was relating to your earlier point - i never hit enter lol )
Brian King (IPC)
02:19:41
Yes, my point was for unaffiliated P/P data
Marika Konings
02:19:49
There is a P/P item that was deferred to priority 2
Matt Serlin (RrSG)
02:20:25
If they are unaffiliated, how does the registrar know it’s a P/P provider??
Mark Svancarek (BC) (marksv)
02:20:49
They will know upon inspection at the time of disclosure balancing test
Brian King (IPC)
02:21:11
Mark took the words out of my mouth
Marika Konings
02:21:37
As a reminder, this is the priority 2 item: As part of phase 1, the EPDP Team made the following recommendation: “In the case of a domain name registration where an "affiliated" privacy/proxy service used (e.g. where dataassociated with a natural person is masked), Registrar (and Registry where applicable) MUST include in the public RDDS and return in response to any query full non-personal RDDS data of the privacy/proxy service, which MAY also include the existing privacy/proxy pseudonymized email.Note, PPSAI is an approved policy that is currently going through implementation. It will be important to understand the interplay between the display of information of affiliated vs. accredited privacy / proxy providers. Based on feedback received on this topic from the PPSAI IRT, the EPDP Team may consider this further in phase 2”.
Matt Serlin (RrSG)
02:21:50
I’m not sure that’s always going to be obvious really…
Volker Greimann (RrSG)
02:22:08
Potential rewrite “…must disclose non-public data clearly not belonging to a data subject protected under applicable data protection regimes.”
Volker Greimann (RrSG)
02:22:30
Sorry: “clearly identifiable as"
Mark Svancarek (BC) (marksv)
02:23:06
I like Volker's rewrite, any concerns?
Volker Greimann (RrSG)
02:23:20
to matt: Absolutely, and under this language disclosure would be limited to clearly identifiable cases.
Matt Serlin (RrSG)
02:23:37
Yeah I think that works
Volker Greimann (RrSG)
02:23:37
Any iffiness and there would not be disclosure
Ayden Férdeline (NCSG)
02:23:42
No, it should not be the responsibility of the data subject.
Mark Svancarek (BC) (marksv)
02:24:12
any iffiness and it's just a normal legitimate interest balancing test
Hadia Elminiawi (ALAC)
02:24:17
That is what ARIN and Ripe are doing
Matt Serlin (RrSG)
02:24:46
iffiness…I like that :)
Brian King (IPC)
02:25:16
We're open to discussing Volker's suggestion
Brian King (IPC)
02:25:31
We might suggest a different standard, but let's work on it.
Hadia Elminiawi (ALAC)
02:25:53
Volker's suggestion could work
Brian King (IPC)
02:26:23
I note that disclosure of data for accredited P/P providers could be easily identified and in fact automated. The accreditation of P/P providers would make this easy.
James Bladel (RrSG)
02:26:40
Need to drop in 7 min. Thanks!
Brian King (IPC)
02:28:24
+1 Margie
Chris Lewis-Evans (GAC)
02:28:40
Unique identifier
Margie Milam (BC)
02:28:53
unique identifier is better
Amr Elsadr (NCSG)
02:30:01
I have no concerns with Brian’s comments. Makes sense.
Amr Elsadr (NCSG)
02:30:17
Sorry. Comment, not comments. ;-)
Amr Elsadr (NCSG)
02:31:11
Ayden’s got a point though. Practically speaking.
Ashley Heineman (GAC)
02:31:15
would an "affirmation" give something? IE: you went against your affirmation?
Volker Greimann (RrSG)
02:31:55
for c) it should be specific information, not just information. We should aim to eliminate “pick and choose” requests where a complainant ;lists a dozen possible violations and that the domain violates one of them.
James Bladel (RrSG)
02:31:56
Not that I disagree with Ayden, but “bad faith” users will also agree to (d)…:(
Amr Elsadr (NCSG)
02:32:21
@James: Exactly…, which if I’m not mistaken, is the point Ayden is making.
Alan Woods (RySG)
02:32:25
I don't want to interrupt the flow - but regarding Margie's comments on A - can we confirm whether or not Thomas' Rickert;s point of order raised a that F2F regarding the inclusion of Reverse Lookup in scope, has been formally dealt with - apologies - i have not had a chance to fully review the last number of meetings whilst on leave?
Mark Svancarek (BC) (marksv)
02:32:46
Thomas concern was not addressed last meeting
Ashley Heineman (GAC)
02:32:48
Well, can't you take action against potentially? Or the entity responsible for access/disclosure?
Alan Woods (RySG)
02:32:59
Thank you
Brian King (IPC)
02:33:21
f) is acceptable
Marika Konings
02:33:34
Staff will fix the numbering :-)
Amr Elsadr (NCSG)
02:33:45
I also spoke to the scoping issue a couple of calls ago, especially what is appropriate to include within scope of this EPDP. Would be happy to take that to the mailing list, if helpful.
Volker Greimann (RrSG)
02:36:17
Agree to this proposal
Amr Elsadr (NCSG)
02:38:50
@Janis: Apart from it not being in the charter, reverse lookups have never been the result of a GNSO PDP, so is inappropriate for any EPDP to address.
Alan Woods (RySG)
02:40:06
+1 amr
Marika Konings
02:40:08
@Amr - the overall of the topic needs to have been scoped previously, not necessarily every topic that may come up in a PDP. For example, accreditation was neither subject of a previous PDP, as far as I recall.
Margie Milam (BC)
02:42:26
most of the WHOIS issue is contract based and did not originate from gnso consensus policy
Amr Elsadr (NCSG)
02:43:02
@Marika: Accreditation is a tool/solution we’re recommending to solve the disclosure issue, which we are scoped to deal with. Not the same thing.
Amr Elsadr (NCSG)
02:43:43
@Margie: Correct, which is why these issues need to be dealt with in whatever replaces the terminated Next-Gen RDS PDP, not here.
Amr Elsadr (NCSG)
02:44:01
There’s a ton of RDDS issues we’re not looking in to. Not just the issue of reverse lookup.
Marika Konings
02:44:20
The charter is also clear that the EPDP Team is expected to address rules / policies, without limiting what those rules could or shouldn’t include.
Matt Serlin (RrSG)
02:44:24
I think Volker’s idea making it optional for registrar or registry operators to implement if they would like is fine
Volker Greimann (RrSG)
02:44:32
agreed, but rev lookup is dear to many
Matt Serlin (RrSG)
02:44:37
But how that would play into the SSAD itself would need to be worked out for sure
Volker Greimann (RrSG)
02:44:59
If we can agree on a solution quickly, we all win
Hadia Elminiawi (ALAC)
02:45:05
thank you all bye for now
Chris Lewis-Evans (GAC)
02:45:10
Thanks all bye
Amr Elsadr (NCSG)
02:45:11
Thanks all. Bye.