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

Hello all

Thank you Keith, apprciate your time here

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

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

we had that conversation again and again and again

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

+1 Sarah

Phase 1 only addressed with redaction

Also +1 @Sarah.

The rec does not discus redaction?

"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."

We haven’t addressed it in the context of SSAD

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

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

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

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

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

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

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

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

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

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.

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

We’ve never had consensus on legal vs natural.

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??

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

+1 Thomas

Also +1 @Thomas.

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

@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

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

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

@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

hadn raised

hand raised

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?

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

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

+1 Alan and Volker

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

Anybody have a link to this doc handy?

Agree with concerns expressed. This is a very heavy lift during already demanding times.

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

Thanks, Berry.

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

hand raised

Taking donations for a t-shirt "The Crank" ;-)

you are not cranky at all though, berry

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…

Yes, we'll send out with meeting notes.

which document is currently on the screen?

I am not worried about staff, I am worrying about the comments

Thanks Berry!

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

Round of applause for the hard work of staff!

Indeed. @Stephanie @Janis: +1

In deed Stephanie! Our staff team rocks!

Virtual clapping for our great staff.

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

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

+1 Alan G

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

Yes please….

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

Well said Volker, thank you

Indeed, well said Volker

+1 Alan W

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

+1 Alan

Brian it looks like it's about creating multiple MUST's as a general concept ...

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

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

just because we can does not mean we should

@Amr two cases

and we are still going to look into the others

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.

@Stephanie: +1

+1 Stephanie

What I’M confused about is the centralized system we began with?! What centralized system?

@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.

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

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

@Amr the two cases are on the screen with green dots

@Sarah: +1

Thanks, Hadia.

three cases

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?

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

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

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.

+1 Stephanie

There are mechanisms to deal wth these situations folks….called DPIAs. Or PIAs.

Too bad we never did them.

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

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

+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.

@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

@Stephanie: +1

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

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

Bird & Bird gave us a couple City field examples that can safely be automated.

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

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

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

+1000 Thomas

+1 Thomas

+1 Thomas and Volker

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

Can we take a minute to discuss in our groups before we agree?

Just replace “MUST” with “Should”.

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

Not sure I understood

yes Janis, in progress now

thank you

I'm unclear what we're discussing, soryr

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?

we're discussing the text on screen at the top of the rec

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

Silence until we resume in 3 minutes

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

One minute until we resume

Time is up

I’ve got to drop…good luck the next 30 minutes…

Thanks Matt

I like this idea

NO best practice language

Not acceptable at all

Not acceptable from IPC

I’m happy with the suggestion from Thomas too.

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

I can live with Thomas suggestion

I think Thomas’ solution works

We need enforceable language

@Laureen, even weaker than "should"

You can ask compliance to investigate failure to comply with best practice

Compliance will not

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

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

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

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

It seems like we cannot reach agreement on „must“

When will someone answer my question, who takes the risk with MUST?

@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

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

SSAD decisions MAY not be automated decision.

To be clear, this only covers disclosure decisions that ARE legally permissible.

Alan Are you reading the same recommendation? This is about automation.

Leaving it up to who to determine that?

People are still incapable of identifying personal information in a simple test.

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

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

Margie, your statement is simply not correct.

But you get that’s not what this MUST is relating to.

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

@alan G correct human intervention is also an option

We can put all sorts of recommendations in our policy - from binding to optional

@Thomas - point to the charter where it says we are developing best practices

Not every word we have in our report will be found in our charter.

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.

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

+1 Margie, open to finding compromise

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

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

Thanks Caitlin

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

@Berry - thanks

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

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.

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

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

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.

What Janis said. :-)

Thanks, Amr and Janis for raising my IQ on that.

shouldn't it be where the data does not contain personal data?

Thank you, staff!

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

presumably staff will address that

Yeah. I was wondering if I was reading that double negative incorrectly!!

i don't think you weren't, amr :)

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

@Brian thanks for confirming

Thanks, Brian. :-)

I don't think we didn't get that wrong

Hahahaha!!

Ok with the proposed edit

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

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.

Yes only certain aspects of those requests can be “automated”

Right. This is a good point from B&B.

+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.

Exactly, Alan W.

Thanks, all.

Thank you - bye

thanks all

Thanks all. Bye.