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

05:53:39
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

05:55:53
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.

05:59:27
No question that these are useful tools.

06:00:33
The unmentionables

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

06:04:21
Which one?

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

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

06:15:31
Thanks Alan. Why “keyed on”?

06:21:40
Automated cases are also evaluated on their own merits

06:28:47
queue please

06:36:12
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.

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

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

06:40:36
Bad actors using/abusing the system

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

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

06:41:33
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

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

06:42:38
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?

06:43:14
It always depends on the circumstances. And that is addressed in the proposed language on the screemn

06:51:29
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.

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

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

07:34:04
UDRP/URS seems a likely candidate for automation in SSAD.

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

07:34:53
+1 berry for automating UDRP/URS

07:35:08
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

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

07:35:49
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.

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

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

07:37:31
@matt if it is an automated response maybe yes

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

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

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

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

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

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

07:49:58
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.

07:50:04
It eliminates longer delays due to holiday + weekends.

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

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

07:54:41
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.

07:54:56
Typically in 3 to 6 month timeframe.

07:56:01
SLO = Service Level Objective

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

07:56:35
Berry, I was thinking the same thing!

07:56:37
In the beginning, there was nothing.

07:56:43
Can we start with athat?

07:56:45
Right on, Berry and Ben.

07:57:01
Then God said: "Let there be SLAs"

07:57:22
SLO=>A's

07:58:20
Deadlines lead to bad decisions

07:58:23
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?

07:58:33
Saying no is faster than saying yes

07:58:57
Which is a result we would like to avoid

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

07:59:37
maybe not exactly the same, but similar?

08:00:19
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

08:01:05
You'll have a recommendation from ICANN to help make the decision;

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

08:02:22
Good point, Berry. That would be helpful.

08:03:43
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

08:05:47
small registrars will authorize ICANN to to respond

08:05:53
automatically

08:06:02
Lol, Margie, good one

08:06:21
it's an option in the report

08:07:02
Just because they CAN doesn’t mean they will...

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

08:07:19
I doubt it will survive to publication

08:07:55
No, we have normal staff with a mobile phone

08:08:38
there's no reason to assume they won't

08:10:17
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

08:11:04
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

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

08:12:43
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.

08:13:04
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.

08:13:05
This is a new situation, so a new approach seems justified

08:17:20
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

08:17:21
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.

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

08:19:48
I try

08:20:45
How's about financial incentives for staying within the SLA for the CPs?

08:22:37
@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.

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

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

08:24:19
As for capacity? Depends on the day of the week

08:24:41
Holiday seasons and illnesses in the team

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

08:25:12
I would guess anything above 50 a week would start impacting response times for abuse tickets

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

08:25:56
The above is for amp registrars in the Centralnic group combined as the abuse function is centralized

08:26:18
amp=all

08:29:28
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.

08:30:04
With financial incentives for the CPs who meet SLA

09:52:58
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

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

09:54:20
and ICANN Compliance won't act in a meaningful way

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

10:00:45
So maybe it’s a footnote that says the SSAD defaults to the registrar

10:01:30
My hand is up

10:02:03
maybe James could write it up, he explained it well already

10:02:15
Queue please

10:03:05
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.

10:03:12
+1 Mark Sv

10:03:21
we point this out in our comments.

10:03:54
Clearly the registrar is the primary data controller because they have the relationship with the customer

10:05:29
Stephanie, this is also part of the reason for this proposal

10:05:47
Exactly, and I support this word change

10:18:05
We think could is a better word that =should.

10:18:43
Should has been defined as fairly coercive

10:24:24
@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

10:29:24
Hello, my name is Volker and I am a controller

10:29:40
Hi Volker!

10:31:56
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

10:32:07
This is pure implementation

10:32:32
We should have done the numbers the other way round

10:32:39
Totally agree with Thomas, this requirement is a shall

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

10:33:03
We noted it as an omission that needed to be fixed as well.

10:33:28
Log, log, it's big it's heavy it's wood

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

10:39:51
It’s better than bad, it’s good!

10:40:18
:-)

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

11:02:51
This should be in the preamble

11:03:14
separate section on publicly available data elements

11:03:24
I thought we had dealt with this in phase one?

11:03:40
@Stephanie, unfortunately no, we didn't

11:04:51
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?

11:05:34
Thanks for that clarification

11:07:39
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

11:07:43
cost

11:09:06
note that imho this language does not preclude what James is concerned about.

11:32:02
+1 Volker

11:32:25
Even if Volker was being cheeky, this sounds like implementation detail.

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

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

11:33:23
TWINSIES!

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

11:36:39
well i have certainly given up on truffles.....