
32:06
Please review ICANN Expected Standards of Behavior here: https://www.icann.org/resources/pages/expected-standards-2016-06-28-en.

35:26
Hello all

40:19
Thank you Keith, apprciate your time here

41:04
Thank you, Keith (apologies I had my chat on panelists only)

44:42
I'm satisifed with the Phase 1 Rec on legal vs natural, I think it gives us enough to complete the issue.

44:51
we had that conversation again and again and again

44:52
We’ve been discussing legal vs natural since Phase 1!!

45:01
+1 Sarah

45:17
Phase 1 only addressed with redaction

45:17
Also +1 @Sarah.

45:49
The rec does not discus redaction?

45:53
"The EPDP Team recommends that Registrars and Registry Operators are permitted to differentiate between registrations of legal and natural persons, but are not obligated to do so."

46:26
We haven’t addressed it in the context of SSAD

46:30
@Margie: Phase 1 rec on legal vs natural addressed how legal vs natural is handled. Wasn’t specific to redaction only.

47:00
And how automated disclosures could happen as recommended by the legal advice

47:03
I understood Phase 1 to be how legal vs. natural was handled in the context of publication, as opposed to disclosure.

47:07
@Amr, that is not the case. We ONLY addressed redaction in Phase 1.

47:37
Phase 1 was much broader than only redaction, I'm sorry, it dealt with what data are collected, transferred to Ry, escrowed, and more

47:41
This chat alone shows that the issue is more nuanced and requires thoughtful discussion.

47:57
We addressed redaction + ICANN purposes. The wording of the recommendation was in no way restricted to redaction alone.

48:36
disclosure/access is addressed in phase 2 and was not addressed in phase 1

49:28
The recommendation was on how CPs would be permitted to handle legal vs natural.

49:41
resending to all: Hi Keith, thanks for your proposal and explanations. Can you please highlight the benefits of the suggested approach (again). I guess I am not clear as to why this is the best option.

51:06
@AlanG: The Council shouldn’t deliberate on substantive issues. Only on what this Team reaches consensus on, right?

51:22
We’ve never had consensus on legal vs natural.

53:36
I’m sorry but I don’t understand how you can say the IPC and BC aren’t represented on council…did I hear that correctly??

54:12
I think we need to create two buckets of open issues: The ones we have divergence on we should not pursue (there is no point in prolonging this exercise until some parties get their will) and the second bucket of issues that just need ore time. I am not sure whether those are actually for phase 3 or just regular PDPs

54:51
+1 Thomas

55:12
Also +1 @Thomas.

56:32
Note that significant parts of the GNSO Council have said that the results of L/N and Accuracy *ARE* policy.

56:52
@Thomas, not sure I can support that broadly - I've heard that some issues have no hope for consensus, but which we have not even discussed legal advice received

56:56
Thanks all. I will now drop off the call. Rafik will provide an update after the Council's 21 May meeting.

57:31
@Thomas, thank you for the suggestion. It will be good to characterize our remaining action items.

58:38
@Brian - you are right we have not reviewed every advice we got and we should do that (preferably during the remaining time of this phase). I was talking more boardlly about the next steps beyond the end of phase 2

59:05
hadn raised

59:09
hand raised

01:02:23
Some of us do not have time to meet every day. Life goes on, you know. How can we, in a meaningful way, deal with the “cannot live with items” in this fashion, when there remains fundamental disagreement on issues that some of us sincerely believe have been settled?

01:03:22
Not succinct, but a quick summary of the answers. I invite all to review the recording for precision of those answers. ;-)

01:05:45
@Janis: Not easy to plan around daily EPDP calls for a week. So @AlanG: +1

01:05:51
+1 Alan and Volker

01:07:01
Anyone over the age of 60 would be daft to agree to meeting day and night under the current COVID circumstances.

01:08:42
Anybody have a link to this doc handy?

01:09:14
Agree with concerns expressed. This is a very heavy lift during already demanding times.

01:10:22
https://community.icann.org/display/EOTSFGRD/g.+Draft+Final+Report+-+Phase+2

01:11:05
Thanks, Berry.

01:11:22
https://community.icann.org/pages/viewpage.action?pageId=126430750

01:11:29
hand raised

01:17:04
Taking donations for a t-shirt "The Crank" ;-)

01:17:15
you are not cranky at all though, berry

01:17:55
Please can you send that explanation with the links to the List Berry? Easier for our members to find there than in disinterring the chat from our calls…

01:18:40
Yes, we'll send out with meeting notes.

01:19:36
which document is currently on the screen?

01:20:24
I am not worried about staff, I am worrying about the comments

01:20:32
Thanks Berry!

01:21:19
https://docs.google.com/document/d/1dsaa_gO78F3hmVZ2P6_yjt716Z9nMyegl3Qj7za0N_o/edit#heading=h.gjdgxs

01:21:20
Round of applause for the hard work of staff!

01:21:36
Indeed. @Stephanie @Janis: +1

01:21:56
In deed Stephanie! Our staff team rocks!

01:22:22
Virtual clapping for our great staff.

01:25:50
To be fair, I'm unclear as to which "must" we're talking about changing to a "should"

01:26:12
I'm with Brian, can we confirm which line of the doc we're talking about?

01:26:13
+1 Alan G

01:26:32
@Brian: +1. If staff could clarify this, we might be able to answer.

01:26:53
Yes please….

01:27:00
Either way, I think it needs to be at the CP's opt-in for any automation category. There's a risk they need to be willing to assume

01:27:39
Well said Volker, thank you

01:28:17
Indeed, well said Volker

01:28:27
+1 Alan W

01:28:39
Can someone answer the question of which "must" we're talking about? Can't respond otherwise...

01:28:39
+1 Alan

01:29:00
Brian it looks like it's about creating multiple MUST's as a general concept ...

01:29:15
Sorry folks — I need to drop off early this week. Ben will cover for SSAC. Thanks!

01:29:45
I will repeat my earlier comments that we need to be talking about DECISIONS at the SSAD, *NOT* Automation!

01:34:43
just because we can does not mean we should

01:34:54
@Amr two cases

01:35:31
and we are still going to look into the others

01:36:42
One was where DPAs are requesting personal information in response to a violation to DP law. I honestly don’t recall the other. Apologies for that.

01:37:20
@Stephanie: +1

01:37:34
+1 Stephanie

01:38:52
What I’M confused about is the centralized system we began with?! What centralized system?

01:40:23
@Amr, we agreed to take a "leap of faith" at Ashley Heineman's suggestion and work together toward a centralized model. We were working on that for quite some time before we pivoted in January.

01:40:45
@MarkSV: I forgot about that one. That’s the second one I missed, I guess.

01:41:22
I'm close to OK with that use case (no p.d.), it's just hard to track the "knowing" that there's none.

01:41:42
@Amr the two cases are on the screen with green dots

01:41:42
@Sarah: +1

01:41:50
Thanks, Hadia.

01:42:10
three cases

01:42:24
Release of non-personal data, and release to compliance in their pursuit of compliance action should be MUSTS. If we cannot agree on those, why are we even bothering?

01:42:24
Sarah, this is why we need to do proper risk assessments of the “use cases”/

01:43:19
City field automated disclosure is difficult; the risk is often (even usually) negligible but it is possible to identify a specific person based on city, and as such before it can be disclosed a person has to review and see if it's personal data or not -- so there has to be some meaningful human review only to determine if it can be further processed automagically

01:43:31
Given the prevalent lack of understanding of what personal data is, that is a risk I would put right up there as as a priority.

01:43:42
+1 Stephanie

01:43:51
There are mechanisms to deal wth these situations folks….called DPIAs. Or PIAs.

01:44:01
Too bad we never did them.

01:45:13
I used to love giving quizzes to staff. They fail the tests, suddenly their bosses who are accountable become more interested…

01:47:12
It seems really unlikely that we'd get legal guidance that says disclosure is okay in al lcases?

01:48:24
+1 Sarah, and I'm aware that we might be more optimistic than others that we get legal guidance that _more_ (not all) use cases may be automated, but our lawyers do think so.

01:49:26
@Sarah for sure disclosure is NOT okay in all cases @ Amr in green as well is the City-field - to evaluate whether to pursue a claim and for statistical purposes

01:49:32
@Stephanie: +1

01:50:38
Hadia did you see my comment above re why city field cannot always be handled automatically?

01:51:39
We have been over city field so many times…..check back on the discussions during the PPSAI discussions.

01:52:30
Bird & Bird gave us a couple City field examples that can safely be automated.

01:52:49
@Sarah and Stephanie I am just referring to the legal advice that we got and the document that was on the screen.

01:53:12
Well he issue is noone is yet clear about who is going to accept resonsibility, we have to play that same old record over and over again

01:53:13
Can you set up a system to handle the risks that some contracted parties will not release ALL city fields?

01:53:28
+1000 Thomas

01:53:34
+1 Thomas

01:53:48
+1 Thomas and Volker

01:53:57
In my view, we need to start operationalizing with limited scope, build trust and broaden the remit over time.

01:54:34
Can we take a minute to discuss in our groups before we agree?

01:54:58
Just replace “MUST” with “Should”.

01:55:04
Volker, did you just say that you unilaterally refuse to give ICANN Compliance data which you are contractually obligated to give them?

01:55:11
Not sure I understood

01:55:22
yes Janis, in progress now

01:55:22
thank you

01:55:32
I'm unclear what we're discussing, soryr

01:55:34
markSV - I don't think ICANN contracts can require us to provide data if the law doesn't allow it. If they can get what they need without the PD why would it be provided?

01:55:44
we're discussing the text on screen at the top of the rec

01:55:51
85 minutes into this call....This is not a good use of our (collective) time.

01:55:52
Silence until we resume in 3 minutes

01:57:08
Sarah, I could not tell if Volker was requesting an exemption or was simply refusing to follow the contract

01:57:37
One minute until we resume

01:58:40
Time is up

02:00:23
I’ve got to drop…good luck the next 30 minutes…

02:00:31
Thanks Matt

02:01:00
I like this idea

02:01:09
NO best practice language

02:01:14
Not acceptable at all

02:01:18
Not acceptable from IPC

02:01:19
I’m happy with the suggestion from Thomas too.

02:01:21
The concern I have with "best practices" is that they are not enforceable. Isn't this really the same thing as "should"?

02:01:27
I can live with Thomas suggestion

02:01:28
I think Thomas’ solution works

02:01:29
We need enforceable language

02:01:54
@Laureen, even weaker than "should"

02:01:54
You can ask compliance to investigate failure to comply with best practice

02:02:06
Compliance will not

02:02:07
We can ask compliance to come over and paint my house too

02:02:32
I do not agree, Janis! It does not dilute. It sets the default to „disclosure“

02:02:43
I was going to answer Stephanie, but Brian's response is better!

02:02:49
@Thomas for different reasons best practices are not always followed and certainly can not be enforced.

02:02:55
It seems like we cannot reach agreement on „must“

02:03:08
When will someone answer my question, who takes the risk with MUST?

02:03:43
@Hadia - but then the CP needs to explain very well why it does not follow the best practice. If it fails to do so, there can and should be a route for ICANN compliance to step in

02:03:57
If it is this committee, as an organ of ICANN which carries no insurance for indemnifying volunteers, forget it. I cannot agree with MUST.

02:04:07
SSAD decisions MAY not be automated decision.

02:04:21
To be clear, this only covers disclosure decisions that ARE legally permissible.

02:04:33
Alan Are you reading the same recommendation? This is about automation.

02:05:00
Leaving it up to who to determine that?

02:05:24
People are still incapable of identifying personal information in a simple test.

02:05:30
@Alan W, and I have repeatedly said that human-assisted SSAD decision must be considered and we are ignoring that option.

02:05:35
@Brian: Yes, but like Stephanie said earlier, what works in theory could be trickier in practice.

02:05:48
Margie, your statement is simply not correct.

02:05:49
But you get that’s not what this MUST is relating to.

02:06:11
@Margie: So we’re only allowed to come up with recommendations that include MUST or MUST NOT?

02:06:16
@alan G correct human intervention is also an option

02:06:21
We can put all sorts of recommendations in our policy - from binding to optional

02:06:23
@Thomas - point to the charter where it says we are developing best practices

02:06:51
Not every word we have in our report will be found in our charter.

02:07:46
I am trying to help find a compromise. Best practice with an escalation path for compliance to step in if automation is not done without good reason.

02:09:24
I appreciate trying to find a compromise - but in my view best practices won’t work; finding a way to articulate the CP concern is the way to find compromise ie guidance to complaince

02:09:44
+1 Margie, open to finding compromise

02:11:21
does someone have the link to the left hand document? The one with the list of items for discussion.

02:13:01
It would be useful to explain what the GDPR means by automated decision making. That ought to be in the policy we come out with

02:14:33
Thanks Caitlin

02:14:49
@Marc, just sent document to list. We didn't get this posted on the wiki yet.

02:15:47
@Berry - thanks

02:16:52
Were we to do a PIA on this thing, of course, we would have the decisions mapped to the data flow and we could discuss each decision point…..and who is accountable and how that accountability is detailed in our policy

02:17:50
I like the point in the doc about whether there should be an SSAD if it's not commercially feasible. With that $9million price tag, maybe we should be thinking abou tit.

02:18:30
@Sarah: +1000. Now that we’ve seen the estimates, do we actually believe this will be financially sustainable?

02:20:28
@Brian: Every PDP is required to consider financial feasibility.

02:20:49
We do not yet have the data from the contracted parties regarding their costs. Since all money comes from the RNSs, then as reps of those non-commercial RNHS, we actually care a lot about getting a full picture of what the real costs are. Don’t forget legal liability costs.

02:20:50
What Janis said. :-)

02:22:31
Thanks, Amr and Janis for raising my IQ on that.

02:24:57
shouldn't it be where the data does not contain personal data?

02:24:57
Thank you, staff!

02:25:08
like, the way it's written is that we automate personal data, I think there's a double negative

02:25:12
presumably staff will address that

02:25:26
Yeah. I was wondering if I was reading that double negative incorrectly!!

02:25:33
i don't think you weren't, amr :)

02:25:33
ha, yep Sarah. Thanks the typo catch. Tried to race through our homework :-)

02:25:43
@Brian thanks for confirming

02:25:44
Thanks, Brian. :-)

02:25:51
I don't think we didn't get that wrong

02:25:57
Hahahaha!!

02:26:31
Ok with the proposed edit

02:27:43
Slip of tongue by Laureen: It would be 6 I c (not e) GDPR

02:27:48
Automation of that use case should still be opt-in. Local-jurisdiction LEA does not always limit their requests appropriately, unfortunately. Not all CPs are okay with automating that.

02:29:04
Yes only certain aspects of those requests can be “automated”

02:29:30
Right. This is a good point from B&B.

02:29:50
+1 Sarah - in the perfect world where LEA requests were always perfect we would gladly agree - but alas we have not attained that level just yet.

02:30:12
Exactly, Alan W.

02:30:22
Thanks, all.

02:30:55
Thank you - bye

02:30:59
thanks all

02:31:06
Thanks all. Bye.