Hopefully we could come up with recommendations for the Natural vs Legal issue before the June deadline

I don’t think we would be comfortable with any kind of standing committee to address this as it clearly would be a policy item and not simply implementation

Agreed Matt. I also continue to be uncomfortable with this concept of "may be useful". This is not a good basis for policy and I certainly of more concern, when talking about use of data, is specifically not a valid reason to process data.

No question that these are useful tools.

The unmentionables

The wording is simple. The first sentence makes it clear that SSAD requests aremade based on a domain name (no wildcards). Period.

Which one?

The first bullet. No need to even mention bulk access is the only search term is a fully qualified domain name.

First bullet: receive requests keyed on fully qualified domain names (without wildcards).

Thanks Alan. Why “keyed on”?

Automated cases are also evaluated on their own merits

queue please

We (Rr) are not indemnifying any user of SSAD. If there are risks associated with fulfilling a given request or dealing with an abusive requestor, It is easier to categorically reject these requests.

If there are issues with compliance to policies, compliance is the correct venue. If this language stays, this work is dead

I apologise if I’m just being thick but what is this indemnity supposed to cover?

Bad actors using/abusing the system

But lets not forget the logging and monitoring for abuse too, including audits. So, it seems likely that bad actors will be found out.

And a bad actor would be someone claiming to be entitled to the data who in fact is not?

If their misrepresenting requests cause us to be fined for breach of the GDPR or similar laws, we will not accept being left holding the short end of the stick

If we have no basis to file claim against such bad requestors who cause us damages, we need not proceed here

but, with respect, you would fined NOT for them lying but for you not performing the checks, no? And if you perform the checks and they pass because they are good liars how would you be liable?

It always depends on the circumstances. And that is addressed in the proposed language on the screemn

It is very easy really: If one does not accept to indemnify the disclosing party, one does not accept the terms of using the SSAD.

We were willing to allow a carve-out for LEAs and similar, but that is it

idemnification is not an implementation issue: it's allocation of risks between parties

UDRP/URS seems a likely candidate for automation in SSAD.

As the providers could become accredited. We’re only talking roughly 4000 requests per year.

+1 berry for automating UDRP/URS

If we are moving these functions to SSAD, then I’m good. I’m ok with the performance targets for the others. I don’t think the LEA folks want their court orders going thru SSAD

It could also be possible to see a trend increase in the numbers of filings over the years too.

Er, put another way: I don’t think we can respond to a court order with “Um..you need to send this via SSAD.” Judges might not see the humor in that.

to the point James made, there already is a process for UDRP providers to get this data

Do we know that UDRP providers would want to change their process to use the SSAD as opposed to what they do today

@matt if it is an automated response maybe yes

For Priority 3 requests, some criteria could also be created, where the SLA clock is paused, but restarted after set time.

oh, also "business days" can vary greatly depending on jurisdiction. May be better to use calendar days.

I think if it’s calendar days, we’d want to increase the number of days

@Matt, I do not find that surprising :-)

If we move “business days” to “calendar days” we’d need to add 2-3 days.

Adding 2-3 days is equivalent to business days again, so that doesn't help

Remember, these requests are guaranteed to be syntactically consistent, complete, and correct, and submitted by an accredited requestor. I'm not arguing for a specific SLA, but I note that these should not take as long to process as some of us might think.

It eliminates longer delays due to holiday + weekends.

@Brian - the trick is that going with “calendar days” means that small CPs will have to staff 24/7

I’m trying to craft a performance target that accounts for holidays and weekends (e.g. Business Days)

Another option is “burn-in time”. In past services I’ve implemented, we contractually started with SLOs until actual system performance was understood. The SLOs then change to SLAs.

Typically in 3 to 6 month timeframe.

SLO = Service Level Objective

I like that concept Barry. I struggle with setting numeric SLAs on a system with so many unknowns

Berry, I was thinking the same thing!

In the beginning, there was nothing.

Can we start with athat?

Right on, Berry and Ben.

Then God said: "Let there be SLAs"

SLO=>A's

Deadlines lead to bad decisions

So in this scenario how would we create the SLA guidelines after the 6 month period? Would this group need to reconvene to do so?

Saying no is faster than saying yes

Which is a result we would like to avoid

@Volker - I think it takes just as long to say no as yes, if a real balancing review is performed

maybe not exactly the same, but similar?

Correct, but if there is an SLA to be met, the quality of these balancing tests would suffer, leading to a higher likelihood to refuse

You'll have a recommendation from ICANN to help make the decision;

Cps have mentioned size as an issue. Can we also create a matrix based on tiers based on DUMs?

Good point, Berry. That would be helpful.

I think using something like DUMs gets really challenging to track and while I understand the spirit of doing that, not sure we should go down that path

small registrars will authorize ICANN to to respond

automatically

Lol, Margie, good one

it's an option in the report

Just because they CAN doesn’t mean they will...

All registrars already have to staff 24/7 for abuse complaints anyway, FWIW.

I doubt it will survive to publication

No, we have normal staff with a mobile phone

there's no reason to assume they won't

Also... speaking in a personal capacity, abuse folks are not always / necessarily the best people to be doing a data privacy balancing tests. I've run teams of really eager people who are good at finding malware and spam and shutting it down, but they do not tend towards ensuring privacy rights

I cannot see how automating everything can be legal just because a registrar is smaller. It will just result in a veto on the GNSO level. Let’s not keep language in there that will result in a block

Good point, Ben. All the more reason to make ICANN do it.

We’ve never “sized” a policy for DUMs or something. I imagine Google and Facebook might have more capabilities than GoDaddy, despite having fewer names under management? And it could be argued that this creates barriers to entry / competition.

I'm not sold that ICANN 'can' do it in a way that would make the privacy attorneys back at the office comfortable... but I will leave that discussion for them.

This is a new situation, so a new approach seems justified

to the point Chris just made, this is the IRT language which could also be useful for this to allow for situations that require more time

For an Urgent Reasonable Request for Lawful Disclosure, Registrars and Registry Operators MUST acknowledge and respond without undue delay, but within (1) one business day from receipt. If responding to a request is complex or a large number of requests are received, Registrars or Registry Operators MAY extend the time for response up to an additional two (2) business days provided Registrars or Registry Operators provide notice to the requestor within the initial (1) one business day period and explain the need for an extension of time.

Credit to Volker - it wasn’t the best joke, but humor from a German is priceless! 😛

I try

How's about financial incentives for staying within the SLA for the CPs?

@Alan W - I'm interested. I guess it could get weird considering Volker's point that it's easier to deny quickly. Don't want to incentivize denying quickly to get the financial incentive. But let's consider it.

good point Brian - of course speed is not the only measure - needs to be worked on of course

Currently we are dealing with an average of 4 disclosure requests a day, so about 20 a week.

As for capacity? Depends on the day of the week

Holiday seasons and illnesses in the team

The 2013 RAA called for Compliance to honor a 12 month “Consultation” or “Transition” period

I would guess anything above 50 a week would start impacting response times for abuse tickets

“Transition Addendum”. We flagged all the things they wouldn’t enforce for 12 months.

The above is for amp registrars in the Centralnic group combined as the abuse function is centralized

amp=all

We could ask Compliance initially only to focus on the CPs in the bottom 1/2 or 2/3 of CPs that are not meeting SLA. This would both: a) incentivize CPs to do better than their peers, and b) exonerate the CPs that are close to meeting SLAs in the early days.

With financial incentives for the CPs who meet SLA

Please can we stop using the “non-responsive” registrar as an issue as we have worked to address that with the SLA language we’ve included here

The SLAs have delayed enforcement- 6 mo - so that would mean NO data for 6 months

and ICANN Compliance won't act in a meaningful way

Do we need to discuss this? If a request reaches the SSAD, the request will be directed to the RR anyway.

So maybe it’s a footnote that says the SSAD defaults to the registrar

My hand is up

maybe James could write it up, he explained it well already

Queue please

In the absence of having an opportunity to speak, may I point out that this is an instance of the text which is unclear because we have not established who is the controller and who is the processor.

+1 Mark Sv

we point this out in our comments.

Clearly the registrar is the primary data controller because they have the relationship with the customer

Stephanie, this is also part of the reason for this proposal

Exactly, and I support this word change

We think could is a better word that =should.

Should has been defined as fairly coercive

@Alan W It's not up to the "controler's free will" Controlership is an obligation steming from the responsbility of definining the processing purposes

Hello, my name is Volker and I am a controller

Hi Volker!

That is tiredness talking. If the controller is permitting automated disclosure, that is the controllers call. This needs to be clear in the Policy. If we are bring told that the SSAD must disclose the data in an automatic manner - without the assent of the rry or Rr as (one presumes joint controllers) then that changes an awful lot. All comes back to agreeing what party is what really

This is pure implementation

We should have done the numbers the other way round

Totally agree with Thomas, this requirement is a shall

“b) Logs will include a record of all queries and all items necessary to audit any decisions made in the context of SSAD.”

We noted it as an omission that needed to be fixed as well.

Log, log, it's big it's heavy it's wood

https://vignette.wikia.nocookie.net/twinpeaks/images/4/4f/Shot0003.png/revision/latest?cb=20140210120651

It’s better than bad, it’s good!

:-)

This is down in the weeds of implementation, considering we do not even know how we are going to build this thing

This should be in the preamble

separate section on publicly available data elements

I thought we had dealt with this in phase one?

@Stephanie, unfortunately no, we didn't

Publicly available data elements (minimum data set is covered) but I think we are taking here about non-personal data that is not publicly available?

Thanks for that clarification

What you have to be careful of here is getting down into data that requires a deliberation on the part of the registrar. That becomes a response/liability burden on the registrars….which impacts feasibility and csot

cost

note that imho this language does not preclude what James is concerned about.

+1 Volker

Even if Volker was being cheeky, this sounds like implementation detail.

the concept as Volker describes it is what I had in mind how this would work…part of the registrar profile basically.

Registrar publishes some sort of profile, listing the “applicable” jurisdictions. I think that’s what Volker was proposing

TWINSIES!

Roots of the weeds = “There’s a turnip down here somewhere!”

well i have certainly given up on truffles.....