Good morning all

Hi all!

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

Bad audi from Rafik

Rafik, you are breaking up a bit.

audio is bad too, heck with his car

Better now...

disappaearing

Whoops…lost him

Cut out now

no sound

maybe a dial out?

+1 Amr

LOL

too bad

the internet gods are trying to tell you something, Rafik

Please stand by while we dial out to Rafik

Oh and no adding 10 minutes onto the end of the call to make up for lost time :)

Again cutting out.

@Alan - it may be on your end this time around? Audio loud and clear on my side.

Rafik sounds okay on my end

https://docs.google.com/document/d/16BICriVfOPiEeve4A-x6TYKPbgRKqvhX/edit

+1 Brian

I don’t think it’s correct to say all parties were in favor of a centralized model…

Link to Cat 1 Input doc: https://docs.google.com/document/d/16BICriVfOPiEeve4A-x6TYKPbgRKqvhX/edit

@Amr, all parties except NCSG favored the centralized model

Would a possible compromise be to follow Chris L’E’s suggestion that although some preferred the centralized model, the group has put forward the hybrid model (or something along those lines)?

I’d prefer that the report describe the disagreement among the parties on this point

Yeah I can accept it too

we know that, Brian.

Welcome to the world of multi stakeholder compromise and consensus

No one said “everyone rejects the centralized model” it says not “everyone could accept the centralized model”

I worry about setting the exception that more centralization is somehow inevitable. The legal/regulatory environment could get WORSE. See ECJ decision last week.

Or BETTER, depending on one’s perspective ;-)

@Milton I was trying for an accurate reflection the team did not reject but came to a compromise...

we’ve already said we would accept Alan’s minor language change

And I meant “Expectation” not “Exception”. Sorry

I think we perhaps need to reflect why the centralized model was possible - based on the legal advice from Bird & Bird and consultation with the Belgian DPA, we determined that that a fully centralized model could not legally achieve the diminishing of liability that was a pre-requisite for implementing such a model

@Chris. in coming to a compromise we had to reject certain options (centralized, decentralized)

whoops - *not possible

@Matt I'm not sure that we "determined" that (not to my satisfaction, anyway), but yes, I think noting that is at the root of our deliberation/disagreement would be wise.

@Amr - the Council is ‘strongly discouraged’ but it is not required to do so.

@Marika: On the first item, Matthrew’s language should be considered when revising the language:

think we perhaps need to reflect why the centralized model was possible - based on the legal advice from Bird & Bird and consultation with the Belgian DPA, we determined that that a fully centralized model could not legally achieve the diminishing of liability that was a pre-requisite for implementing such a model

We cannot "INSTRUCT" the Council. But we can try!

why don’t we just say we prefer this to be adopted as a package and move on.

yes

+1 Thomas

It says "must", not "MUST". So the IETF implication are not there.

exactly, Alan :-)

speculation is not the best use of our time

+1 to Thomas' suggestion

let’s try, Amr!

I agree with Marc on procedures, but that being said, the words are good.

yaaawnn

lol

We can make clear that the interdependency is for the SSAC recs?

Sorry SSAD

If we need input, give us a chance to comment.

what did you propose?

we should try to actually resolve easy issues and reduce the number of open items.

we don’t need that!

So we are saving discussion on the items marked with "Proposals" to the end of our discussion today or on Wednesday?

@Laureen - it will depend on how much time is left :-)

The hope is also that some proposals can be accepted without needing further discussion

we can’t know whether they will be accepted unless we can discuss them

My concern is that the items marked with Proposals actually raise some challenging issues. I don't want them to shortchanged.

@Milton - input has been encouraged on the google doc

I note that many groups have reviewed and responded to the proposals in the Google doc. IIRC that was our homework.

we don’t need to listen to people reading what is on the Google doc, Marika

Part of the resistance you're hearing is because we were informed that we would discuss this in order, one by one. Now we are skipping some for the end of the process and some of us are concerned we will not get a meaningful opportunity to discuss and resolve them.

+1 @Laureen

this is not a good procedure

+1 Marika

ok, so NOW WE DISCUSS, right?

what is outside of the charter? What recommendation does it conflict with?

Sorry Alan…what isn’t part of our charter?

Yes - as outlined in Rafik’s email, all those items for which QUESTIONS have been identified, are for discussion now, for all those for which a PROPOSAL has been identified, the idea was to introduce the proposal, not to discuss it, to allow groups to think about whether they can accept the proposal and the group can move on (without further deliberation) or whether there is a need to come back to it.

+ Chris

+1 Chris

there is a mistake in Chris’s analysis which I will explain

Our mandate was clear. General privacy protection may be admirable and we could have a PDP on it, but t hat is not this EPDP.

Please don’t cut this important discussion short with this arbitrary 10 minute limit

+1 Amr.

Can someone explain the idea of competitive disadvantage? That argument has never made any sense to me

sure, I will

we are not managing time, we are managing policy development.

Unfortunately I think you mean "level of consensus", Rafik.

Alan has already spoken. Chris has already spoken on this. How is it that Stephanie and I cannot?

I have a specific new point to make

Why are we not using the time?

Per speaker?

+1 Marika

we agreed on one

So then let’s remove the calendar days altogether and keep it as one business day

I hadn't realized we could use this process to re-open issues where we were not happy with the results.

The existing 24hr rule is for Law Enforcement requests, which are easier in a way.

and a lot more rare

you should see some of the “urgent” disclosure requests we see...

@Volker - but if those do not meet the criteria, a registrar can recategorize it as a priority 3 request.

For which there is a different SLA

but still has to do that in the time for the urgent one

Volker, in the current system there are no safeguards against bad requestors, whereas this policy would implement such safeguards

would’ve could’ve

Rafik, I actually did raise a possibility to deal with this.

legal vs natural comes to mind. or accuracy. how many days have we wasted on addressing those topics?

objection

Noting again that denying a request is always the fastest response.

Any denials need to be justified --

That’s the unfortunate & unintended outcome of time-limited review processes.

@Laureen apparently the justification will be "I didn't want to staff this function and I wanted to go on vacation"

thanks mark, lets go back to business days then

am I misremembering? sorry if that is the case.

Anyway: When Rafik asked if there were any objections, only Volker responded. Even if Volker speaks for all Registrars, that is only one of the many groups in this EPDP, so should we allow one objection to block consensus? Still not clear what we are trying to do here today

indeed, I thought we were trying to resolve differences, not just state them

@Mark - part of the objective is indeed to better understand what remaining cannot live with items may remain and cannot be resolved which will factor into the consensus designation process. But obviously the goal is to try to resolve as many as possible.

in germany, tax authorities were buying cds with leaked evader data left and right...

What is ‘may

Is changed too ‘should’?

That allows for flexibility but makes the expectation clear?

Would be happy with SHOULD

Trying again, what if ‘may’ is changed to ‘should’?

will be

Victims?

if you order the music, you pay the band

It is very clear in their report that there will be fees.

Its part of maintaining the security and stability of the Internet as a whole

Its part of ensuring a safe ecosystem

@Amr, yes some of the cost. All registrants benefit from the SSR of the DNS.

Note that the current language says ‘may’

If BC/IPC are right about SSR of the DNS being fundamental to the internet, then registrants are the main victims, yet they seem to be suggesting that those victims should pay

We are hearing two different position from different Rr reps

“Should” is ok

I can accept SHOULD

ok

Please note that the current language says ‘may’.

@Amr we were at MAY

This is implementation guidance so using MUST is inappropriate in any event

We cannot keep on re-opening decisions that we made LONG ago and have not changed in recent report versions.

Exactly, Chris - the language is ‘may’, there was a proposal to change it to ‘must’, and the compromise proposal is to change it to 'should'.

works for me

14.8 says there will generally be fees!

need to see the language

What is the proposal?

The proposal is changing ‘may’ to ‘should’ as displayed on the screen.

As long as the other line is retained and/or referenced here, I think it’s ok

+1 Alan G

+1 MarcA

Good suggestion Marc

No concern…good call out

Also feel free to list your items in the chat

SSAC: 27; 37-41

So basically items 1-41 on this list (for those where there is a proposal): https://docs.google.com/document/d/16BICriVfOPiEeve4A-x6TYKPbgRKqvhX/edit

There will be 4 more min of silence. Chats are being recorded.

How will we address items which have neither a question nor a proposal. Example: 16

GAC: 1,7,8,10, 13, 14, 16,18, 22-25, 27, 34 37-41

@Alan - I think groups who have indicated it as a cannot live with items can flag those as well and provide the context that was requested.

RrSG: 16, 21, 23, 24, 32, 34, 36, 39, 40, 41 (partly)

ALAC, 1, 8 and more later.

NCSG Rec 8

BC: 1,7,8,10, 11, 23, 24, 27... maybe others

RySG: 1,5, 10/11, 21-24, 37-41

BC: 37

BC: 1,7,8,10, 11, 23, 24, 27, 34, 37

IPC: 1, 7, 8, 10-11, 18, 23, 24, 27, 34, 37-41

@amr understand and would love to see a proposal that covers your concerns that doesn't remove all the language

Contracted Parties cannot defer their determination of legal risk to ICANN org. Brian and other lawyers understand this.

but will never admit it

@James - I had a similar question about the 5-calendar day issue...

+1 James.

5 already is the compromis mark

that was a question from James, will we get an answer?

I don’t think Brian and Frank can answer here, maybe take the question back to IPC

we should respect ICANN‘s role and limitations here.

because we been there, done that, hadia. never again

you cannot force ICANN org to review decisions, but all other aspects. that is why we have eg put the requirement to give rationales in the recommendation

Wrongful denials that are unreasonable can be reviewed

+1 Margie

Ie phishing & fraud denials where the request was properly made, proof provided, yet request denied

Thanks all

Unless of course there is PII involved in the decision … which does not need to be disclosed. I think you are not spending enough time in the boots of the controller Margie. It is our job as a controller to protect the data we hold. You continue to think that we are able to run rough shod over that to appease. This is not us being obstinate .. it is is being responsible controllers.

thank you all and let’s try harder