me too

Yes, I am letting her know

yuo

Thanks Andrea

yup

Hope it is only her

Yes, I believe it is her line

Better now

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

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

Janis hard to hear. Just me?

I think just you, Alan G

very distant for me too

nope. He is very distant.

215-858-2257 is Greg

Thank you, Greg

ouch

Folks the audio is cutting in and out pretty aggressively.

Is today the berlin meeting day?

Yes, Chris. IGF.

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

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

I asked Angela for asylum in Germany and she said Yes

as long as Microsoft builds the system and maintains it!

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

:-)

unmute my phone please

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

+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

This is proposed language from the CPH team

building block N starts further down …..

thank you Caitlin! :)

apologies for being late

Whatever is best for the team, sure

This was intended to replace most of what is there already

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

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

yes- sorry I wasn't clear

Thanks for clarifying

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

yes - Alan G - I was referring to that development

ICANN accredits accreditors

so ICANN would accredit WIPO as an example

I thought we said ICANN was the accreditation provider??

No, there will not be accreditation of accreditors

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

principals

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

I thought there is a web interface?

Yes, +1 Beth!

we could just put general principals if everyone agrees

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.

+1 Thomas

The CPH proposal takes us to principles instead of specifics, may be helpful.

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

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.

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

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

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

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

+1 Sarah

Maybe even split between private requestors’ requests and LEA requests.

+1 Sarah

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

+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??

Sounds good Janis, thank you.

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

Date more requests

+1 Beth

+1

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

+1 mark

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

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

+1 Alan

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

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

Having an incomplete requ

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

Sorry I keep hitting ‘return’ mid comment!

Thank you, Caitlin! Super helpful

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

agreed

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

and/or ?

Only if Mark's amendment does not equal a new request

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

for cost purposes

really like Sarah's suggestion

So this is assuming an automated system

which is probably okay?

This is a good point, Beth

Brian that is helpful. We should be more clear about that in the text please.

If it is an incomplete request is submitted it certainly does not pass to the decision maker

such faith in automation

The decision maker only looks into full and complete requests

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

Yes, once the SSAD passes the singularity we can refer to it that way

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.

Sure Brian that makes sense

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)

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

exactly what Greg is saying... lol

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

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

+1 Greg

@Greg but this will only happen during the determination phase

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.

Mal-formed not misinformed …

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.

+100 Beth

There are still many unknowns that have real significant effects on our decisions

True dat Beth + Sarah

Change it to business days and it is still a tough timeline to beat

This is specifically for not automated responses, Margie

‘When we get to it’ is still the best I can offer

This is specific to requests that cannot be responded to automatically

We truly need to be realistic here, as our risks are very real

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

if nothing else, the data must be provided to the SSAD

so there is involvement

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

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

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

…should endeavour to be returned within [timelines to be determined]…

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

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

Placeholders should not look like maximum demands

Good question, Beth

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

So the RDAP SLAs cannot even remotely be compared

Tough timelines make for sloppy reviews

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

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

Yes

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

@Sarah, I suppose that's what I don't understand.

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

@Sarah, I also don't understand

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

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

is that what the legal advices says is the actual reality of the situation is Brian.

@Alan yes, of one particular set of facts.

ICANN has proposed a different set of facts to the DPAs for opinion

Yes Mark, but we must always base our estimations on the weakest link

........ 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

+1 Alan

+1 Beth

@Beth currently there is one particular idea that we all hope it works

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

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

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

Ok with "should"

not sure what "preferably" does for us

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

I assumed we're using those IETF-defined terms, yes?

@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.

@Beth I'll look for that language

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

Why recreate the wheel?

Rec. 18 was meant for the manual requests - not the SSAD

I wish, MakSV, I wish

MarkSV

could we ask ICANN compliance if they would enforce that language?

:-)

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

Lost Janis sound?

lost audio

Did Janis drop?

we are checking into this

Yes, thanks

ye

yes

yes and much clearer now

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

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

we lost you again

the problem is that there are 7 of us in a room with a polycom

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.

It is the same SLA, just different timeframes

So *everyone* is allowed to provide SLAs crafted to support the most poorly staffed entities

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

Business days btw also is a legal term

It just means no week-ends, no holidays

+1 Volker

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

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

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

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

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

I think that's fair, Beth.

+1 for that for me.

was that not the notion before?

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

I am not even willing to guarantee I will stay somewhere where I have internet connectivityt

Thanks for reasonableness and understanding, y'all.

thanks!

Progress!

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

:)

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

Logging is fine

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

Uh, not quite

that is an abuse point of contact

it's not the same as a disclosure decision

+1 Sarah

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

great point Alan!

Alan G

well I hardly thought you agreed with me Margie

:)

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

For the record, RAA 3.18.2

Totally get it, Beth.

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

Rec 18 does include logging requirements ??

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;

THat is from the "timeline' part of rec 18

Thanks, Sarah.

It's there in 18

Sarah save us all

I see it in 18

Logging is fine

Ahhh, thanks, Caitlin!

agree with deleting d from here

agree deleting d

Yes, that's a big question

(who the Controller is)

Ok

that's ok

I am Ok with that deletion

+1.

sorry! :D

Yup C, not B. :)

Chris, could F become the definition in the footnote to C?

yeah (I'm not Chris, but I think so)

think so…. (@beth)

need to lose the of

As long as Chris is happy with that I’m pretty happy too

+1 Brian

+1 Brian

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?

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

Ok that is really helpful. Thank you, Caitlin!

@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.

Thanks, all

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! :)

agreed beth

Thanks all

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

looking forward to it

Sorry, is the draft just coming to the team on Thursday?

thank you bye

Happy thanksgiving everyone!

And not to public comment until Dec?

thanks bye

Thanks all