
34:29
Good morning all

34:47
Hi all!

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

37:07
Bad audi from Rafik

37:23
Rafik, you are breaking up a bit.

37:28
audio is bad too, heck with his car

37:42
Better now...

38:19
disappaearing

38:19
Whoops…lost him

38:20
Cut out now

38:26
no sound

38:56
maybe a dial out?

39:19
+1 Amr

39:23
LOL

39:38
too bad

39:46
the internet gods are trying to tell you something, Rafik

40:25
Please stand by while we dial out to Rafik

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

41:37
Again cutting out.

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

42:04
Rafik sounds okay on my end

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

49:51
+1 Brian

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

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

50:38
@Amr, all parties except NCSG favored the centralized model

51:46
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)?

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

53:44
Yeah I can accept it too

54:09
we know that, Brian.

54:20
Welcome to the world of multi stakeholder compromise and consensus

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

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

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

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

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

57:17
And I meant “Expectation” not “Exception”. Sorry

57:34
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

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

58:25
whoops - *not possible

59:37
@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.

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

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

01:02:39
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

01:02:41
We cannot "INSTRUCT" the Council. But we can try!

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

01:03:15
yes

01:03:33
+1 Thomas

01:03:38
It says "must", not "MUST". So the IETF implication are not there.

01:03:46
exactly, Alan :-)

01:04:22
speculation is not the best use of our time

01:04:48
+1 to Thomas' suggestion

01:06:58
let’s try, Amr!

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

01:09:48
yaaawnn

01:09:52
lol

01:10:23
We can make clear that the interdependency is for the SSAC recs?

01:11:02
Sorry SSAD

01:23:26
If we need input, give us a chance to comment.

01:23:28
what did you propose?

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

01:23:48
we don’t need that!

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

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

01:24:14
The hope is also that some proposals can be accepted without needing further discussion

01:24:31
we can’t know whether they will be accepted unless we can discuss them

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

01:25:02
@Milton - input has been encouraged on the google doc

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

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

01:27:44
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.

01:29:25
+1 @Laureen

01:29:34
this is not a good procedure

01:29:39
+1 Marika

01:30:12
ok, so NOW WE DISCUSS, right?

01:31:06
what is outside of the charter? What recommendation does it conflict with?

01:31:13
Sorry Alan…what isn’t part of our charter?

01:31:33
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.

01:32:36
+ Chris

01:33:40
+1 Chris

01:33:54
there is a mistake in Chris’s analysis which I will explain

01:36:24
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.

01:36:32
Please don’t cut this important discussion short with this arbitrary 10 minute limit

01:36:50
+1 Amr.

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

01:37:42
sure, I will

01:38:51
we are not managing time, we are managing policy development.

01:39:06
Unfortunately I think you mean "level of consensus", Rafik.

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

01:41:47
I have a specific new point to make

01:45:22
Why are we not using the time?

01:45:40
Per speaker?

01:47:53
+1 Marika

01:50:05
we agreed on one

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

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

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

01:55:26
and a lot more rare

01:55:48
you should see some of the “urgent” disclosure requests we see...

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

01:56:26
For which there is a different SLA

01:56:39
but still has to do that in the time for the urgent one

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

01:57:00
would’ve could’ve

01:57:51
Rafik, I actually did raise a possibility to deal with this.

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

01:59:31
objection

02:00:59
Noting again that denying a request is always the fastest response.

02:02:26
Any denials need to be justified --

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

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

02:04:22
thanks mark, lets go back to business days then

02:11:58
am I misremembering? sorry if that is the case.

02:12:32
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

02:14:41
indeed, I thought we were trying to resolve differences, not just state them

02:15:09
@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.

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

02:17:05
What is ‘may

02:17:10
Is changed too ‘should’?

02:17:29
That allows for flexibility but makes the expectation clear?

02:17:55
Would be happy with SHOULD

02:18:08
Trying again, what if ‘may’ is changed to ‘should’?

02:18:29
will be

02:19:06
Victims?

02:19:26
if you order the music, you pay the band

02:20:17
It is very clear in their report that there will be fees.

02:20:22
Its part of maintaining the security and stability of the Internet as a whole

02:20:48
Its part of ensuring a safe ecosystem

02:20:50
@Amr, yes some of the cost. All registrants benefit from the SSR of the DNS.

02:21:28
Note that the current language says ‘may’

02:23:43
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

02:24:00
We are hearing two different position from different Rr reps

02:24:50
“Should” is ok

02:24:53
I can accept SHOULD

02:25:08
ok

02:26:57
Please note that the current language says ‘may’.

02:27:44
@Amr we were at MAY

02:27:47
This is implementation guidance so using MUST is inappropriate in any event

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

02:28:11
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'.

02:29:04
works for me

02:29:50
14.8 says there will generally be fees!

02:29:56
need to see the language

02:30:00
What is the proposal?

02:30:37
The proposal is changing ‘may’ to ‘should’ as displayed on the screen.

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

02:35:38
+1 Alan G

02:48:58
+1 MarcA

02:49:02
Good suggestion Marc

02:50:34
No concern…good call out

02:57:04
Also feel free to list your items in the chat

02:58:36
SSAC: 27; 37-41

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

03:04:05
There will be 4 more min of silence. Chats are being recorded.

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

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

03:06:34
@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.

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

03:09:30
ALAC, 1, 8 and more later.

03:10:06
NCSG Rec 8

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

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

03:11:25
BC: 37

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

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

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

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

03:24:48
but will never admit it

03:25:21
@James - I had a similar question about the 5-calendar day issue...

03:25:24
+1 James.

03:25:42
5 already is the compromis mark

03:26:04
that was a question from James, will we get an answer?

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

03:27:51
we should respect ICANN‘s role and limitations here.

03:27:53
because we been there, done that, hadia. never again

03:29:16
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

03:32:28
Wrongful denials that are unreasonable can be reviewed

03:32:54
+1 Margie

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

03:33:18
Thanks all

03:35:00
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.

03:36:18
thank you all and let’s try harder