I am in another meeting so I will try to follow as much as I can.

Hello all

Hi all.

Good morning from DC

I’m here

BRB - my audio is not working

Good morning from Iowa, Becky. It is 5 degrees here. :)

It’s 55 F here James, but your weather is heading east tonight ...

14° C and sunny here

or as some call it: "winter"

+10C/50F here

Since we’re sharing weather updates, 18C in the suburbs west of Giza, and sunny, but warmer today than it has been over the past week, or so. :)

-9 C and heading for 20 below cold snap after 10 inches of snow, so y’all just keep quite ok?

quiet, that was….

I seem to have lost audio. Just me?

Audio back now.

ok here

Must be on my end. Thanks, Alan.

@Stephanie: Happy to trade some sand for snow.

Having connectivity issues. Will try to fix them, then rejoin the call.

+1 Volker

Key words in Volker’s contribution: legal clarity.

To those groups I would like to say: Is having no change over the status quo really preferrable over the hybrid model?

as the hybrid model has a centralized part to it, it makes adapting it to be more permissive later on easier

We can talk about how important our consensus position is, but we need to focus on legal certainty. Hybrid model is the only possibility.

@Stephanie: +1

status qou is the fully decentralized model, btw

Also just to be clear, the hybrid model we have proposed provides for many improvements over what exists today

quo

We could be think about a hybrid model based on the centralized model

If all requests flow through a central gateway, it allows for full tracking of those requests and assurances that the correct CP must respond, provide information, etc

do we want to wait another year then? or do we build the hybrid model and then incorporate the new learnings down the road?

we could consider a hybrid model based on the centralized model

+1 james

+1 James

@Matt: +1, which is one of the best features of the centralized model, which also makes the hybrid model appealing.

And to be clear, if we got off this call today and all agreed on the hybrid model, we would still be crunched for time to get our work done in the allotted time

Lets not build the egg-laying woolmilkpig right away. let's first get something that lays eggs and breed it for additional features later

I wish we could stop talking about at 100% centralized model. I don't see how we could ever get there as there will always be cases where CP have access to data needed to make a fair decision. To force 100% centralized, we are virtually guaranteeing rejection of requests that might be valid.

+1 Laureen

We could start with a policy that allows for a mature system that is centralized but currently working mostly in a hybrid way with regard to the decision making

@Laureen, that is exactly what some of us are proposing. Identify specific classes of requests that may be "simple" but high volume, that we could automate immediately.

+1 Laureen. LEA requests can be automated today, if we can do some jurisdiction matching/vetting (part of accreditation?).

+ 1 Ben … I agree I think that it is a great approach, and the most sensible TBH

I have an ongoing power outage so I may disappear as one device loses battery power and I switch to another one.

+1 Brian - for sure…lots of work to be done but boy I think our work could be successful if we agreed on a model and dug in, rolled up our sleeves and did it in the coming months rather than go round and round on the model

@Alan, noted

@Matt, I almost agree with you. We cannot "agree on a model" until we know that it can meet our needs. We are happy to agree to get to work on policy development around a model, but we cannot write a blank check. I hope that makes sense.

Hybrid model has structural elements (centralized gateway and logging, RDAP relay, etc). But it also has Operational elements such as maximum response time for disclosure or denial, and a Service Level Agreement such as 95% of responses to accredited requests within x hours.

A deadline for noon tomorrow gives us less than 48 hrs to review and discuss the draft questions.

we all need to commit to work on the basis of their advice.

bravo, Alan W

Lots of useful tools went away with changes in the law.

lots of 'useful' tool existed at the time despite the law too.....

understood James.

But my understanding of the situation with the PDP was as described by Janis

What we're asking is how the law applies to this

@Brian - ok, that’s fair. But why? For a future PDP?

Tools may have gone away with changes of law even though the law did not definitively require them to go away.

I think you are not quite seeing Amr's point Brian. The point is that we should not expend our time and indeed funds on a matter that is not in scope.

Examples Mark?

Access to the contact info of legal persons, for example

Well said, Amr

Mark, access to contact info of legal persons is not a distinct tool, as far as I can tell. It’s a policy decision regarding what data is redacted and what is not

We have language in the draft initial report that would make it consensus policy to prohibit reverse lookups. If it's within our remit to prohibit it, wouldn't it be within our remit to allow it, if legally permissible?

The views I referred to were expressed in EPDP plenary calls, not on the legal committee (or if they were on the legal committee, I don’t know about it).

This particular question was actually approved by the Legal Committee before I replaced Leon, so I am unable to speak in detail regarding the discussion in the committee. What I can say is that all parts of the community have been represented in the Committee discussions, we have had good participation and vigorous debate.

That said, if reverse lookup has been rejected as a policy matter by the plenary, moving forward doesn’t make a lot of sense

@Becky: My take on reverse lookup isn’t so much a policy one, but a procedural one. EPDPs (as opposed to PDPs) have very narrow remits, in which reverse lookup doesn’t fit.

@Hadia: I just said that not all our concerns are legal. Our = NCSG. I understand that you don’t share those concerns, but we do.

If I am understanding this discussion, we need to reach agreement about whether this is in or out of scope.

Thanks, Becky.

@Amr the concerns in relation to Natural vs legal are legal by nature. If you regard the law (GDPR) wrong about having legal persons data not protected under GDPR - we can't do anything in this regard

I will stop my share momentarly to prep for next agenda item.

@Janis: Wether it’s compliant or not, wether it’s desirable or not…, makes no difference. It’s out-of-scope.

There were two objections: Legality and Scope. Bird & Bird may be asked on the legality, but that’s irrelevant for the scope of this PDP. So the future PDP should pay for their own advice.

@James: +1

You might be surprised, but we'd be just as happy to call this out of scope - however, this means that reverse lookups cannot be prohibited either, and that draft language must be changed.

I don't think it's de facto out of scope, but we'd be happy to focus elsewhere and be silent on reverse lookups

@Brian: I’m perfectly happy with no mention of reverse lookups, one way or the other, in our report.

yes, we will do that if people respond by email with objections. Please be as specific as possible

@Brian - I am looking over the initial report, and don’t see it. Can you show me where it is prohibited?

but otherwise fine that we don’t mention it at all

Query policy I believe

I'll find it

ok, I’ll look there

Preliminary Rec 9, query policy

Yeah I do recall that…so maybe that’s the best option is just for us to be silent on it

Probably one of those days when I was skipping school....

we nees to finish at least some important ones and include them

need

Agree that the highlighted text on the screen is accurately representative of what their purpose within our deliberations were.

absent details on how decisions are being made in certain cases, the EDPB will not be able to assess GDPR compliance. period

I think dropping things in the interests of going forwards merely prolongs the agony

if we drop work on use cases, we need to lower our expectations

and plus 1000 Thomas.

@Alan W and Alan G: +1

they are not ready for prime time, though.

Yes, discussing use cases did exactly what we wanted, which was clarify issues in the request and disclosure process. We are now done with it

Thomas: “absent details on how decisions are being made in certain cases, the EDPB will not be able to assess GDPR compliance. period” I couldn’t agree more.

the EDPB will look to the application of GDPR on a case by case basis. I'd rather the decision maker being able to show their own consideration and not merely point and shrug at a use case. Completely agree with Thomas they are not fit for purpose and I have no problem with the reference that they helped us on the path, but we need to be very very clear and explicit that they are illustrative not binding.

(sorry putting word in Thomas' mouth - that they need work )

"illustrative and not binding" is an appropriate representation IMO

"they"

Exactly, Mark SV. Requestors will approach registrars and registries directly with data requests and we cannot prevent that. Recc 18 from Phase 1 is supposed to implement methods for responding.

Who in SSAD will be accountable for reviewing the procedures and practices of LEAs, and determining whether they are consistent with the EU Charter/UDHR?

I believe that ICANN has pumped a lot of money into the Internet and Jurisdiction project and they still don’t have an answer to that question, but I stand ready to be corrected by those in the know....

...but you accepted it. Let's ot walk back reached agreements!

I hope the GAC responds directly to Stephanie’s question, but I don’t see how our SSAD can claim it has authority to review internal processes at a law enforcement agency.

I agree Steve. National sovereignty still exists. TBDF will remain a difficult problem for the foreseeable future.

As it has for the past 60 years….

i need to drop. bye all!

check

Janis — not everyone seeking RDS data will even know the SSAD exists, and we will have LEA, reporters, and others who phone a registrar, send a letter, knock on the door, etc. So we absolutely need a Recc 18 implementation to give CPH a policy they can follow

+1 Steve

Hi folks. I’m losing my workspace here at the hotel, so will need to drop. Apologies.

Thanks, Marc A. - we can do that.

Link to goog doc.

The whole thing hinges on who is the controller, and how much the policy constrains their actions. That is a legal question worth asking

https://docs.google.com/document/d/1rV0Iwo6HCABfP8oaxPC_u_D-vvjud15b/edit

+1 Marc

Hopefully we don't need this permanently, but I think we do need it now

Cool

Smaller, plz

jk

+1 Marc

Agree with Marc, and agree with MarkSV that how logging will be conducted is something we should consider in our determination.

+1 Georgios

@Georgios: +1 here too.

+1 Georgios in country A requestor + country A CP gets more difficult if the authorization provider is in country B

Lots of background noise

someone tuning a guitar

@Alan but if they log based from the information then they are processing it...

I am happy to think about it

I’m not clear on why data passing through multiple jurisdictions does not constitute processing, but happy to table this for now.

but would like help from Giorgios ;-)

I can also join

thx

@Chris, I'm not sure that the logging involves any personal data.

(other than that of the requestor)

yes

internet routers log all sorts of data as well...

logging is processing. I think that is pretty well acknowledged, do we need to cite the guidance?

I think we need to distinguish between the entity performing the function, and the entity holding responsibility in the centralized model (the latter being ICANN).

@Alan G: +1

AlanG just made my intervention... I think Janis was accidentally saying "accreditation authority" rather than "authorization authority"

@Janis: This comment is specifically addressing the possibility that we recommend a centralized model in deciding responses to disclosure requests.

+1 Alan G, Mark

thanks all

thanks all

bye

Thanks all!

Thanks all. Bye.

thanks bye