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

33:12
Members, please select all panelists and attendees chat option

33:43
https://community.icann.org/display/EOTSFGRD/g.+Draft+Final+Report+-+Phase+2

35:54
Rec3: https://docs.google.com/document/d/1Dde62eeOfCvf6qcbnXoLdYFF4Oum0RN2sz2jBuBm6yw/edit#heading=h.gjdgxs

38:15
Can you confirm that the versions posted are final?

38:24
I collected a few about 3 days ago and it looks like they're slightly updated since then

38:32
Thank you Marika

38:44
Can do!

41:26
saturday belongs to the family. it is not a workday

42:40
Thank you Marika, Berry, and Caitlin for this crazy amount of work.

43:09
+1 Beth

51:23
+1 Beth

51:39
+1 Volker

51:41
+1 Volker. There needs to be some sort of abuse handling, details can be fleshed out later

52:07
oops..

53:50
CPs can always refuse disclosure based on clear reasons

55:48
+1 Janis

57:21
MUST and SHALL mean the same thing , though??

57:25
not again!

57:42
1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification

57:47
https://tools.ietf.org/html/rfc2119

57:52
So, let's move on :)

58:26
Oh -- I wonder if the suggestion is that some should become lower-case 'shall' instead of capitalized meaningful SHALL

58:30
Let's pick one and use it consistently

58:39
I'd prefer to consistently use

59:13
consistently use a single one

59:49
Amr - we do. I think this question was if some should move from defined terms to non-defined regular-use 'shall'.

01:01:02
Agree with Marc - seems like we should change that paragraph but not the latter two

01:01:08
they seem more like Policy than guidance

01:01:28
We could move the highlighted portion to implementation guidance

01:02:38
OK by me

01:10:13
so wouldn't that just be two different requests?

01:10:18
if it's two different marks being infringed

01:10:25
or more, if the infringement is different in each

01:12:17
Marika, that is my understanding

01:13:26
If the rationales are different, e.g. one counterfeit and one phishing, then those should be submitted as separate requests.

01:14:14
Bulk requests are those that apply to multiple domain names for which all the disclosure request information is the same.

01:14:31
I thought we had a requirement that the SSAD can divide up th requests by CP as needed

01:14:32
Thank you, Marika. That's how I understood it.

01:14:32
SSAD would determine where the request would need to go and relay accordingly.

01:14:51
Agree with Marika but I didn't think that was what Brian K had described...

01:15:58
Each request would still considered on its own merits - it is purely about avoiding having to duplicate the requests for which the info is identical.

01:16:47
Batch okay. Bulk not okay

01:16:52
Bulk does not appear in the implementation guidance itself, to reassure everyone :-)

01:17:05
That is reassuring, Marika!

01:18:22
@Milton: Yes.

01:18:44
That should probably be in the recommendation itself, as opposed to implementation guidance.

01:19:56
I disagree that batching 100 requests is more expensive than sending 100 individual requests. They still arrive at the CP as 100 individual requests

01:20:25
@Milton, we've been feasting on dinner for 6 weeks. ;-)

01:24:09
If requestors pay per request and submit a request for 100 domains with the same basis/etc, but which are across 5 registrars, do they pay once or 5 times or 100 times?

01:24:27
we don‘t want to incentivise bulk requests

01:25:14
We are violently and incoherently agreeing! The 100 requests are indeed charged at the 100 request rate. But I had to push the Send button fewer times when I sent them

01:26:11
and incoherent

01:26:18
:-P

01:28:17
@AlanG: It’s never free. Someone will always have to pay for it. If the requestor doesn’t cover the cost, the cost will be shifted to other stakeholders, won’t it?

01:28:28
Sorry all, I need to drop off early for (recurring) conflicting meeting. Ben will cover for SSAC. Thanks!

01:28:50
Yes, but as Chris is saying, the accreditation agency may be funded centrally and not use a per-accred fee.

01:29:55
MUST is a suggested change, not "retained" just FYI

01:29:56
@Amr supporting the public good benefits all stakeholders

01:30:01
@James: +1

01:30:39
@Hadia: I’m not arguing for or against that. Just saying, as James just did, that the cost doesn’t go away, and needs to be paid by someone.

01:33:07
If we are going to keep “MAY” then we need to define which users will not be required to cover the costs of their accreditation. And to my knowledge, we haven’t done that yet.

01:33:17
+1 James

01:33:27
If we agree that financial sustainability is based on a cost-recovery basis, that would suggest that the cost needs to be recovered from fees paid by other SSAD users, doesn’t it?

01:34:31
@James moving to must with a disclaimer could solve this issue

01:34:37
Then they can pay through the applicant

01:34:44
Like the bill can go to the applicant and they can ensure someone pays it

01:35:01
Correct Sarah. They still pay, but we don’t decide or limit where they’re being reimbursed

01:35:50
Having a bill go out that the applicant forwards to someone else Is just not practical.

01:37:08
@Alan agree forwarding a bill to someone else does not work

01:37:59
If the applicant doesn't ensure the bill gets paid, what is a practical alternative? In my experience doing customer billing and account management, it's hard to get paid especialy if the actual accountholder/user is not the one doing the payment

01:38:04
I’m not sure forwarding a bill to a 3rd party is something we can practically recommend. How would this be enforced?

01:42:25
but that's not a third-party, then it's either the applicant or the accreditation authoirty

01:42:33
which i'm fine with

01:42:36
but doesn't match what alan g proposed

01:43:54
I agree the current language d/n address the concerns.

01:46:15
That sounds good, Laureen.

01:46:27
Strikes the right balance

01:47:54
It's "waived" not "waved."

01:48:20
Yes

01:48:42
Good edit

01:48:46
+1 Amr

01:48:59
amr+1

01:49:09
+1 amr

01:49:28
Can we get clarification on what "explicit additional charges" means?

01:51:07
Hi folks - Dropping early today. Owen Smigelski will step in for the RrSG. Thank you!

01:51:47
I really don't think Registrants should be paying for this system

01:52:03
we said data subjects MUST NOT bear the costs. the registrants are the data subjects

01:52:51
+1 Sarah.

01:53:01
Well said, Volker

01:53:02
@Volker: +1

01:53:38
Yeah…, agree with Volker on all this.

01:53:39
subsequent running of the system happens on a cost recovery basis

01:53:46
@Sarah: +1

01:54:34
What if applicable law REQUIRED disclosure. Would the cost of that disclosure mechanism be borne by requestors?

01:56:03
it is not THEIR data, it is their DATA

01:56:04
For this SSAD system? Sure. Alternatively, the requestor can come right to the registrar and request the data for free.

01:56:29
This is a hard, worked-out compromise. We wouldn't want to change it

01:56:57
maybe I’m missing something but if ICANN subsidizes how do you avoid the fact that ultimately registrants are paying for disclosure?

01:57:54
or the other requestors subsidize the freebies...

01:58:51
exactly Becky

02:00:14
The “their” still needs to go.

02:00:26
Makes the sentence mean something totally different.

02:00:28
+1 Amr

02:00:35
only a little bit...?

02:01:11
That sounds good to me.

02:03:22
@Volker: +1

02:03:38
+1

02:04:04
What about the 40+% of registered name holders who are not "data subjects" - may they pay for natural person registrants' data to be disclosed?

02:04:35
they shouldn‘t either, brian

02:05:05
we could habe simply said. fees should not go up or new fees introduced to finance ssad

02:06:49
I haven't heard anything to convince me to change the existing language

02:08:16
As Laureen said, it should be "waived"

02:08:27
(That's a "cannot live with" right there.)

02:08:35
implementation

02:08:40
;-)

02:09:45
yes

02:09:50
Change the last sentence to "The EPDP Team also recognizes that governments may be subject to certain payment restrictions which should be taken into account in implementation.

02:10:23
Love it

02:10:38
<3

02:10:38
I'm very effusive.

02:10:51
You know we revere you Janis --

02:10:54
LOL.

02:13:08
Agree with Alan W

02:13:39
@AlanW: +1

02:13:56
@Volker: Exactly.

02:15:30
Oh god love them!

02:15:30
we will try :-)

02:16:03
Sure

02:17:44
Maybe we combine these two paragraphs to better make the connection?

02:18:22
Can we all get historic cost refunds for time served in EPDP?

02:19:03
If we automate and CP's costs go down, good for them!

02:19:05
@Brian: LOL!! Count me in!!

02:19:57
works for me

02:20:41
what does it mean for current CP costs to be considered?

02:20:47
that suggests ICANN may not recover development and deployment, only operations

02:20:49
like, what is the practical effect?

02:20:58
no objection to remove

02:21:48
@AlanG: +1

02:22:03
That sentence was put in for a reason!

02:23:01
Add after "historic costs", "(that is, the costs born by contracted parties prior to the SSAD)"

02:23:27
but "borne by contracted parties prior to the SSAD)" is not the same as "costs for developing, deployment, and operationalizing" which is what Marika referenced

02:23:52
yes, janis, we are

02:24:50
agree Sarah, but not sure the language says that.

02:25:06
@Becky: +1. Requires clarification.

02:25:22
Becky - right, so we should figure it out

02:25:53
@Marc: +1

02:26:44
Keep as I’m running out of time - this is the start of the potential foot note …. “Given the potential for legal uncertainty and the heightened legal and operational risk on all parties included in the provision of the SSAD, creation of a legal risk fund refers to the creation of a suitable legal contingency plan, including but not limited to appropriate insurance cover, and any other appropriate measures that may be deemed sufficient to cover potential regulatory fines or related legal costs. “

02:26:51
Not perfect by any stretch … but .. time …

02:27:01
I'm unclear how CP costs would be calculated, recovered, etc.

02:27:14
I like AlanW's language as a good starting point for reivew

02:29:19
Note there is a week of no calls for groups to do homework.

02:29:29
Thanks, all.

02:29:37
Ok Berry thanks

02:29:37
Thanks all. Bye.

02:29:39
Thanks everybody

02:29:42
And if homework is done and groups prepared, maybe we complete in 2. ;-)

02:29:43
bye all