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

Members: please select all panelists and attendees in order for everyone to see chat

point of order: our rep remembers no such agreement

https://docs.google.com/document/d/17gGzz6K-zKuSK71FluHCowZo3p6tFEd3/edit

I don’t recall any group supporting the proposal at this time…, registrars, or otherwise.

The NCSG may end up not accepting it. :-)

Small team calls are only recorded, no transcripts.

+ 1 Volker -- participating in ICANN68 and the EPDP mtgs is challenging.

I would have to agree. The NCSG meeting runs from (my time, EDT) 3 am to 5:30 am, so having a 10 am meeting on top of a full 8 hour shift all night is a bit much

And the same thing is happening with RPMs.

However, there is a zoom transcript provided, but as you know it can be a little choppy.

that is a relief

Brian we can't hear you

Thanks for that clarification Berry. Problem is we don’t even have time to listen at the moment, still catching up on ICANN Meeting conflicts….

good now

Can hear you now, Brian.

Thnx, Brian.

Yes, kudos to Amr for his very thoughtful approach to try and move the ball forward. That said, we're not at the finish line and yet. . .

+1 Laureen and Brian thank you Amr for putting this forward

And as a reminder, this should say 1 business day, not 24 hours.

as Volker said :-)

I do not recall agreeing to change to business day

link to yellow items doc: https://docs.google.com/document/d/1gSdkEf4EyBM7z3YXAzGjTb-AULxOrDeC/edit

@Mark - the 24 hours was part of the original staff support team proposal to limit urgent requests to LEA in return for a 24 hour response time. As limiting to LEA was not accepted, we also reverted back to the 1 business day.

Again, I do not recall that business days was tied to non-LEA

No

yes we can

For urgent LEA requests, there is always the RRSG emergency contact.

Thomas that's for abuse though, not necessarily disclosure.

Probably connected in most cases, but not necessarily.

Struggling to think of a LEA issue that wouldn’t involve abuse.

or at least alleged abuse/criminal activity

Well, if it is such an urgent case, I trust it is in connection with abuse.

+1 Thomas

Not trying to be difficult, just saying there are alternative routes to the data.

IF all Prio 1 requests are abuse, then the REAL limit is 24 hours and why are CP forcing this issue?

Frankly, if you are not going to accept that business days usually means not on weekends, then just go with 24 hours.

Right, Thomas, but not all abuse is "DNS Abuse" right?

That is correct, Brian.

I recall it from phase 1

And I must say this shaving of the gist of the compromise right off, makes me lose trust in the stability of the document

Also as a reminder: “Violations of the use of Urgent SSAD Requests will result in a response from the Central Gateway Manager to ensure that the requirements for Urgent SSAD Requests are known and met in the first instance, but repeated violations may result in the Central Gateway Manager suspending the ability to make urgent requests via the SSAD.”

Alan - that requirement is for Law Enforcmenet.

You’re mixing two different categories of abuse.

And to actually address abuse…not review disclosure requests for data

1 business day…not to exceed 3 calendar days seemed like a good proposal from Janis

The issue is that Registrars should not be required to make staff working on the disclosure requests work 24/7 if I understand correctly.

I think the point was that registrars already have an obligation to be staffed 24/7 (for a different purpose, I concede), but I think we'd be ok with the compromise.

Different teams & personnel. And presumably different volume of requests (LEA requests are rare and urgent)

Should be not to exceed 2 calendar days IMO

We started with 5, now down to 3.

3 seems to catch those long weekends so I’d support that

Correct @Chris: “b. Contracted Parties MUST maintain a dedicated contact for dealing with Urgent SSAD Requests which can be stored and used by the Central Gateway Manager, in circumstances where an SSAD request has been flagged as Urgent. “

We started with 5000 milliseconds ;-)

Sorry, couldn't help it

+Brian LOL

shall we move it back to 5, Brian?

Now, now Volker.

me=grumpy

You are not alone. . .

5 seconds is exactly what we'd prefer, Volker. Ha, me too. I forgive you. This schedule is nuts.

Thanks for constructive conversation and compromise.

The blue text is basically addressed in a paragraph that is further up so it is a duplication.

Twice!

It was Org

agree, this doesn't belong in SLAs anymore and should go to the new priority one.

My recollection is that ICANN:CP negotiations happen periodically and not often.

1.2.2. functional and performance specifications for the provision of Registrar Services;

Is SSAD a “Registar Service”?

WHOIS is in the picket fence and this is part of the WHOIS

I was so excited to hear Becky solve this for us

Given that Registrations have been occurring for several years absent SSAD, it doesn’t appear to be a necessary element

Yes - put it in the policy

I thought negotiations were for later change! Not the current numbers.

@Alan, that's also my understanding

As I said, existing processes may be within 10 years...

it must be clear that these SLA numbers cannot be watered down by contract negotiations. they are set by consensus policy

Unfortunately, and inexplicably, I lost my zoom connection after I spoke. I did not hear any response, although I note that someone has brought up the issue of the famous picket fence.

So if some kind soul will tell me whether there was any response to the issue of affordability of this SSAD and the attendant SLAs, that would be very kind.

@Volker: +1. Shouldn’t policy recommendations be focused on what’s in the contracts, not the SLAs?

Are there other policies that contain SLA’s?

@Matt - I believe UDRP Lock had a response time in policy recs?

transfer policy

UDRP

Yeah transfer policy was the one that came to my mind…not sure it’s what folks think of when they think of a SLA however

I presume that whatever Consensus Policy is adopted post review of the TMCH/Sunrise/Claims, an SLA might be involved, just not necessarily with CPs.

Sorry, it's ICANN. We need acronyms.

No more acronyms ;-)!

Ts&Cs updated by ICANN unilaterally?

@ Laureen …Or as we like to say - NMA!

:-)

So the means that all of those detailed responsibilities will be sorted out in the contract?

Sure, they are joint controllers, but there remains a huge ambit here in accountability, and that is not a simple matter to be determined inside the picket fence

If SSAD = Central gateway manager it should read: "Contracted parties and SSAD central gateway manager" for clarity

Lost everybody, is there sound or is it just me?

sound still works for me @Stephanie

Maybe we can revert but applying normative language?

what if can = changed to MAY (in the original version)?

Sorry am tired missed read the change

"Confidential requests can be disclosed to data subjects in cooperation with the requesting entity, but MUST NOT do so without cooperation from the requesting authority, in accordance with the data subject's rights under applicable law."

Stephanie needs to be promoted to a “panelist”.

It's still slightly different meaning - can it be accepted?

I don’t think so, Janis.

no, that has the same problem

@Janis: Yes. That’d work.

Actually…, I’m not sure that’d work either.

No objection to replacing "can" with "MAY" if GAC is OK with it

I actually am an expert here. So I do object to all the Musts in the latter half of the sentence, and a weak may in the front half

@Stephanie - reverting back to the original language means there are no MUSTs

The proposal is to change can to MAY

Makes it better, the compromise we choked down originally

@MarcA, I assumed that "in cooperation" was more significant than "if they simply inform", but again I defer to GAC

Note that this language did not change, only the redline - the green language just notes that it was moved from somewhere else.

Correct, Janis, it just got moved up.

IMHO Confidentiality requests (except those who are grounded in the specific applicable legal obligation, specifically claimed, unless they are directly applicable, made within a specific jurisdiction by a relevant party) are simply not absolute. We cannot change that.

For the record, this was the language included in the Initial Report: “Confidential requests can be disclosed to data subjects in cooperation with the requesting authority, [and] [or] in accordance with the data subject’s rights under applicable law”.

@Chris: That sounds great. If that’s what we’re talking about, then works for me.

Since we have a lot more serious legal advice since phase 1, I expect that there are quite a few bits in there that will be found to be in contradiction to other agreed text

To split hairs … it's not the CPs data .. it's the registrant's - but that is a significant delineation. We are not dealing with something we own, we are custodians of data owned by someone else. I think we could be getting through these things far quicker if we all appreciated this basic fact.

It seems to me that the requesting entity should be at least notified that the request is no longer confidential.

@AlanW: +1

@Brian: That sounds fair.

The SSAD must inform all users and the RNHs whose data is going to be revealed, the terms and conditions of disclosure both to third parties and to the RNHs who have rights UNDER THIS POLICY, not just under local law.

I believe that Bird and Bird have outlined some of those openness provisions in recent memos

No objections

Suggest ALAC take #61 to the list for discussion?

Note that this recommendation says ‘the CGM makes a determination’

OK. Thanks Marika.

The metaphor is that if you don’t deal with the few bad apples, they will spoil the barrel. Sorry to be picky, but this is being misapplied a lot lately w.r.t. police misconduct.

the original language is good

Yup. Original language fine.

did i lose sound?

I can hear fine.

We still hear, Volker

Companies can differentiate themselves through their transparency reports

Yes, this change would be a result of the public comment review.

Need to run to another call…thanks all

Or better said - addition

Time check….need to drop in 1 min

Ah, I see the distinction, Dan.

Need to drop. Thanks all.

They certainly have no right to see the PI of other RNHs, regardless if they want to verify their own compliance track record

Let's not call it "the data" - it's activity statistics. We'll just confuse people if we call it "the data"

We are not okay to park it either

it seems like we are just over engineering what we can see in our 'accounts' in the SSAD (tangible - not concept)

For very different reasons.

Thanks all. Bye.

Thank you all bye