Logo

Julie Bisland's Personal Meeting Room - Shared screen with speaker view
Amr Elsadr (NCSG)
47:12
I see Becky in the Zoom room.
Janis Karklins (Chair)
49:54
sorry, Team. technical problem at the airport. listening in
Berry Cobb
51:04
https://docs.google.com/document/d/1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4/edit
stephanieperrin
52:03
apologies for joining late
Amr Elsadr (NCSG)
52:41
Using “DPA” interchangeably between DP Agreements and Authorities can sometimes be confusing. Just sayin’.
Sarah Wyld (RrSG)
54:04
Agreed, Amr
Rafik Dammak (GNSO Council Liaison)
54:32
@amr point taken
Sarah Wyld (RrSG)
55:10
And the doc lower down does refer to "Disclosure agreements"
Sarah Wyld (RrSG)
55:19
maybe the intro is wrong and the DPA is a separate thing, not part of this doc?
Sarah Wyld (RrSG)
55:23
that sounded correct, what Marc just said
Alan Woods (RYSG)
55:28
agreed
Matt Serlin (RrSG)
55:44
+1 Marc…I had that same thought on the disclosure agreement
Sarah Wyld (RrSG)
56:40
So should we change the intro?
Alan Woods (RYSG)
57:41
+! Sarah
Amr Elsadr (NCSG)
57:43
@Sarah: +1
Alan Woods (RYSG)
57:47
or +1 even
Georgios Tselentis (GAC)
59:14
Apologies for being late. I will also need to leave earlier the call.
Laureen Kapin (GAC)
59:45
Perhaps we should get a chance to review first before its closed?
Berry Cobb
59:47
In Janis terms, "stable" for import into report.
Berry Cobb
01:01:33
https://docs.google.com/document/d/1KCzlakWVkt6GN5ZPl0my45WdR34JPes_bZwmJkY9Z3k/edit
Amr Elsadr (NCSG)
01:02:14
Sorry. Which comment?
Rafik Dammak (GNSO Council Liaison)
01:02:26
@amr the first comment
Amr Elsadr (NCSG)
01:02:31
Thanks.
Caitlin Tubergen
01:02:32
NCSG comment: This language is really objectionable. At worst, you want to say "may" be automated, it is not a consensus policy ever, that it "must" be automated. Suggest rewording to:"The EPDP Team recommends that those aspects of the SSAD identified below may be automated where both technically feasible and legally permissible."
Brian King (IPC)
01:02:51
Thanks, Caitlin!
Stephanie Perrin (NCSG)
01:04:38
some where in there the cost issue ought to be included. I understand it might be construed under “technically feasible” but I would sooner insert a comma, and include “cost effective”, and etc.
Sarah Wyld (RrSG)
01:04:59
I think reports and audit logs would be what falls under the parts that are both technically feasible and legally permissible? Like, that seems to be included in this already, to me.
Alan Woods (RYSG)
01:05:10
then make them.
Alan Woods (RYSG)
01:05:41
also +1 Sarah
Stephanie Perrin (NCSG)
01:06:20
Balancing test needs to be manual
Georgios Tselentis (GAC)
01:06:31
Is the authorisation authority the one responsible at first to judge what is legally permissible?
Stephanie Perrin (NCSG)
01:06:36
You may not like the argument, but we have certainly been making it
Janis Karklins (Chair)
01:06:48
I am surprised with objection of principle that we agreed month ago and already publicly announced in Montreal.
Marc Anderson (Verisign / RySG)
01:06:52
automation does not always mean cheaper... in some cases it is much more expensive.
Janis Karklins (Chair)
01:07:06
we used should at that presentation
Mark Svancarek (BC) (marksv)
01:07:16
@Marc, can you share an example?
Becky Burr
01:07:18
I am off the phone and in the Zoom room now
Brian King (IPC)
01:08:32
Ok, Marc and Stephanie. I (wrongfully) assumed that automation is always cheaper.
Amr Elsadr (NCSG)
01:08:49
Use of the word “may” here doesn’t prohibit automation at any point, so should be good enough.
Brian King (IPC)
01:09:07
I think we could agree to "technically feasible, legally permissible, and cost effective" or similar.
Margie Milam (BC)
01:10:17
+1 Alan G
Sarah Wyld (RrSG)
01:10:19
I'd be happy to have cost effective included here
Sarah Wyld (RrSG)
01:10:32
+1 Amr re may
Amr Elsadr (NCSG)
01:12:01
Agree with Volker.
Stephanie Perrin (NCSG)
01:12:05
I agree with Volker too
Alan Woods (RYSG)
01:12:25
agree to Cost effective. Also that feeds into the broader and overarching requirement of cost benefit study / feasibility study etc.
Sarah Wyld (RrSG)
01:12:41
+1 Volker
Alan Greenberg (ALAC)
01:14:16
If the AUthorization provider is considered part of the SSAD, then certainly we cannot say MUST. But we also know that the Accreditation provider WILL be using manual (at least in part) so I think those providers cannot be an integral part of the SSAD.
Berry Cobb
01:14:23
To our rules described in prior call, please only use side-bar comments for suggested changes.
Stephanie Perrin (NCSG)
01:17:02
Mark of course things are going to be ambiguous. WE don’t know who the controller is yet. By definition, there is ambiguity.
Sarah Wyld (RrSG)
01:17:24
+1 Stephanie
Volker Greimann (RrSG)
01:17:46
Adding must will add just that much more complexity to the IRT too.
Volker Greimann (RrSG)
01:17:57
Because then the IRT must determine feasibility
Volker Greimann (RrSG)
01:18:09
Remember how that discussion turned our
Amr Elsadr (NCSG)
01:18:12
@Marc: +1. Right!!
Volker Greimann (RrSG)
01:18:18
Turned out for X-field?
Sarah Wyld (RrSG)
01:18:45
+1 Marc
Stephanie Perrin (NCSG)
01:18:48
The fairness of the cost allocation issue also inserts ambiguity into that IRT decision making.
Matt Serlin (RrSG)
01:18:50
agreed
Volker Greimann (RrSG)
01:18:55
Agreed to Marc
Stephanie Perrin (NCSG)
01:19:08
Marc is stating the problem well.
Stephanie Perrin (NCSG)
01:19:57
It is not like, after all this work, we are trying to weasel out of the concept of SSAD. Must is too coercive, given the number of open variables.
Berry Cobb
01:21:45
FYI - "must" has been here in the version history since LA and as such not being introduced here for first time. The suggestions here on the call were to change from must to may.
Berry Cobb
01:21:58
the original draft from 23 Sept has this language: "• Full automation of the SSAD may not be possible, but SSAD must be automated where technically and/or legally permissable;• In those areas where it is not possible to automate, standardization must be the objective.
Laureen Kapin (GAC)
01:22:16
Thanks for this clarification Barry.
Alan Greenberg (ALAC)
01:23:05
REading Berry's comment into the record would be good.
Volker Greimann (RrSG)
01:23:09
shmust
Amr Elsadr (NCSG)
01:23:15
lol
Volker Greimann (RrSG)
01:23:21
shmayst
Mark Svancarek (BC) (marksv)
01:23:33
lol
Brian King (IPC)
01:24:00
Thanks Berry
Franck Journoud (IPC)
01:24:40
I'm eager to see what I can come up with too!
Hadia Elminiawi (ALAC)
01:24:42
You do not really need to mention the technical feasibility - You are stating the obvious if it cannot be implemented (technically) then it is not even an option. having said so I am fine with keeping technically feasible. In all cases the sentence now includes the technical, legal and cost aspects so why do we not want to use "must" ? If any reason comes up related to the above aspects then no automation will happen.
Margie Milam (BC)
01:25:47
I'm going offline but will stay on the call
Matt Serlin (RrSG)
01:27:55
Do we envision the IRT to determine the feasibility, cost effectiveness and legality as in that first sentence? Or the SSAD operator? Or ICANN?
Amr Elsadr (NCSG)
01:28:12
In my experience, IRTs are commonly very resistant to sending issues with which they’re having difficulty back to the GNSO. Things can really get quite stuck.
Sarah Wyld (RrSG)
01:28:18
Good question @Matt S.
Amr Elsadr (NCSG)
01:28:49
@Sarah: +1 on Matt’s question being a good one.
Amr Elsadr (NCSG)
01:29:25
Some flexibility in the policy recommendation just seems like the smart thing to do to me.
Hadia Elminiawi (ALAC)
01:29:39
@Matt yes this is a good question who will determine this
Alan Woods (RYSG)
01:29:40
@matt great question, from a POV of the best possible flexibility and to allow the disclosing body to dynamically approach their own legal risk without requiring a consensus policy - should really be the disclosing controller.
Greg Aaron (SSAC)
01:29:44
who determines what is " cost effective"?
Volker Greimann (RrSG)
01:30:36
If we ant to have a working/workable system quickly, flexibility will be paramount. The more we leave to the IRT to figure out, the longer we will wait for the system
Hadia Elminiawi (ALAC)
01:30:37
@Sara however the flexibility adds nothing to the question and its answer
Volker Greimann (RrSG)
01:31:02
@Greg: Exactly, and do we want to wait a year or so to find out?
Sarah Wyld (RrSG)
01:31:08
I don't think I had said anything about flexibility, Hadia
Amr Elsadr (NCSG)
01:31:17
@Hadia: It also doesn’t prohibit automation in any way.
Volker Greimann (RrSG)
01:31:45
Do we want perfect in ten years, or do we want workable and legal in two?
Hadia Elminiawi (ALAC)
01:31:54
@Sarah correct sorry it was amr
Greg Aaron (SSAC)
01:32:06
That's a false equavalence
Matt Serlin (RrSG)
01:32:47
Great point Volker…I think we’d all say we should not be striving for perfection…if so, the IRT for this would last forver
Amr Elsadr (NCSG)
01:34:01
I’m not clear on what text we’re discussing.
Stephanie Perrin (NCSG)
01:34:21
I raised my hand
Caitlin Tubergen
01:34:28
The SSAD must allow for automation of the processing of well-formed, valid, complete, properly-identified requests from accredited users with some limited and specific set of legal basis and data processing purposes which are yet to be determined. These requests MAY be automatically processed and result in the disclosure of non-public RDS data without human intervention.
Caitlin Tubergen
01:34:40
(This is the text NCSG objected to.)
Amr Elsadr (NCSG)
01:34:56
Thanks, Caitlin.
Berry Cobb
01:34:57
Correct, Milton was original commenter.
Berry Cobb
01:35:21
MarkSV made the suggestion to change MUST to SHOULD.
Brian King (IPC)
01:35:57
MarkSV didn't mean that :-)
Volker Greimann (RrSG)
01:35:59
Aww, our littles working group observer also does not like “must”
Volker Greimann (RrSG)
01:36:02
littlest
Stephanie Perrin (NCSG)
01:37:00
I train ‘em early
Franck Journoud (IPC)
01:37:23
well played, Stephanie
Amr Elsadr (NCSG)
01:37:28
Agree that “should” is preferable.
Amr Elsadr (NCSG)
01:37:34
@Franck: lol
Matt Serlin (RrSG)
01:38:53
This policy language is not what will be enforced
Volker Greimann (RrSG)
01:38:57
“Must not”
Amr Elsadr (NCSG)
01:39:00
Enforceability is cool, so long as there are no moving parts, of which there are potentially several in this case.
Matt Serlin (RrSG)
01:39:18
This is what informs the IRT to write actual language that will become binding and enforceable
Laureen Kapin (GAC)
01:39:20
+1 Brian -- our proposed policies need to be enforceable.
Amr Elsadr (NCSG)
01:39:24
+1 to “should”.
Greg Aaron (SSAC)
01:40:23
No, SHOULD is not "strong" according to the RFC definitions we use in these documents. SHOULD is optional and not biding.
Franck Journoud (IPC)
01:40:30
"I'm new here": hey that's MY line, Mark Sv!!!
Sarah Wyld (RrSG)
01:40:58
Should is definitely stronger than May
Laureen Kapin (GAC)
01:41:08
Didn't we get guidance from ICANN about enforceability of "should" indicating enforcement challenges? Please clarify.
Sarah Wyld (RrSG)
01:41:16
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
Mark Svancarek (BC) (marksv)
01:41:20
ha
Laureen Kapin (GAC)
01:41:32
Thanks Sarah --
Greg Aaron (SSAC)
01:41:53
Yes, read RFC 2119 for the definitions. SHOULD can be ignored by the implementing party...
Alan Woods (RYSG)
01:41:55
That makes great sense Sarah .. thanks for providing
Hadia Elminiawi (ALAC)
01:42:19
Thanks Sarah
Sarah Wyld (RrSG)
01:42:25
Greg - agree, but my point is that a MAY is truly optional, while a SHOULD is a strong requirement that can only be ignored in limited and specific circumstances
Matt Serlin (RrSG)
01:42:39
I think should is much better than may
Sarah Wyld (RrSG)
01:42:39
+1 Marc
Stephanie Perrin (NCSG)
01:42:47
Once we get the variables bolted down, we can interpret the should better in the IRT
Sarah Wyld (RrSG)
01:42:56
+1 Stephanie - we have so many crucial open questions remaining
Matt Serlin (RrSG)
01:42:58
And should (excuse the pun) allow the IRT to work toward that in their work
Greg Aaron (SSAC)
01:43:03
in ICANN contracts and Consensus Policies, SHOULD is not binding.
Stephanie Perrin (NCSG)
01:43:52
Here is one “must” I agree with….we “must” decide who the controller and processors are.
Mark Svancarek (BC) (marksv)
01:44:33
@Greg - I am concerned that SHOULD in Rec turns to MAY in IRT turns to not enforced in practice
Volker Greimann (RrSG)
01:45:25
Can we please move on
Volker Greimann (RrSG)
01:45:34
And discuss issues of substance
Mark Svancarek (BC) (marksv)
01:46:09
Isn't enforceability a topic of substance?
Volker Greimann (RrSG)
01:46:20
Yes, Greg which is why there is objection to must
Brian King (IPC)
01:46:49
We have MUST language in the Temporary Specification that ICANN Compliance still will not enforce ("reasonable access"), so we need to be very clear here.
Volker Greimann (RrSG)
01:47:00
Enforceability against the SSAC, which AlanG stated should be the gateway platform only?
Volker Greimann (RrSG)
01:47:08
What is the point?
Alan Greenberg (ALAC)
01:47:10
COmpliance and enforceablility is related to contracted parties - ie registrars and registries. Contracts with service providers is addressed through ICANN Legal and contractual terms.
Volker Greimann (RrSG)
01:47:30
exactly
Sarah Wyld (RrSG)
01:47:41
+1 Alan W
Amr Elsadr (NCSG)
01:47:53
@AlanW: YES!! Thank you!!
Matt Serlin (RrSG)
01:48:02
Well said Alan W
Alan Greenberg (ALAC)
01:48:07
If a registrar and registry will be involved with the SSAD, it will be as a authorization provider and in that case no one is saying it must be automated.
Brian King (IPC)
01:49:14
+1 Laureen
Mark Svancarek (BC) (marksv)
01:49:24
+1
Alan Woods (RYSG)
01:49:44
I'm also thinking of the poor Centralized SSAD Alan - I agree with you, but we are cementing them into a corner - the black or white - the yes or no - it will work or it will not.
Volker Greimann (RrSG)
01:49:54
Why do you want to enforce what basically is: “IF you can automate legally, you may!"
Mark Svancarek (BC) (marksv)
01:52:03
i win!
Matt Serlin (RrSG)
01:52:14
Clear as mud everyone?!?!
Amr Elsadr (NCSG)
01:52:30
I’m not sure what the concern is with “should” in this case. If there’s no reason not to automate, why wouldn’t automation be done?
Amr Elsadr (NCSG)
01:53:11
Even if the party doing the automation isn’t compelled to with something like “must” in the Consensus Policy language.
Caitlin Tubergen
01:54:22
ICANN org liaisons comment: For implementation purposes, who would determine that automation is "both technically feasible and legally permissible," and when would that occur?
Amr Elsadr (NCSG)
01:54:40
Same questions as the one Matt posted above.
Franck Journoud (IPC)
01:54:54
and stephanie and me and laureen
Hadia Elminiawi (ALAC)
01:54:59
@rafik I think we all agree on the meaning of must and should and how enforceable they are. the argument is about which one to use based on our common understanding of both words
Amr Elsadr (NCSG)
01:55:55
It’s difficult to answer this question right now, isn’t it? Not until we know what kind of model will be adopted?
Sarah Wyld (RrSG)
01:56:09
+1 Amr
Franck Journoud (IPC)
01:56:52
@Hadia: not just what the word means, but also who will apply it: centralized, decentralized? and when: request by request, or as a permanent policy matter.
Amr Elsadr (NCSG)
01:57:18
It’s still a good question. Need to defer answering it, for now.
Sarah Wyld (RrSG)
01:57:35
Right, e.g. if a data subject objects to being subjected to decisions based solely on automated processing, how would that be communicated to the SSAD operator?
Sarah Wyld (RrSG)
01:57:58
Good questions Stephanie
Amr Elsadr (NCSG)
01:58:55
@Stephanie and @Sarah: +1
Stephanie Perrin (NCSG)
02:00:05
Exactly the problem Marc….
Stephanie Perrin (NCSG)
02:00:12
I mean Mark SV
Sarah Wyld (RrSG)
02:00:42
Sorry - I missed the last thing Mark SV said - the decision what ?
Berry Cobb
02:02:14
https://docs.google.com/document/d/1KqfkWfbC6gBIrmE3OTTw7MYpThciaMc03Lu6M9skEEI/edit
Sarah Wyld (RrSG)
02:02:19
Thanks Berry
Sarah Wyld (RrSG)
02:03:26
What happens if the disclosure is consistent with the recommendations but still contradicts applicable law?
Sarah Wyld (RrSG)
02:04:33
maybe 'or' rather than 'and'?
Marc Anderson (Verisign / RySG)
02:05:58
what are we trying to accomplish by adding the online and offline language to section e - I'm not sure what this proposed edit is trying to accomplish.
Amr Elsadr (NCSG)
02:10:04
Agree with Marc. I don’t understand what “online and offline” refers to. Not in favor of language that may be perceived to mean different things during implementation.
Sarah Wyld (RrSG)
02:10:30
Not super clear to me how physical infrastructure like that would be affected by a domain name
Marc Anderson (Verisign / RySG)
02:10:34
Ok, thanks Dan
Alan Woods (RYSG)
02:10:48
or mitigated by release of registrant data … but OK
Sarah Wyld (RrSG)
02:10:53
Right
Laureen Kapin (GAC)
02:11:48
I think there is some support --
Franck Journoud (IPC)
02:12:25
+1 @margie
Hadia Elminiawi (ALAC)
02:12:28
@ I heard no objection to the addition the only comments were with regard to the clarity
Amr Elsadr (NCSG)
02:13:55
Can someone provide examples of “offline” infrastructure being rescued from danger as a result of registrant data being disclosed? I’m not sure what this is meant to mitigate against.
Sarah Wyld (RrSG)
02:14:31
Disagree with this text. ICANN Compliance is not the correct arbiter of disclosure disputes
Sarah Wyld (RrSG)
02:14:53
+1 Matt S, thank you.
Alan Woods (RYSG)
02:14:54
+100 Matt
Sarah Wyld (RrSG)
02:19:22
+1 Marc - Compliance should deal with the process, which will be contractually required, while an appropriate DPA should deal with the actual disclosure decision because it relates to applicable law
Stephanie Perrin (NCSG)
02:19:34
Agree with Sarah re Icann compliance
Sarah Wyld (RrSG)
02:19:53
We need to make sure not to set up contractual requirements that will contradict applicable law
Volker Greimann (RrSG)
02:20:10
Do you want us to answer compliance or requestors?
Stephanie Perrin (NCSG)
02:20:14
Furthermore, unless ICANN steps up as controller, they would have no authority to intervene
Matt Serlin (RrSG)
02:20:25
Agreed…as I said compliance should’t be making determinations as to whether or not disclosure is appropriate or not
Sarah Wyld (RrSG)
02:20:36
+1 Stephanie
Volker Greimann (RrSG)
02:20:39
A compliance request can easily take up tenfold the time a response can, often more
Sarah Wyld (RrSG)
02:20:39
+1 Marc
Sarah Wyld (RrSG)
02:20:47
sorry, I mean +1 Matt Serlijn. But also marc in general.
Volker Greimann (RrSG)
02:21:03
So if we get compliance complaints for every refusal, the queue will grow
Matt Serlin (RrSG)
02:21:27
Well in theory the SSAD operator would have a contract in place so they could go to compliance
Matt Serlin (RrSG)
02:21:42
Even if the disclosing party was not a registrar/registry
Caitlin Tubergen
02:22:29
Further to Marc’s point: “If Contracted Parties are ultimately responsible for the decision to disclose data, ICANN Compliance should be prepared to investigate complaints regarding disclosure requests under its standard enforcement processes."
Marc Anderson (Verisign / RySG)
02:23:10
@caitlin - thanks!
Sarah Wyld (RrSG)
02:24:09
Right, but the consequence should be within the legal system, not the icann contractual compliance system
Amr Elsadr (NCSG)
02:24:17
If a party is refusing to hand over data for a valid/legal reason, then its decision to do so should stand.
Matt Serlin (RrSG)
02:24:39
Yes but that isn’t what this says Mark…there could be consequences for a valid rejection of a request if compliance disagrees with the assessment or balancing test
Matt Serlin (RrSG)
02:24:49
seems that’s just as dangerous as the scenario you describe
Amr Elsadr (NCSG)
02:24:57
Compliance cannot (or “must” not) compel the party to do otherwise.
Sarah Wyld (RrSG)
02:24:58
+1 MattS
Alan Woods (RYSG)
02:25:04
The controller has the obligation to the data subject - not ICANN
Amr Elsadr (NCSG)
02:26:27
@AlanW: +1
Matt Serlin (RrSG)
02:26:43
I agree with Mark SV on his point about a party that blanket refuses all requests without legitimate and meaningful review but again that’s not what this text says
Brian King (IPC)
02:27:13
That's the concern we need to address
Matthew Crossman (RySG)
02:27:16
I think we should draw the line at procedural vs. substantive assessment of a decision to disclose. If a controller follows the prescribed procedure in the policy and makes a decision not to disclose, that should not be subject to compliance complaint. But if a controller is not following the procedure in the policy, that is a valid place for compliance to review
Brian King (IPC)
02:27:22
We can work on other language
Matt Serlin (RrSG)
02:27:36
+1 Matt C
Sarah Wyld (RrSG)
02:27:38
Matthew - yes! exactly!
Amr Elsadr (NCSG)
02:27:42
@MatthewC: +1
Brian King (IPC)
02:28:08
I had to step away earlier when I presume we looked at the language from the P/P policy I added in the margin. That would be a big help here.
Matt Serlin (RrSG)
02:28:19
We included language that requires a justification for not disclosing didn’t we?
Brian King (IPC)
02:28:21
Sorry I missed that conversation
Sarah Wyld (RrSG)
02:28:37
Yesw Matt - d) Responses where disclosure of data (in whole or in part) has been denied should include: rationale sufficient for the requestor to understand the reasons for the decision,
Sarah Wyld (RrSG)
02:28:52
I think Matthew C's point here in chat is very important
Matt Serlin (RrSG)
02:28:57
Sarah had that off the top of her head btw :)
Stephanie Perrin (NCSG)
02:29:13
Sorry folks, have to run!
Matthew Crossman (RySG)
02:30:01
Exactly Sarah,
Sarah Wyld (RrSG)
02:30:39
I just scrolled up in the doc, guys. :)
Berry Cobb
02:30:50
https://docs.google.com/document/d/1B2JHP0ue4sAu5u37NtddzmtYs--Q_jg2mfKho-YB81E/edit#heading=h.gjdgxs
Brian King (IPC)
02:32:21
Matt C. I agree in principle, but what happens in practice is many CPs play lip service to ICANN Compliance and Compliance claims they don't have the tools they need to address the issues. We have an opportunity to do better here.
Brian King (IPC)
02:33:04
And I think we can. Sounds like the language here doesn't work for many, so we can try again.
Alan Woods (RYSG)
02:35:25
Brian .. come on .. define "many" also such statements are both inflammatory, unsubstantiated and utterly unhelpful. I mean … for instance … does MarkMonitor only pay lip service to ICANN compliance?
Alan Woods (RYSG)
02:36:03
I'm sure they are not …. but please can we keep it positive here.
Matt Serlin (RrSG)
02:36:39
Agreed…the point was not to protect bad actors but we felt inappropriate to have compliance be the ultimate authority over whether or not a disclosure request is appropriate or not
Matthew Crossman (RySG)
02:36:45
Brian - but isn't that why we have specific steps (like what Sarah flagged) requiring a baseline level of documentation that the appropriate steps were followed? Isn't that a more effective way to address the problem (while still giving compliance a hook to get the truly bad actors)
Berry Cobb
02:38:11
LEgal Committee call next Tuesday.
Berry Cobb
02:38:25
Next EPDP - 19 Dec.
Berry Cobb
02:38:56
Deadline for review of • Purposes• Acceptable Use Policyis 17 Dec
Franck Journoud (IPC)
02:39:13
Rafik: I don't understand what our way forward is on user groups, I didn't understand the "approach"
Brian King (IPC)
02:39:44
Didn't mean to be inflammatory - apologies for that. Trying to be concise enough for chat about the concern that we're attempting to address/avoid. Matt C. yes that is a huge help.
Franck Journoud (IPC)
02:43:25
ok
Brian King (IPC)
02:43:39
thanks all
Rahul Gosain (GAC)
02:43:49
Thanks All. Bye Everyone.
Amr Elsadr (NCSG)
02:43:55
Thanks all. Bye.
Hadia Elminiawi (ALAC)
02:44:02
bye