
35:11
Good morning!

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

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

38:29
Thanks, Caitlin. This should be helpful

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

42:22
apologies for being late.

45:38
Their recourse would be ICANN Compliance.

45:43
+1 James.

45:43
+1 James

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

46:33
Alan’s scenario is classic venue-shopping

46:43
Due process………

46:47
anyone?

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

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

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

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

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

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

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

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

51:15
*previous

51:18
+1 Alan

51:43
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

52:16
@Volker: Right!! +1

53:01
Well that’s a very good point Volker…

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

54:51
The Policy Formerly Known as the Temp Spec

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

57:08
@James: Right. Apologies. :-)

57:44
@Laureen: :-)

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

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

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

59:53
@ 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.

01:00:01
We can hardly set policy in these circumstances

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

01:00:26
who told you that, Alan?

01:00:44
@Becky, yes I think so.

01:00:47
(that compliance will never look over registrar compliance with policy?)

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

01:01:12
@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.

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

01:01:44
in other words, a typical day, Janis!

01:01:56
lol

01:02:04
+1 Stephanie

01:02:17
Perhaps we can put some guardrails around scenarios where requestors can submit a request to a registry

01:02:21
(prefer joint controller" to "co-controller"

01:02:41
@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

01:02:50
We can't live with a blanket prohibition, but would consider guardrails.

01:03:01
@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.

01:03:18
correct, Stephanie it works both ways

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

01:07:23
@AlanW: +1

01:07:44
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.

01:07:52
Agree - let's work on the safeguards!

01:07:59
@AlanW agree, let's work together on this

01:12:53
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?

01:12:57
Completely agree, Hadia. That's the important distinction.

01:13:24
Also not clear on what decision by the Central Gateway is referring to?

01:20:58
@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 )

01:21:29
Really depends on the Joint controller agreement Hadia

01:29:03
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.

01:29:54
@Milton: +1

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

01:33:50
that recommendation MarcSV will be based on billions of transaction data

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

01:34:11
and ground truth about which transactions went bad. which we don’t have yet

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

01:35:42
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

01:36:15
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.

01:38:18
Great point, Marc. Lots to consider.

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

01:38:37
@Marc: +1

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

01:41:11
@Milton: +1000

01:41:30
Yes +1000 Milton

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

01:45:51
Rec c) the central gateway manager MAY be stupid

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

01:46:49
+1 MarcA

01:47:25
@staff - Janis' summary just now sounds like a good implementation note.

01:48:07
+1 Marc A to adding notes to the implementation part

01:52:02
We addressed the “no answer” issue with the SLA, no?

01:52:16
As in a previous topic - let's focus on the safeguards

01:52:21
@Matt: +1

01:52:37
@Matt I think this is different

01:52:53
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.

01:53:47
+1 Stephanie -- recourse from DPA highly unlikely.

01:55:10
@Milton: +1

01:55:37
I hope ICANN Compliance will step up to the task!

01:55:49
@Janis: +1

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

01:56:38
If every denial is appealed, the bulk-appealer should lose accred

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

01:59:45
No

02:00:05
cost-benefit ration is completely out of whack here

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

02:00:10
+1 Janis

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

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

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

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

02:03:17
+1 Lauren

02:04:44
@Stephanie: +1

02:04:56
@Stephanie Lauren suggestion covers both sides

02:05:07
+1 Stephanie

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

02:06:58
Review of compliance with policy is what it is

02:07:10
right, good Janis.

02:07:14
patterns

02:07:23
right Steph

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

02:08:01
Agreed Janis

02:08:05
right, same issue as the one we just discussed

02:08:07
Agreed Janis

02:08:08
Ole hand

02:08:11
sorry

02:08:24
@Chris: +1

02:09:42
Yay we all agree

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

02:10:06
I think so

02:10:10
I do too.

02:10:51
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

02:11:19
With access to data spelled out sepcifically

02:11:26
specifically

02:14:16
Thanks for the save, Marc.

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

02:18:07
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

02:20:30
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

02:21:08
Margie made my points. Hand going down.

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

02:24:20
@Stephanie: Good point!!

02:24:39
right, Steph. this rec has it kind f backwards.

02:24:40
Thanks Stephanie, that's what we're envisioning too.

02:25:05
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.

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

02:28:15
@Brian: +1

02:29:45
Staff, Volker and I can continue our conversation

02:30:03
i volunteer Volker!

02:30:09
Thx all.

02:31:00
Thanks all. Bye.

02:31:04
Thank you all bye

02:31:07
thanks everyone

02:31:10
thanks all

02:31:17
thanks all