
31:11
me too

31:18
Yes, I am letting her know

31:18
yuo

31:21
Thanks Andrea

31:22
yup

31:40
Hope it is only her

31:46
Yes, I believe it is her line

32:26
Better now

32:31
Can you dial in again? This is a bit of a fill the blanks exercise

32:45
Hi folks. Please note that I’m an alternate today.

34:13
Janis hard to hear. Just me?

34:54
I think just you, Alan G

35:06
very distant for me too

35:11
nope. He is very distant.

35:24
215-858-2257 is Greg

35:50
Thank you, Greg

36:15
ouch

38:33
Folks the audio is cutting in and out pretty aggressively.

38:38
Is today the berlin meeting day?

39:06
Yes, Chris. IGF.

39:09
@Chris yes, they even had Angela Merkel and UN Secretary General :)

40:01
$3M from Donuts,. Everyone else just chips in coins from the couch cushions

40:11
I asked Angela for asylum in Germany and she said Yes

40:35
as long as Microsoft builds the system and maintains it!

40:37
But, she said, first you have to do the ICANN EPDP meeting

40:50
:-)

41:29
unmute my phone please

42:01
Causing feedback, I will unmute when Beth is done speaking.

42:15
+1 to Alan and Beth, this is very sudden and we have open questions waiting for answers that I thought would provide input to this exact question

46:22
This is proposed language from the CPH team

47:03
building block N starts further down …..

48:43
thank you Caitlin! :)

50:59
apologies for being late

51:11
Whatever is best for the team, sure

51:19
This was intended to replace most of what is there already

53:45
I thought we can't estimate what to charge users until we understand the cost of creating and maintaining the system?

54:51
@Sarah I think Margie's referring to upfront integration cost for accreditors/users, as opposed to usage cost

55:01
yes- sorry I wasn't clear

55:27
Thanks for clarifying

57:09
I thought we had decided that there would be only one accrediting party, ICANN

57:10
yes - Alan G - I was referring to that development

57:29
ICANN accredits accreditors

57:41
so ICANN would accredit WIPO as an example

57:50
I thought we said ICANN was the accreditation provider??

58:10
No, there will not be accreditation of accreditors

58:22
I think we must try to develop principles now since that is all we can determine right now

58:34
principals

58:50
+1 Alan it is very difficult to determine in detail the financial aspects of an unknown system

59:56
I thought there is a web interface?

01:00:01
Yes, +1 Beth!

01:00:04
we could just put general principals if everyone agrees

01:00:28
Why don’t we start with CPs sharing their current volume of requests and make a projection as well as the other groups on this team.

01:00:53
+1 Thomas

01:00:56
The CPH proposal takes us to principles instead of specifics, may be helpful.

01:00:59
I don’t think we are looking for number now, just agreement how that number will be paid for

01:01:07
There will for sure be a substantial difference in projected figures, but maybe we can then settle on a middle ground so we have at least the same fact base.

01:01:23
I think that current volumes will not be indicative of a future centralized system

01:01:32
So isn't this estimate exactly what we asked ICANN Org for?

01:01:42
possibly not, but it's a better starting point than nothing

01:01:51
We need to get aligned on the order of magnitude. Policies will potentially be adjusted based on that.

01:02:12
+1 Sarah

01:02:17
Maybe even split between private requestors’ requests and LEA requests.

01:02:29
+1 Sarah

01:02:31
I agree with Sarah, but the question is whether we can or should wait for that.

01:04:12
+1 Thomas ..... is this, not wanting to open pandora's box, a question of what goes into the initial report or not and whether it will be ready in time or not??

01:05:10
Sounds good Janis, thank you.

01:06:39
If we are anticipating simply a distribution point (because we can’t yet determine who the decision maker is) should we not then try to be conservative in our approach as a simple system could likely scale to accomm

01:06:46
Date more requests

01:07:00
+1 Beth

01:07:08
+1

01:09:58
The central system should be able totell if a data element is missing, and return an error code.

01:10:10
+1 mark

01:11:32
Agree with Greg that many/most syntactical errors will algorithmically bounce back to requestor before ever getting to the decider.

01:11:32
assuming greg that you are talking about missing fields … not a change of fundamental details to do with reasoning?

01:12:11
+1 Alan

01:12:11
I still think that if a request is not properly formatted, it needs to be fixed and resubmitted

01:12:18
There may well be web interface, but at the policy level, we need to allow for an API interface as well.

01:12:45
Having an incomplete requ

01:13:01
st is not in line with the requirements of Rec 18 in Phase !

01:13:17
Sorry I keep hitting ‘return’ mid comment!

01:13:29
Thank you, Caitlin! Super helpful

01:15:59
Someone who contiinually submits mal-formed requests is abusing the system and should be dealt with that way.

01:17:08
agreed

01:17:28
should it be 'amend OR resubmit' ? because we don't know exactly how the system will work yet

01:17:33
and/or ?

01:17:41
Only if Mark's amendment does not equal a new request

01:17:42
+1 Alan. Also an amended request (not an non-accepted, incomplete request) should be considered in a balancing test …..

01:17:45
for cost purposes

01:17:58
really like Sarah's suggestion

01:19:17
So this is assuming an automated system

01:19:22
which is probably okay?

01:20:10
This is a good point, Beth

01:22:12
Brian that is helpful. We should be more clear about that in the text please.

01:22:44
If it is an incomplete request is submitted it certainly does not pass to the decision maker

01:22:58
such faith in automation

01:23:22
The decision maker only looks into full and complete requests

01:23:34
If we replace "the entity receiving the access/disclosure request" with "the SSAD", that should do the trick.

01:23:58
Yes, once the SSAD passes the singularity we can refer to it that way

01:24:13
My take on this would be: Where the requestor fails to fill in all fields or where the examiner requests additional information, a supplemental fee can be charged at the discretion of the examiner.

01:24:38
Sure Brian that makes sense

01:24:44
You can still fill a box with nonsense ……. and claim that it's an incomplete request … and unless Skynet has gone live, AI will not be making those calls. Empty box - system will not allow it.But if you want to Amend what you put into the box, unless you are rectifying a clear error (could be one of the denied options - denial but opportunity to amend)

01:24:50
@Milton the entity receiving the request will make sure requests are complete whether through automation or through other means

01:24:50
exactly what Greg is saying... lol

01:25:03
We want to ensure that the requestors provide all information at hand upfront and not try salami tactics with examiners.

01:25:17
In the event that the access/disclosure request is deemed to be incomplete, the requesting party will be given an opportunity to amend. . .

01:25:23
+1 Greg

01:26:12
@Greg but this will only happen during the determination phase

01:27:35
In the event that the access/disclosure request is deemed to be misinformed, incomplete, and or requires additional information, the requesting party will be given an opportunity to amend and resubmit its request.

01:28:05
Mal-formed not misinformed …

01:29:06
I continue to think that most of the disconnects on this text is that we are all operating with different visions of what this system looks like and how parties interact with it.

01:29:13
+100 Beth

01:29:30
There are still many unknowns that have real significant effects on our decisions

01:30:07
True dat Beth + Sarah

01:33:06
Change it to business days and it is still a tough timeline to beat

01:33:11
This is specifically for not automated responses, Margie

01:33:24
‘When we get to it’ is still the best I can offer

01:33:39
This is specific to requests that cannot be responded to automatically

01:34:06
We truly need to be realistic here, as our risks are very real

01:34:23
I cannot imagine that we as controllers of the data will have nothing to do with this

01:34:28
if nothing else, the data must be provided to the SSAD

01:34:31
so there is involvement

01:35:35
@sarah - if its an RDAP reply - this timeline can be met

01:36:23
We had recommendation 18 because there was no system for disclosure in place. The new system should have its own elements and parameters

01:36:34
So I get the hope.... but if we are still can't decide between 3 different models, then the placeholder for the building blocks should be threefold

01:37:13
…should endeavour to be returned within [timelines to be determined]…

01:37:16
If all we're asking CPs to do is respond to an RDAP query, the current SLA in the Registry Agreement is ≤ 2000 milliseconds, for at least 95% of the queries

01:37:45
Brian we can't expect that SLA to apply for non-automated disclosure decisions

01:38:00
Placeholders should not look like maximum demands

01:38:02
Good question, Beth

01:38:34
Brian: those were automated. This is about non-automated respomses

01:39:16
So the RDAP SLAs cannot even remotely be compared

01:40:51
Tough timelines make for sloppy reviews

01:41:29
@Milton, remember that Alan W had reported that he at the time of his report, he had never had to do a balancing test.

01:41:30
Do CPs care what the SSAD SLAs are, if the CPs are only required to respond to an RDAP query?

01:41:40
Yes

01:41:49
@Milton we hope the CPs won't need to make the decision. As for the old WHOIS it is dead and not coming back

01:41:53
@Sarah, I suppose that's what I don't understand.

01:41:58
They are responding to a disclosure request that must be conformant to data protection law, not an "RDAP request"

01:42:08
@Sarah, I also don't understand

01:42:13
European laws are full of relative definitions like that. And we have not devolved to chaos yet

01:43:48
The second half of Brian's question, " if the CPs are only required to respond to an RDAP query", is a big assumption that I don't think we can make yet, and thus we do need to care about these response times

01:44:48
is that what the legal advices says is the actual reality of the situation is Brian.

01:45:52
@Alan yes, of one particular set of facts.

01:46:30
ICANN has proposed a different set of facts to the DPAs for opinion

01:48:00
Yes Mark, but we must always base our estimations on the weakest link

01:48:02
........ so let's wait until we get the answer so Brian . Absolutely agree! Wonderful plan. no need to 'lock it in' if we are pending that answer so

01:48:38
+1 Alan

01:48:40
+1 Beth

01:50:34
@Beth currently there is one particular idea that we all hope it works

01:50:36
@Alan sure thing, and let's do all we can in the meantime (not necessarily "wait" IMO).

01:51:10
@Beth sure let's try to work that up and chew on it. What does that look like?

01:51:20
With both "should" and "preferably" I think it'd be OK, but would need to discuss with my SG.

01:51:59
Ok with "should"

01:52:11
not sure what "preferably" does for us

01:52:33
OK so not presupposing the response you are waiting for is probably considered the 'right' thing so.

01:52:49
I assumed we're using those IETF-defined terms, yes?

01:54:00
@Brian, appreciate that! I think some of the CPH comments tried to move in that direction. Towards language that is flexible and more neutrally describes what a system would look like.

01:54:29
@Beth I'll look for that language

01:54:53
Could we adopt the language for this that we use in Rec 18 from phase 1?

01:55:03
Why recreate the wheel?

01:56:02
Rec. 18 was meant for the manual requests - not the SSAD

01:56:27
I wish, MakSV, I wish

01:56:32
MarkSV

01:56:35
could we ask ICANN compliance if they would enforce that language?

01:56:59
:-)

01:57:51
I have no problem with specific timeframes for urgent requests provided they are limited as to who can make them and spelled out in business days

01:58:16
Lost Janis sound?

01:58:20
lost audio

01:58:20
Did Janis drop?

01:58:23
we are checking into this

01:58:34
Yes, thanks

01:58:35
ye

01:58:36
yes

01:58:43
yes and much clearer now

01:58:55
I am worried about "business days", as opposed to "calendar days", which again feels like a compromise to enable the most-poorly staffed entities to provide worse SLAs

01:59:25
stay on whatever audio you're on, Janis! Agree with Alan W that you're clearer now

01:59:28
we lost you again

01:59:47
the problem is that there are 7 of us in a room with a polycom

02:00:01
Re: business days, if the request comes on a Friday or holiday, then 1 day could become 3. That would undermine the rapid response that is the goal.

02:00:14
It is the same SLA, just different timeframes

02:01:13
So *everyone* is allowed to provide SLAs crafted to support the most poorly staffed entities

02:01:44
No, since not everyone is so poorly staffed as to have less business days in the week

02:01:57
Business days btw also is a legal term

02:02:09
It just means no week-ends, no holidays

02:02:19
+1 Volker

02:02:50
So the SLA only differs by what and how many public/bsank holidays there are in any given country/state

02:02:55
Yes, we all understand the difference between Bdays and Cdays and that is why I object

02:03:25
So why the argument with the poorly staffed entities if that does not matter to the definition of business days?

02:04:25
I want calendar days. As you say, business days varies everywhere - less predictable. It's not as if cybercrimes happen less frequently on weekends or bank holidays

02:05:03
And yes, business days means that it could become Wednesday if you send you request on the Friday before the winter holidays if the 25.th falls on a Monday

02:05:34
I think that's fair, Beth.

02:05:36
+1 for that for me.

02:05:54
was that not the notion before?

02:06:23
Are you willing to come into the office on Dec 24-26 just in case law enforcement will send a request, Mark? I am not

02:06:42
I am not even willing to guarantee I will stay somewhere where I have internet connectivityt

02:06:47
Thanks for reasonableness and understanding, y'all.

02:06:50
thanks!

02:06:53
Progress!

02:09:55
@Eleeza I was hoping to get rid of that ambiguity too :-)

02:10:23
:)

02:12:30
I'm not clear how reporting numbers of request vs denied would identify improper denials

02:12:30
Logging is fine

02:12:42
Wouldn't that be a situation where the requestor would follow the dispute process to address it?

02:13:19
Uh, not quite

02:13:24
that is an abuse point of contact

02:13:29
it's not the same as a disclosure decision

02:13:39
+1 Sarah

02:13:55
And the abuse contact is not necessarily able to make that decision, it's a very different work function

02:13:55
great point Alan!

02:14:00
Alan G

02:14:15
well I hardly thought you agreed with me Margie

02:14:28
:)

02:14:38
@Sarah, I didn't say it was identical, just noting its existance and there is some correspondance.

02:14:59
For the record, RAA 3.18.2

02:15:54
Totally get it, Beth.

02:16:34
Thanks, Brian. Just trying to make sure we are have a shared understanding so we can get where we need to go.

02:17:57
Rec 18 does include logging requirements ??

02:18:06
Logs of Requests, Acknowledgements and Responses should be maintained in accordance with standard business recordation practices so that they are available to be produced as needed including, but not limited to, for audit purposes by ICANN Compliance;

02:18:11
THat is from the "timeline' part of rec 18

02:18:21
Thanks, Sarah.

02:18:25
It's there in 18

02:18:40
Sarah save us all

02:18:47
I see it in 18

02:18:56
Logging is fine

02:18:59
Ahhh, thanks, Caitlin!

02:19:09
agree with deleting d from here

02:19:25
agree deleting d

02:20:03
Yes, that's a big question

02:20:08
(who the Controller is)

02:21:11
Ok

02:21:12
that's ok

02:21:16
I am Ok with that deletion

02:21:31
+1.

02:21:52
sorry! :D

02:24:04
Yup C, not B. :)

02:25:03
Chris, could F become the definition in the footnote to C?

02:25:21
yeah (I'm not Chris, but I think so)

02:25:53
think so…. (@beth)

02:26:28
need to lose the of

02:26:36
As long as Chris is happy with that I’m pretty happy too

02:27:14
+1 Brian

02:27:29
+1 Brian

02:28:43
Just noting that the language is slightly different. I want to make sure we capture it if it’s different but if it’s the same maybe we consolidate?

02:30:30
agree with Beth that it's also important to consider whether the "unless exceptional circumstances" applies here too (I think it probably shouldn't)

02:31:11
Ok that is really helpful. Thank you, Caitlin!

02:31:31
@Brian I'm not convinced that you have an urgent in the same sense as Public authorities. You say you have provided good reasoning. Could you point that out again. I do need to point out that we should NOT be treating private entities in the same manner we deal with those who retain an actual legal authority. If you could provide that clarity for the record.

02:31:31
Thanks, all

02:31:49
I think whatever Chris needs on this to feel it is clear. I just think it’s important that we are clear or it will be confusing to everyone else! :)

02:31:59
agreed beth

02:32:52
Thanks all

02:33:04
it is never good to be the turkey during this week :)

02:33:15
looking forward to it

02:34:44
Sorry, is the draft just coming to the team on Thursday?

02:34:44
thank you bye

02:34:52
Happy thanksgiving everyone!

02:34:53
And not to public comment until Dec?

02:34:59
thanks bye

02:35:02
Thanks all
Zoom would like to update your account settings. When joining a meeting or webinar by entering a meeting ID, participants will be required to enter a password. Participants joining using a meeting invite link will not be required to enter a password. Learn More
This change will be effective on . If approved or declined, the change will take effect immediately.