This is the document that we will look at next - it was also attached to the email that went out yesterday with the agenda.

test

+1 Thomas

The CPH would further like to reiterate our understanding of the advice we have received from Bird and Bird on automation. Relevant to the SSAD, most decisions short of the ultimate decision whether or not to disclose data can be fully automated, but that most decisions involving disclosing registrant data of a natural person will require meaningful human review. To be clear, this shouldn’t foreclose the possibility of a model that evolves towards further automation of disclosure decisions, or individual controllers automating their own decision-making processes based on their assessment of the risks.

FWIW to Stephanie's point this already says "legally permissible" - should capture that

as long as people do not take a narrow reading of that.

Possibly if Marc would care to spitball a percentage that is likely legally permissible to automate, it might help.

+1 Alan G!!!

@Marc sure but "legally permissible" should cover your above statement

Correct Hadia.

i have my hand up

same

Can we go by the queue again please?

I still have an important point to make. Shall I type it in the chat?

I agree with James that we should be focusing right now on the cases which are clearly lawful. The principles allow for us to expand that list as more guidance and experience is received

WE are about to release a document for public comment. We need to be clear and explicit regarding what we mean by “automation”, because it is a hot button word, and is explicitly dealt with under data protection law. Human oversight is often demanded…we need to explain how that will be achieved somewhere.

I do not believe that the “grand public” understands what we mean by automating the accreditation and authorization functions.

For avoidance of doubt: It is in our (CPs) best interest to automate as much as possible, so long as we are on firm legal ground. This will scale better and save operational costs.

So we need diagrams and explicit understand of which procedures will be automated and how, and who is accountable i.e. the controller of that procedure.

+1 James

I am concerned that we may unleash a dog’s breakfast of comments if we are not crystal clear…..recent experience with the .org sale has not been…..reassuring

link to automation building block

https://docs.google.com/document/d/1KCzlakWVkt6GN5ZPl0my45WdR34JPes_bZwmJkY9Z3k/edit

link to wiki where initial report: https://community.icann.org/display/EOTSFGRD/f.+-+Draft+Initial+Report

Thx Marc

This is the proposal that was shared last week and which includes the latest version of all the recommendations.

we’ve discussed LEA rquiests with jurisdiction matching.

There are two possible examples. LEA requests within same jurisidiction (ex. German LEA to German Rr). UDRP requests from providers.

Is it possible to print the draft report please?

+1 Laureen

Some of us are not doing this as part of our day job. This makes it hard to keep up with the review, and hard to justify carrying our paper files to support us while here. I guarantee it will help

@AlanW, sorry I was trying to avoid discussing implementation. Sorry I seemed dodgy. Easy examples would be anything under .BANK, or anything containing the string "exxon"

("exxon is a string that isn't a word and appears in TMCH)

phishing is another example

+1 Stephanie

We have some good ideas to explore for those no-brainer, can-always-be-automated cases, when we get there.

Let’s remember the central gateway will not hold any of the actual data

+100000 Matt

+1 Matt the data would ultimately come from the CPs data

Right but I also say that to illustrate it’s difficult for the central gateway to make decisions without having access to the data

@Matt, right. And let's consider that the central gateway could get the data (but not disclose it) for its own purposes of evaluating whether to automate. Automation could be a subsequent step. If the central gateway is operated by ICANN (or its designee) as a joint controller, there is no problem for the CP to send the data to its joint controller for the controller's own purpose.

I've also heard though, while SSAD does not have the data, some Registrars may choose to automate disclosure requests, even if 6.1.f due to scales or lack of resources.

<<< should say smaller Registrars.

Creating copies of data records has its own risks. And who ensures that the SSAD’s data is synchronized if the Registrant/Data Subject makes any updates? Opens up lots of questions

The TSG model and I think I recall Org saying they don't want to store data at the SSAD.

that's my recollection too, Berry. I don't think anybody wants ICANN or SSAD to have a shadow database

+1 stephanie

"evolutionary model"?

...can we just not call it … The model … can we commit already

For the record: I’m still favoring Iguana

Here’s a very easy fix - Delete “...from a hybrid to a (partly) centralized)...”

While it doesn't work purely given two sides of demand vs. supply side, the model is really a hub and spoke of sorts.

+1 James on deletion

I think "EXPECTED evolving nature" anticipates an outcome but does not mandate it

Reminder to lower hand in zoom when finished with question/comments.

The principles need to be seen as a package - so evolution would only happen if the other conditions are met (technically feasible and legally permissible).

To the point James earlier, we also think we need to add commercially reasonable as well to those two existing caveats

I had suggested earlier that the trademark-infringement related disclosure requests could be automated.

+1 Thomas. I will submit that to the email list shortly.

@Thomas: How?

Note, Standardization is within the Automation building block.

prelim rec. 13 (from automation BB) currently reads: The EPDP Team acknowledges that full automation of the SSAD may not be possible, but recommends that the SSAD [should, must or may] be automated where technically feasible and legally permissible. Additionally, in areas where automation is not both technically feasible and legally permissible, the EPDP Team recommends standardization as the baseline objective.

All great suggestions Volker

+1 Volker

Maybe add statistics:

95% of CPs in your jurisdiction have approved this king of request/ requests by this requester...

king=kind

+1 Volker adding statistics help the system to learn

Speak now or be forever quiet! ;-)

+1 Volker again

Right now the principles allow a CP what to automate, who they implicitly trust, and whether to contract a joint controller or a processor. I think all these good ideas are compatible with the principles already ...?

Are all joint controllers (ICANN, Rys and Rrs) comfortable with the way responsibilities are now split?