Good morning!

Members - please change your chat to all panelist and attendees.

https://community.icann.org/display/EOTSFGRD/g.+Draft+Final+Report+-+Phase+2

Thanks, Caitlin. This should be helpful

Thank you Janis it is very important for the legal committee to meet in this regard

apologies for being late.

Their recourse would be ICANN Compliance.

+1 James.

+1 James

The recourse isn’t to go to the registry in that case IMO Alan

Alan’s scenario is classic venue-shopping

Due process………

anyone?

Shouldn’t they have to choose one or the other?

How would the registry operator know the same request had been routed to the registrar and denied?

I think folks here are making a strong case that Registrars should push all Registries to convert to "Thin"

There are implementation issues to be considered to make this work well.

And if a registry denies all requests they receive? Then they go back to the registrar?

Who is more important here … the data subject or the requester?

If ICANN Compliance will never question decision, then the whole system falls apart.

You can always go the to registry directly - but the registry should of course know if a proviso request has been made, denied etc.

*previous

+1 Alan

There is an if: "does not respond by the SLA" which means that the answer for the request is due. This is the reason to go to the Registry

@Volker: Right!! +1

Well that’s a very good point Volker…

Georgios - I think we can agree sensible safeguards in that sort of instance inbuilt and they do need to be defined.

The Policy Formerly Known as the Temp Spec

ICANN compliance provided input to this group that it WILL NOT review disclosure decisions

@James: Right. Apologies. :-)

@Laureen: :-)

The distinction James is making between denied requests vs not living up to SLA requirements makes sense to me.

can we clarify that we are talking about a registry agreeing to the same request for the same reason that the registrar has denied?

These are all matters that ought to be interrogated through the co-controller agreements. Which we are not talking about, for some reason.

@ James, I agree we c/n have a system that allows a routine 2nd bite. But we do need "safety mechanisms" to deal with registrars that d/n abide by the rules of SSAD.

We can hardly set policy in these circumstances

@Becky: My understanding is that this is exactly what we’re discussing, no?

who told you that, Alan?

@Becky, yes I think so.

(that compliance will never look over registrar compliance with policy?)

thanks @Amr, just wanted to be sure I’m on the same page

@Becky: Or perhaps not necessarily have a RO agree to a disclosure request a Registrar has denied, but rather as a form of recourse (just the option) in the event of the Registrar denying the request.

@ Amr -- James' proposal for "safety mechanisms" makes sense to me too.

in other words, a typical day, Janis!

lol

+1 Stephanie

Perhaps we can put some guardrails around scenarios where requestors can submit a request to a registry

(prefer joint controller" to "co-controller"

@Alan - compliance has to enforce Rr and Ry adherence to the policy. But they cannot overrule the Contracted Party’s determination of whether or not the request was legal. If they did, that’s a quick route to getting SSAD thrown out in court somewhere

We can't live with a blanket prohibition, but would consider guardrails.

@Laureen: Yeah…, I mean if the requestor has a legitimate reason to seek disclosure, and there is no legal reason to deny it, but the Registrar is just not complying with SLA requirements - in this scenario, makes sense for a recourse to be available. If the Registrar does comply with the SLA, but denies the disclosure request, it’s a different story.

correct, Stephanie it works both ways

It MUST always go to the registrar, unless ICANN is going to take ownership of the controllership.

@AlanW: +1

And forum shopping to the registry brings up a point that James made in the chat a while ago. Thin registries must be the rule, unless a case can be made under the GDPR for the data sharing. I cannot see the argument.

Agree - let's work on the safeguards!

@AlanW agree, let's work together on this

I didn’t think we were discussing automated responses right now. If we were, wouldn’t the disclosure requests not be subject to refusal by the Registrar, in the first place?

Completely agree, Hadia. That's the important distinction.

Also not clear on what decision by the Central Gateway is referring to?

@Volker we are talking if the decision is not made by the CP, do CPs still need to receive the entire information (We are trying to think about what is best for the CPs )

Really depends on the Joint controller agreement Hadia

Bear in mind that compromises we make to achieve some sort of concensus here may make very little to no sense under data protection law. The co-controller agreements will have to spell out the liability here.

@Milton: +1

If the algorithm learns from bad decision, it’s likely to make bad (or worse) ones itself.

that recommendation MarcSV will be based on billions of transaction data

@Amr you are assuming that the only input to the system is the decision which is not the case

and ground truth about which transactions went bad. which we don’t have yet

@Hadia: I’m not making that assumption at all. :-)

when using machine learning the input to the system is not only the decisions, the decisions made are necessary but other inputs are sure required

Also note that we're not requiring the CGM to make a recommendation, just that it MAY. From there, we're not even requiring CPs to follow the recommendation.

Great point, Marc. Lots to consider.

I also hope it's automated. SLA and cost benefit as MarcA says. But both humans and machines can perform an algorithm, of course

@Marc: +1

@Milton, NO. The Rec says the SSAD *MAY* do this, not that it will do it from the start.

@Milton: +1000

Yes +1000 Milton

+1 Brian The recommendation says "May" so when the central gateway manager can make a recommendation it will go ahead and do so.

Rec c) the central gateway manager MAY be stupid

sounds like some of what people are saying now should make it's way into implementation notes

+1 MarcA

@staff - Janis' summary just now sounds like a good implementation note.

+1 Marc A to adding notes to the implementation part

We addressed the “no answer” issue with the SLA, no?

As in a previous topic - let's focus on the safeguards

@Matt: +1

@Matt I think this is different

I would just like to note for the record that it is not within a DPA’s mandate to investigate an entity’s failure to collect personal data. They are busy, forget the thought of a requestor complaining to them.

+1 Stephanie -- recourse from DPA highly unlikely.

@Milton: +1

I hope ICANN Compliance will step up to the task!

@Janis: +1

(but hope is not a plan so we ask for an appeals mechanism, thanks)

If every denial is appealed, the bulk-appealer should lose accred

How existing legal process could be considered a ‘backstop’ is sort of the problem here though.

No

cost-benefit ration is completely out of whack here

@Brian: Sounds like you just said that you’re seeking protections for TM holders via ICANN policies, which are not granted by law. ;-)

+1 Janis

"The non-refundable amount for the administrationof proceedings pursuant to the New gTLD DisputeResolution Procedure is 5,000 Euro."

seriously, Brian, how can you ask for appeal rights for requestors but not for data subjects?

@Brian: Or is it that you’re seeking TM protections via ICANN policies, BECAUSE they’re not granted by law?!

Maybe a flagging mechanism where requestors or data subjects who think a specific registrar is not following law as Laureen suggests

+1 Lauren

@Stephanie: +1

@Stephanie Lauren suggestion covers both sides

+1 Stephanie

An appeal cannot compel disclosure. But it can give input to ICANN compliance to take action against CP.

Review of compliance with policy is what it is

right, good Janis.

patterns

right Steph

Not an appeals mechanism. If a registrar were to routinely fail to comply with legitimate requests, it raises questions of compliance with registration policy and security and stability of the DNS, at a meta level

Agreed Janis

right, same issue as the one we just discussed

Agreed Janis

Ole hand

sorry

@Chris: +1

Yay we all agree

@Brian: Agree. Do you think that is already covered in the phase 1 recommendation on ICANN’s Compliance purpose?

I think so

I do too.

Plenty broad enough, and not to be a broken record or anything, but the role of the Compliance group will be spelled out in the co-controller agreement

With access to data spelled out sepcifically

specifically

Thanks for the save, Marc.

Agree that the CGM doing this seems more sensible. Will likely provide more uniform and complete information as well.

I think we do need to be realistic here also …. teh central gateway is not some omnipresent oracle either - so we should ensure the policy is not creating an impossible task

Volker do you do that even if the data on the website isn't the same as the data you have? asking because website data isn't authoritative

Margie made my points. Hand going down.

something like "request MUST return a link to the RDS service where the Minimum Public Data Set can be obtained" could work

@Stephanie: Good point!!

right, Steph. this rec has it kind f backwards.

Thanks Stephanie, that's what we're envisioning too.

I don't object to that Brian, I'd rather have that up front at the central gateway though, because in theory, the requestor should be checking the public data first. Including it in the response for non-public data seems out of order.

@Marc, agreed, especially requestors have to pay for SSAD requests and not public RDS data

@Brian: +1

Staff, Volker and I can continue our conversation

i volunteer Volker!

Thx all.

Thanks all. Bye.

Thank you all bye

thanks everyone

thanks all

thanks all