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

Link to Goog Doc of Cat1: https://docs.google.com/document/d/16BICriVfOPiEeve4A-x6TYKPbgRKqvhX/edit

digesting

digesting, and discussing who among our group will speak

Proposed language would be: “• 9.4 Per the legal guidance obtained (see here), the EPDP Team recommends that the following types of disclosure requests, for which legal permissibility has been indicated under GDPR for full automation (in-take as well as processing of disclosure decision), MUST be automated from the start:””

• Possible footnote that would state: “The EPDP team notes that the advice received was based on several specific underlying assumptions and any derogation from such conditions may affects the validity of the advice received”.

+1 Marc

Nobody said we would not rely on to. What we are saying is that the policy cannot state categorically what is liege or not.

In other words, as we have pointed out before, MUST automate is not a directive that I support. I have not had a minute to caucus with colleagues on this matter.

Under current ICANN contracts, it is indeed left to each contracted party to determine what is legal for that contracted party. ICANN policy cannot overrule that.

ugh - trying again without typos … Nobody said we would not rely on it. What we are saying is that the policy cannot state categorically what is legal or not.

+1 Alan

+1 Alan

The proposed language says: “for which legal permissibility has been indicated under GDPR for full automation”.

I again worry that we are creating policy that is specifically tied to GDPR with references like that

As a reminder, there is also 9.5 under which a CP can notify of an exemption.

What if a contracted party is in a jurisdiction that has privacy laws that specifically prohibit the automation of data disclosure?

+1 Marc

@Matt - in that case, a CP will invoke 9.5.

+1 Marc

I’m sorry. I’m not sure how referring to art 44-49 equates to compliance with art 44-49?

Proposed language would be: “• 9.4 Per the legal guidance obtained (see here), the EPDP Team recommends that the following types of disclosure requests, for which legal permissibility has been indicated under GDPR for full automation (in-take as well as processing of disclosure decision), MUST be automated from the start:””
• Possible footnote that would state: “The EPDP team notes that the advice received was based on several specific underlying assumptions and any derogation from such conditions may affects the validity of the advice received”.

Yes Hadia therefore you agrees with us. Absolute statement of legal permissibility should not be in the recommendation.

Well said Alan

Everything is possible. Extent of associated risk of liability is the issue, and as far as I can tell, that’s what the RySG is trying to have reflected in the final report.

I am very curious as to how anyone sees this “MUST” requirement being implemented. If a contracted party fails to automate, what happens next, who investigates, and who pays for that investigation?

Investigations cost money.

What is involved here is external parties second guessing controllers, particularly risky when we are talking about different jurisdictions.

old hand from me

@Alan W reference to the possible legality as determined by Bird &Bird is important also we need to remember that based on this Bird & Bird memo we have also dismissed many other cases

Because interpretation of legal memos allow us to assess risk - not absolute.

We deemed there was a risk, highlights by the memo therefore better to err on the side of NOT breaking the law .

We didn’t need an absolute to make that call.

@Alan W. - if “for which legal permissibility has been indicated’ does not do it, do you have a suggestion of what would work for the RySG?

That is completely different from stating the memo has concluded that it IS legally permissible - It says it is likely permissible - and we have accepted this.

(Sorry Marika - responding to Hadia - I am much happier with your suggestion.)

@Owen: +1

But the RYSG issue remains that 2 pillars of financial and technical feasibility (which may very well be captured elsewhere - but we need to be sure that it is ) must also be considered

Did you say automated with manual intervention? Aren’t those two in opposition?

@Matt: That’s what confused me too.

Including investigation of complaints. Lets remember that if automation is truly possible and low risk, it is predominantly in the interests of the data controller to automate it. Why can we not leave it at that, folks? Investigate the chaps who automate to a “no” response in due time, as acting in bad faith, and stop fighting over an issue where the legal certainty cannot be resolved in a policy.

@Alan W. Please see footnote 32 & 33 which talks about commercial and technical feasibility.

+1 Alan

Let’s just remove the “automation” part, because it includes manual review.

+1 Owen

@Owen, unfortunately we have explicitely defined "automation" as possibly being human-assisted. It makes no sense semantically, but that is what we did.

Also don’t agree to automation with these use cases, and like Owen said, I thought we settled this when we were discussing all the use cases MarkSV presented to the Team.

Allocate responsibility?

Are we truly back to that?

Do we know that ICANN is willing to assume this responsibility?

It seems like we are so late in the game to be trying to iron this out and include this centralization

@Matt: +1

+1 Matt

The ECJ just gave the DPAs a rather stern admonition to do their jobs. I would suggest that “authoritative advice” coming out of any Brussels engagement in which ICANN has been taking part, with or without EPDP input, is not to be relied upon.

+1 Matt

I believe the RrSG continues to object to the deletion of the text

Not ok with deleting this section.

The blame is always on staff ;-)

Thanks Amr!

My point was to object to the deletion as well, just in case I was too brief.

I also need to step away for Hour Two; Ben Butler will cover for SSAC during my gap.

no protection is unacceptable. GDPR must be bottom line for all registrants

+1 Thomas. And EU Charter of Fundamental Rights.

Thank you Amr!

Excellent explanation of the Problems Amr.

Where is the revised language posted?

Can we see the language

ok

it was an attachment

emailed by Marika

+1 Alan G

the epdp team grudingly accepts...?

@AlanG: There’s still outstanding work on legal vs natural.

let’s see whether the work will be outstanding or horrible like a root canal

I will need more time to review/discuss- a 5 minute break during a call is not sufficient to consider these changes.

+1 Owen. Some of us were still asleep when this was sent :-)

@AlanG: I did say that I did not understand the substantive nature of what you were proposing, so was not my intention to put words in your mouth. Apologies, and thanks for the clarification. It was quite helpful.

@Laureen, and I am fine with that.

@Laureen: +1. There’s no update to the phase 1 rec on legal vs natural. I don’t see a need to point that out in this recommendation, but have no objection to it.

Agree with Mark SV- we need to consider this further offline

I too was sleeping when this was shared

we can add, per Laureen’s comment: “nor does it override the ability for Cps to differentiate between legal and natural persons as per rec #17.”?

Yeah this rec is of critical importance to many so ask that we can reserve comment on the list…can’t agree or disagree on this call I don’t think

+1 Matt

@Marika: Sounds good.

Maybe staff can share a Google doc of the proposed changes to Rec 8 for review after this call?

@Marika, fine with that.

@AlanW: +1

+1 Alan W

@Eleeza: Doesn’t the report specify GDPR as the only privacy law referenced in the report? Isn’t that helpful in narrowing down which law is referenced in terms of legal bases?

+1 Rafik re sleeping!

@Eleeza: Check line 263 in the draft final report?

+1 Marika

@AlanW: +1 again.

We have said little or nothing about the rights of registrants. We certainly can decide in a policy that GDPR rights are a minimum, and provide those rights through this policy to the extent possible. We can even, in the absence of legally enforceable Charter rights, honour those rights in our procedures.

To repeat, ICANN Compliance cannot overrule a contracted party’s determination. They do not do so now, and it’s no appropriate to do so in the future.

@Stephanie as you know GDPR sets a high bar so yes it is our minimum but it is a very good minimum

@Margie: How would the requestor know what the data contains, if it’s redacted?

There might be indications from the website itself

@Volker: +1

Org field does not need to be determinative - it's just a clue whether a subsequent reexamination is justified

It’s perfectly reasonable for the personal information of a natural person to be included in the registration data of a domain name held by an org. That’s a really low bar for seeking some kind of appeal or investigation by ICANN Compliance.

the determination must lie with the cp

@AlanW: Yup. Pretty much.

+1 Volker

Also +1 @Volker.

Also +1 Alan W

Margie's concern seems to already be covered by 8.10

8.10. MAY file a reexamination request if it believes its request was improperly 1186 denied.

The contracted party “reasonably” determines that ….

and 8.12

@Marc: Good point.

8.12. If a Requestor believes a Contracted Party is not complying with any of the 1194 requirements of this policy, the Requestor SHOULD notify ICANN Compliance 1195 further to the alert mechanism described in Recommendation #5 – Response 1196 Requirements.

no objection from me.

Seems ok

We’d continue to support MAY but not MUST as it seems too prescriptive and gets into management of how CP’s manage workflow

agree with Volker, do not support this change.

@Stephanie if the CP is not respecting the rights of the registrants that makes it not in compliance with GDPR and subject to huge fines

@Laureen: Isn’t the obligation to not just deal with them first, but also to deal with them with tighter deadlines?

@Stephanie - please see recommendation #11 SSAD Terms and Conditions.

@Laureen: Understood. Thanks.

@Stepahnie reporting this to a data protection authority is much better than reporting it to ICANN compliance

have CP withdrawn their objection?

I think should would be acceptable

no, still don’t like it

Owen has to break the tie!

+1 laureen

I have agreed to LOTs of things I don't like! And so has everyone else.

@AlanG: Indeed.

three categoeries, no more

everything else can evolved into the ssad later

@Volker - there would not be an additional category, just a requirement to prioritize those priority 3 requests that are flagged as consumer protection issues.

I’m OK with should. While some might think this is a simple sorting issue, registrars with millions of domain names have complicated tracking systems for these requests so it may not be easy to resort once a request is in process

Volker, would you accept such a queue-sorting requirement to be a non-policy issue under the evolution mechanism?

so lets have 4 levels of priorities

@alanwoods I added you because we didn’t hear from RySG

@ Volker -- I'm ok with keeping 3 categories, just prioritizing within 3rd category.

everyone would just call their issue consumer protection even trademark vioaltion can be argued to be consumer protection

This is simply an acknowledgement that queries from consumer protection orgs may warrant higher prioritization within the same Q.

lets discuss that im the standing committee

@Laureen - I'd say "sorting" within the 3rd category, since the categories are themselves defined by "priority" level

@AlanW: +1

Completely agree with Alan W

It's not OK to say that we'll discuss it in the standing committee if we subsequently determine that the standing committee has no scope to address such issues

this also looks like a trap. what is the consequence to not doing this?

and what will be the next category?

The proposal simply helps ensure that consumer protection requests are not t he ones where the SLA is not met (rules allow some % to not be met).

we have three priorities, lets stick to those

Might we maintain a civil tone gents?

The compromise is “should” instead of “may”, or something else?

I didn’t think “should” was acceptable if I recall what Laureen had said...

+1 Amr, I am also not 100% clear on the compromise langauge

@Voker fine but lets make sure that consumer protection requests are answered within the determined SLA

“shall be permitted to” is the best i can agree to

@Rafik: Thanks. Got it.

Describing prioritizing consumer protection requests as "strange" seems puzzling to me Alan W. Did I mishear?

it is an entirely undefined term. at this stage, it is a catch-all that fits all requestors

The outage referred to by Margie had nothing to do with ICANN

I think my point is that there are many laws that do that

if there is a law, it does not need stating, right? because the law already exists

I'm not sure I agree that DSP is unique in that circumstance (there are entities like Operators of Essential Services under the same NIS regulation that have similar obligations)

I don't think DSP is unique in that circumstance either. I was unclear: in the enumerated list of purposes, "I have an obligation" is missing if we don't have the DSP point. Not that DSPs are necessarily unique in that regard.

I think it’s fine to delete

@Marika: Right. +1

@Brian: That’s fair.

+1 Brian

Rec 6.3: The Contracted Party:• MAY reassign the priority level during the review of the request. For example, as a request is manually reviewed, the Contracted Party MAY note that although the priority is set as priority 2 (ICANN Administrative Proceeding), the request shows no evidence documenting an ICANN Administrative Proceeding such as a filed UDRP case, and accordingly, the request should be recategorized as Priority 3.• MUST communicate any recategorization to the Central Gateway Manager and Requestor.

Note that the proposal is to leave 1 business day not to exceed 3 calendar days, but with the footnote

The problem is that cyberattacks peak during those holiday periods to maximize impact when the bad guys know that security response staff is on skeleton crew, so that's precisely when the need for urgent requests is highest.

@Volker but we are talking urgent requests like life threatening issues

and we are talking about registration data

Court orders take time - the registration data helps us resolve issues quickly without going to court and to identify other likely attacks

+1 Volker. I fail to see when simple disclosure of data is so urgent that it needs to be done in faster time. Report abuse, get the police, etc to deal with really urgent/problematic domains

Even for a large registrar that operates 24/7, it still takes time to review and consider disclosure requests

we just last week got an “urgent” disclosure request where law enforcement wanted the data of a user of a domain (not the registrant)

these will come into this queue too.

5 is fine

As a reminder: “The criteria to determine urgent requests is limited to circumstances that pose an imminent threat to life, serious bodily injury, critical infrastructure (online and offline) or child exploitation.”

Also: “Abuse of urgent requests: Violations of the use of Urgent SSAD Requests will result in a response from the Central Gateway Manager to ensure that the 1024 requirements for Urgent SSAD Requests are known and met in the first instance, but repeated violations may result in the Central Gateway Manager suspending the ability to make urgent requests via the SSAD.”

that was for cat 2

this is a cannot live with

“should be consulted” or “may be offered the opportunity to comment” seems fine

Do note that the proposed implementation is also posted for public comment.

@AlanG: I suspect we can reach some kind of compromise along the lines of what you’re suggesting.

Compromise about to happen here

Buckle up

+1 to the combined proposals from Volker and Thomas.

Fine with Volker and Thomas

How about: “The prospective users of the SSAD, as determined based on the implementation of the accreditation process and Identity Providers to be used, should be consulted on setting usage fees for the SSAD. In particular, those potential SSAD requestors who are not part of the ICANN community must have the opportunity to comment.”

@Marika: That sounds good, but maybe add something along the lines of what Thomas said - that the IRT needs to be informed by SSAD users.

To remind: if there are issues with the fees that this service will have to charge … Phase I has also created a free version of the SSAD by way of undertaking by the CPS that they will review such disclosure requests. No charge there.

+1 Amr

Updated version: The prospective users of the SSAD, as determined based on the implementation of the accreditation process and Identity Providers to be used, should be consulted on setting usage fees for the SSAD. In particular, those potential SSAD requestors who are not part of the ICANN community must have the opportunity to comment and interact with the IRT. This input should help inform the IRT deliberations on this topic.

@Marika: I think that works.

novall you can eat buffet, please. that creates the wrong incentive

Fine with this latest version

This is additional language

No changes to any other sections, as far as I understand.

I need to drop a bit early today…thanks all!

I'm fine

Zero disagreement Stephanie.

@Rafik on many occasions you have allowed more than one person from the same group to speak, so maty you please let us know your criteria so that we can adhere to it - thanks

*may

Please note the phase 1 IRT meets at the top of the hour.

going over causes a conflict for many of us who are also on the IRT

Re: IRT, I emailed Dennis that some of us may be late. I can stay.

@Milton, correct. My mistake. Standing Comm. RECOMMENDATIONS

Maybe if someone has Dennis on speed dial, he can be asked to postpone or reschedule the IRT call

This recommendation is only in relation to adding new cases to automation - it does not try to limit the ability of the standing committee

@Rafik thanks I shall wait for my turn

@Milto does each group get to speak only once?

when did we agree to that each group speaks only once?

When did we agree to each group speaking only once

Anyway this is a crucial issue for ALAC

speaking only once is critical?

@ Milton -- I think the goal is trying to get clarity on how new automated use cases will be addressed -- whether that is considered within the purview of the Standing Committee or not.

Our request is consistent with the report

Need to drop, carry on!

NEXT ITEM PLEASE!

Lets see which groups object?

Rafik … are we agreeing with the Proposal or the addition?

RySG objects

Then what is the objection to the proposed clarification? Is there a suggestion to improve the language to make it acceptable?

that

S not what the recommendation says

I'm being told the start of the IRT has been delayed 30 minutes

It only addresses specific topics as recognizing that they would not need further policy work

@Marika there is no objection to a change in language - this recommendation does not intend to make any chnages

We really do need sufficient time to work through the remaining important issues.

tbh…, I don’t see the NCSG agreeing to these changes offline or online.

I don’t think we are talking about the staff proposal, but about the proposed addition?

no, it is booo, not booourns!

All what we want is a confirmation in relation to the automation cases

we agree with the staff proposal NOT to implement the proposed addition.

We agree with the Staff proposal - i.e. not add the language.

same

@AlanG: Objecting to the ALAC/BC proposal. Agree with the staff proposal.

For the record, it is not AlanG's proposal but the ALAC proposal.

Given the importance of this issue to so many stakeholder groups, perhaps we should try to spend a bit more time offline to come up with something that's acceptable. I'm still not clear on the basis for the objections.

+1 Laureen

@Laureen agree, the recommendation does not propose anything new it just confirms what is agreed upon.

+1 Alan G

@Milton Fees are one of them (presuming they are made in support of the policy we have written). There may be a host of other purely operation aspects of the SSAD.

We support the ALAC request here

Yes. Objecting to the proposed change.

GAC supports ALAC clarification.

We support ALAC request as well

I miss the agree/disagree features in AC rooms right now. ;-)

RySG objects

Oops, forgot to include attendees- RrSG objects

Struggling to understand why K'ed parties should have veto over issues that do NOT affect their obligations.

Additional call proposed for tomorrow at 14.30 UTC

Note that RySG has language in their proposal

Tomorrow's meeting?

14.30 UTC

Thanks, Marika. How long?

90 minutes

@Alan - we have proposed to make specific which topics are not addressed and with the GNSO Council.

I think we largely agree, and we think our proposed language is factual in that regard

Invite will be sent out shortly

@Matthew, you may feel thatit accurately reflects what was done. Others may not. BUt we botrh agree that the concl. section should not be silent.

That's baloney though

Our "time constraints" are entirely self-imposed.

Could we also have an update on the list of the new timescales

@Alan - fair point, and glad we are finding some common ground. Would be helpful to hear what in the proposed language is objectionable.

+l Chris LE

I am afraid the way we are pushing will lead to no consensus

Respectfully, these are artificial deadlines which may be changed.

By all - thanks

Disrespectfully, they're baloney :-)

Thanks all. Bye.