Logo

Marika Konings' Personal Meeting Room
James Bladel (RrSG)
01:06:20
Agree, we should have a “cry wolf” provision if it’s not already in there
Julf Helsingius (NCSG)
01:07:19
+1 James
Chris Lewis-Evans(GAC)
01:13:20
+1 James
Volker Greimann (RrSG)
01:13:23
We could also publish it in the icann registrar service portal. Will only take 5 years to implement it there
marksv
01:13:28
+1 James
Brian King (IPC)
01:13:45
lol Volker. I was actually thinking that's a good place where Rrs can keep that information up to date.
Mark Svancerak (BC)
01:13:54
@Volker, it will be added immediately and promptly become undiscoverable
James Bladel (RrSG)
01:14:19
Would be great if ICANN can create those “profiles” by pulling data from other sources (their Registrar Information Forms or DN Portal).
James Bladel (RrSG)
01:14:32
But we would still need a mechanism to update/manage
Volker Greimann (RrSG)
01:14:33
agreed
James Bladel (RrSG)
01:15:25
We are 24/7
James Bladel (RrSG)
01:15:40
Or, from 12:00-12:30 on every 3rd Sunday in Leap Years
Thomas Rickert (ISPCP)
01:16:10
Can’t we say you publish, but it is not binding? It is just to give the SSAD users an idea of when they can typically expect an office to be open
Mark Svancerak (BC)
01:16:34
vftw
Matt Serlin (RrSG)
01:18:00
I’d love to see ICANN gather all of the required info for registrars/registries and then let them publish a directory of sorts
Matt Serlin (RrSG)
01:18:09
but that’s probably a discussion for another time and venue
Alan Woods (RYSG)
01:20:25
+1 Matt
Margie Milam (BC)
01:21:15
+1 Thomas
Volker Greimann (RrSG)
01:23:06
https://cipher.com/blog/the-16-sectors-of-critical-infrastructure-cybersecurity/
stephanieperrin
01:24:42
perhaps add without restricting the generality of the foregoing in there (yes, it is my favorite phrase)
Thomas Rickert (ISPCP)
01:29:57
energy, transport, banking, financial market infrastructures, health, drinking water supply and distribution, and digital infrastructure sectors
Thomas Rickert (ISPCP)
01:30:18
I will try to find a list of definitions in English
Thomas Rickert (ISPCP)
01:31:11
But Volker’s ist is also good.
Marika Konings
01:32:09
@Thomas - maybe including the reference to the relevant section in GDPR is sufficient?
Thomas Rickert (ISPCP)
01:33:50
@Marika - it’s not GDPR, it’s the NIS directive.
Thomas Rickert (ISPCP)
01:33:53
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.L_.2016.194.01.0001.01.ENG&toc=OJ:L:2016:194:TOC
Marika Konings
01:35:39
Got you, thanks
Georgios Tselentis
01:35:57
I do not know if that from B&B helps https://www.twobirds.com/en/in-focus/cybersecurity/nisd-tracker/country-comparison-by-topic/determination-of-operators-of-essential-services
Margie Milam (BC)
01:39:53
See the right to be informed discussion: https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/individual-rights/right-to-be-informed/
Margie Milam (BC)
01:42:42
GDPR Article 13: https://gdpr-info.eu/art-13-gdpr/
Mark Svancerak (BC)
01:48:00
I do have a concern that a controller would deliberately choose not to inform the registrant that data "might be disclosed to IP holders" - and then later say, "well, I can't disclose for that purpose since it was never disclosed at the time of collection"
Mark Svancerak (BC)
01:49:03
Alan makes my point, thanks
Alan Woods (RYSG)
01:50:01
Wonderfully cynical. Thank you Mark
Mark Svancerak (BC)
01:50:03
(though I disagreed with the final conclusion)
Alan Woods (RYSG)
01:50:39
also It is refreshing to see you guys worried about the registrant for once
Mark Svancerak (BC)
01:50:43
It's not cynical if it reflects feedback we've previously received on past requests.
Mark Svancerak (BC)
01:50:48
hey!
Brian King (IPC)
01:50:59
boo Alan
Thomas Rickert (ISPCP)
01:51:09
Tone it down, friends!
Brian King (IPC)
01:51:21
:-)
Stephanie Perrin (NCSG)
01:54:15
legal certainty comes from the contract with the registrant which specifies UDRP and trademark abuse issues....
Stephanie Perrin (NCSG)
01:56:58
Suggested language in implementation advice section: “Best practice will evolve over time, but notice of potential disclosures of registrant data to third parties should include…..
Stephanie Perrin (NCSG)
01:57:45
and I disagree with Alan G as to what status ICANN has. Perhaps I am not in the loop, but we still have no clarity with respect to ICANN’s role in this ecosystem.
Stephanie Perrin (NCSG)
01:58:28
They are controllers with respect to the escrow agreements IMHO. Their role in running this hybrid model is rather unclear to me….possible processor.
Hadia Elminiawi (ALAC)
01:58:34
so what about changing "must" to "should" and keeping it
Thomas Rickert (ISPCP)
01:58:58
The joint controllers will ensure to compehehsively fulfill their information duties according to Art. 13 and 14 GDPR, which includes a list of recipients and categories of recipients of non-public registration data. The list of potential requestors in building block…. Shall serve as a basis for this, as legally permissible
Thomas Rickert (ISPCP)
01:59:37
My suggestion for language to fix this. What to you guys think? The eligible requestor list includes IP holders, so you are covered.
Stephanie Perrin (NCSG)
01:59:51
In setting the policy, they become the primary controller if they are coercive about decision making. The potential role of GDD is also quite unclear to me, but the more they do the more ICANN is the controller.
Becky Burr Board Liaison
02:00:07
I
Becky Burr Board Liaison
02:00:42
May be missing something, has there been a decision that as a matter of policy we do not want ICANN to be a controller?
Stephanie Perrin (NCSG)
02:01:23
you would know better than I Becky....
Mark Svancerak (BC)
02:01:40
I think Thomas' linkage resolves my concern about confusion in IRT - let's discuss during break
Brian King (IPC)
02:01:42
We see ICANN's controllership as being a positive thing
Stephanie Perrin (NCSG)
02:01:49
we are in the dark over here in ncsg
Thomas Rickert (ISPCP)
02:02:11
No, Becky. I think the opposite is true. We are hoping ICANN will commit to be a joint controller and enter into a JCA with Rys and Rrs
Becky Burr Board Liaison
02:02:12
I’m not aware of such a decision, and both the Board and ICANN have been pretty clear that we are willing to take that on
Brian King (IPC)
02:02:23
I think Thomas' incorporation by reference is a clever way to address this, and would likely meet your needs
Brian King (IPC)
02:03:03
What do CPH friends think?
Brian King (IPC)
02:03:25
*Would likely meet our needs as well
Hadia Elminiawi (ALAC)
02:03:50
@ Becky we are saying just the opposite ICANN is a controller
Stephanie Perrin (NCSG)
02:08:12
sorry old hand
Stephanie Perrin (NCSG)
02:09:19
Totally agree with Alan W
Margie Milam (BC)
02:10:50
yes - that works
Stephanie Perrin (NCSG)
02:11:01
Regrettable sentiment of mistrust is a great title for an article on this, thanks
James Bladel (RrSG)
02:16:30
The people paying get to decide what’s “financially feasible”
Stephanie Perrin (NCSG)
02:16:46
Pardon my inattention, but what happened to 56..we strongly support this RySG comment
Marika Konings
02:19:20
The financial sustainability recommendation will be discussed after we complete the list, incl. issue list items 56, 57 and 58
Stephanie Perrin (NCSG)
02:20:16
Thanks very much Marika, now I remember. I don’t know how you manage to keep all these things straight!!
Margie Milam (BC)
02:21:27
This is an ongoing issue, beyond initial implementation
Marika Konings
02:22:06
So initially IRT and then Advisory Group, if further consideration is needed?
Matt Serlin (RrSG)
02:22:35
That’s what we wanted to include this language!
Chris Disspain (ICANN Board Liaison)
02:47:06
so what would be the status of the advice from this advisory group?
Brian King (IPC)
02:47:24
@Chris that's the point of my point in 62
Chris Disspain (ICANN Board Liaison)
02:48:10
and who would the be representing?
Chris Disspain (ICANN Board Liaison)
02:48:56
Yes..Advice is a loaded word in icann
Matt Serlin (RrSG)
02:50:22
My personal view is that any sort of advisory committee is really something that should be defined and implemented by the GNSO Council and be something not just utilized by this policy process
Julf Helsingius (NCSG)
02:50:53
+1 Matt
Chris Lewis-Evans(GAC)
02:52:05
Does accreditation authority need changing to Central Gateway?
Alan Woods (RYSG)
02:53:13
+1 Matt
Mark Svancerak (BC)
03:02:55
AlanG makes my point. Hand down.
Mark Svancerak (BC)
03:35:27
Berry is making an important point. These are the business flows and let's not bog down in this portion of the meeting by too many details of implementation
Volker Greimann (RrSG)
03:36:09
I just had my eyes checked and received new strengths glasses but I cannot read a word in the chart
Mark Svancerak (BC)
03:36:21
CTL+
Volker Greimann (RrSG)
03:52:50
Like a Mario-pipe
Brian King (IPC)
03:52:59
Volker my thoughts exactly
Mark Svancerak (BC)
03:56:32
old hand
Stephanie Perrin (NCSG)
03:59:19
I think if you just state that it is not determinative, but illustrative, it will avoid innumerable comments which may not be helpful
Stephanie Perrin (NCSG)
03:59:50
Franck is dead right there, the text is going to be a slog, lots of folks will focus their critical eyeballs on any diagram.
Matthew Crossman (RySG)
04:00:27
I think that's right Franck - we've run into this in the Phase 1 IRT. A clear statement like you suggested makes sense to help the implementors.
Mark Svancerak (BC)
04:08:37
@MarcA I think there are specific implementations where the IdP has a direct responsibility at each logon; whether that detail belongs here is debatable
Georgios Tselentis (GAC)
04:10:28
Maybe I miss it but where is and who performs the logging process of the requests?
Stephanie Perrin (NCSG)
04:21:13
Thanks Mark, yes it is very important to have logging points, for DP reasons and of course quality controls
Stephanie Perrin (NCSG)
04:21:40
but as Berry says, maybe not on this diagram, perhaps an overlay.
Thomas Rickert (ISPCP)
04:22:56
Language for issue 54. I understand MarkSV and AlanW are ok with this: Notwithstanding obligations on the contracted parties under applicable law, ICANN and the contracted parties as joint controllers will draft and agree upon a privacy policy for the SSAD and standard language (relating to the SSAD) to inform data subjects according to Art. 13 and 14 GDPR (or any other relevant obligations), to be presented to data subjects by the registrars. This will contain information on potential recipients of non-public registration data including, but not limited to the recipients listed in Building Block .... as legally permissible. Information duties according to applicable laws may apply additionally, but the information referenced above must be contained as a minimum.
margiemilam
04:26:45
ok for me
Stephanie Perrin (NCSG)
04:30:18
do I need to say plus a million to Thomas’ comment?
Julf Helsingius (NCSG)
04:31:04
+1000001
Brian King (IPC)
04:33:37
FWIW Dan's point is correct that controllership is fact-based, and we haven't decided on all the facts yet.
Hadia Elminiawi (ALAC)
04:35:16
@Thomas - But how can we just like that determine this. Roles depend on facts.
Thomas Rickert (ISPCP)
04:36:35
@Hadia. We know what the SSAD will look like. We have agreed on the basic principles. I cannot imagine a way how the parties would not be joint controllers.
Hadia Elminiawi (ALAC)
04:37:48
@Thomas fine then lets state this clearly with the logic behind it in some other part of the report
Stephanie Perrin (NCSG)
04:38:09
I always like to note when Alan G and I are in strong agreement. Support his remarks
Thomas Rickert (ISPCP)
04:40:11
We can do a section. In fact, we had a section in the phase 1 report and it was then diluted. So we can easily insert something
Mark Svancarek (BC)
04:40:25
Can we keep Thomas' suggestion if "joint controllers" is removed?
James Bladel (RrSG)
04:41:00
ICANN - Let’s wait and see who is a Data Controller. CPs - Fine, we’re going home. ICANN - You can’t go home. CPs - I guess we know who the controller is then.
Thomas Rickert (ISPCP)
04:41:16
Let’s not remove it from the report. If we remove it here, we need to put it somewhere else.
Hadia Elminiawi (ALAC)
04:41:43
@James :)
James Bladel (RrSG)
04:42:24
just a bit of snark to move things along. It’s why i get invited to these things
Volker Greimann (RrSG)
04:42:26
ICANN and the contracted parties [as whatever type of controllers they are]…
Matt Serlin (RrSG)
04:47:23
This seems like a rather large issue to try and sort out in the next week…
Brian King (IPC)
04:49:55
+1 Laureen
Laureen Kapin (GAC)
04:55:15
My modest proposal for purposes of the Draft Report in 4.3 Underlying Assumptions: "We believe that for the purposes of the Draft Preliminary Report, ICANN serves as joint controller for certain purposes described the SSAD Model."
Thomas Rickert (ISPCP)
04:55:37
Just for the record, I will not be part of the drafting team.
Thomas Rickert (ISPCP)
04:55:54
Happy to review the output, though.
James Bladel (RrSG)
04:56:29
Stephanie raise the controller, data processing audit idea when I first met her, in 2014.
Stephanie Perrin (NCSG)
04:56:48
You are very kind to do so. Any chance you could send us your previous text that got obliterated?
Stephanie Perrin (NCSG)
04:57:20
(that last remark was to Thomas)
Thomas Rickert (ISPCP)
04:59:22
@Stephanie, yes, will dig out and send to you.
Stephanie Perrin (NCSG)
05:04:59
Thanks Thomas, very much appreciated
Volker Greimann (RrSG)
05:06:48
Yes, but the number of YES/No actions should not be part of the SLA
Volker Greimann (RrSG)
05:08:37
If there are too many denials, maybe the requests are a bit shit?
James Bladel (RrSG)
05:09:05
3 months means we have a “mid-term” and a “final”
Margie Milam (BC)
05:14:41
I'm talking about an ability to have registrar compliance ability to address unusually low disclosure rates for legitimate requests
Milton Mueller (NCSG)
05:20:03
that’s cost causation, Brian
Becky Burr (ICANN Board Liaison)
05:22:16
Urge you to make sure that cost is associated with use of the service and NOT acquisition of data. The latter raises significant CCPA questions - paying “for datasets” is likely to be problematic
Brian King (IPC)
05:22:38
good point, Becky
James Bladel (RrSG)
05:23:50
I don’t fully understand the heartburn around “cost causation” (a defined term in economics & utility rates), but it sounds like Brian’s language is dancing around “system utilization”. we could also add “volume and patterns”
Milton Mueller (NCSG)
05:23:59
Becky, that’s one reason why cost causation is a better concept that request volume
Stephanie Perrin (NCSG)
05:24:38
would it be helpful to mention fee waiver structure?
Stephanie Perrin (NCSG)
05:24:59
Most public institutions have a sliding scale for information requests
Milton Mueller (NCSG)
05:25:16
No
Milton Mueller (NCSG)
05:25:32
I have to be unmuted by God
Milton Mueller (NCSG)
05:31:36
it is quite an exaggeration to say that the internet as a whole requires this to run.
Milton Mueller (NCSG)
05:32:11
this data is needed SOME times for parallel systems such as law enforcement to work more efficiently
James Bladel (RrSG)
05:38:17
Are folks here clear on where ICANN gets its money?
Stephanie Perrin (NCSG)
05:41:29
Direct does not help me at all, indirect costs are passed on
Alan Greenberg (ALAC)
05:42:55
Part of the problem is the rather colloquial term "foot the bill"
Brian King (IPC)
05:43:05
+1 Alan G
Stephanie Perrin (NCSG)
05:43:14
at least is has the merit of being clear
Brian King (IPC)
05:43:23
also, many registrants are not "data subjects"
Alan Greenberg (ALAC)
05:44:03
@Stephane not to me.
Milton Mueller (NCSG)
05:46:39
no, if you say “directly” you cannot delete the language about beneficiaries and users, and certainly not “cost causation” because then you’ve just open the door to registrants indirectly paying the cost, ie through higher prices
Stephanie Perrin (NCSG)
05:46:54
I agree that slipping into the vernacular should be avoided Alan G, but there are a ton of other edits I would want first....
Franck Journoud (IPC)
05:48:24
@MARIKA: I suggest you replace "users" with "requrestors"
Brian King (IPC)
05:50:03
New gTLD auction funds still laying around somewhere?
Volker Greimann (RrSG)
05:50:14
Hand in there cookie jar
Brian King (IPC)
05:50:55
That was mostly a joke, btw
Volker Greimann (RrSG)
05:55:46
Well, it _is_ the biggest pool of unallocated funds in the community
Stephanie Perrin (NCSG)
05:58:25
we still need directly or indirectly in there.
Volker Greimann (RrSG)
05:58:33
indeed
Stephanie Perrin (NCSG)
05:59:17
Where is ICANN going to get the money to build it?
James Bladel (RrSG)
06:03:38
For the record, I don’t think it’s redundant or repetitive. If it were up to me, I would repeat this a dozen times in the report.
James Bladel (RrSG)
06:08:00
Folks - ICANN can’t give us an estimate on costs for 2 reasons. One, they have no idea how the final system will operate, and two: they need to be able to negotiate with potential subcontractors to build & run this monster.
Milton Mueller (NCSG)
06:12:45
agree it is not redundant or repetitive. Nor does it repeat itself
Mark Svancarek (BC)
06:14:50
CPs acknowledge that they pay a portion. Requestors acknowledge that they pay a portion. Current text allows ICANN to pay a portion.
Mark Svancarek (BC)
06:15:11
Text says that requestors pay th eprimary portion.
Milton Mueller (NCSG)
06:17:30
Under no circumstances should this language be removed
Mark Svancarek (BC)
06:19:01
!!!
Alan Greenberg (ALAC)
06:23:21
ANY = DIRECTLY OR INDIRECTLY
Milton Mueller (NCSG)
06:23:22
cost causation, anyone?
Matthew Crossman (RySG)
06:25:52
Indemnification of the controllers based on the following principles:• Requestors are responsible for damages or costs related to third party claims arising from (i) their misrepresentations in the accreditation or request process; or (ii) misuse of the requested data in violation of the applicable terms of use or applicable law(s).• Nothing in these terms limits any parties’ liability or rights of recovery under applicable laws (i.e. requestors are not precluded from seeking recovery from controllers where those rights are provided under law).• Nothing in these terms shall be construed to create indemnification obligations for public authority requestors who lack the legal authority to enter into such indemnification clauses. Further, nothing in this clause shall alter potentially existing government liability as a recourse for the operators of the SSAD.
Alan Greenberg (ALAC)
06:28:57
Looks good to me.
Thomas Rickert (ISPCP)
06:29:08
I am ok with this, too.
Stephanie Perrin (NCSG)
06:33:30
Did we lose the suggestion for damages for registrants who are not otherwise protected?
Stephanie Perrin (NCSG)
06:34:30
and just by the way, who foots the bill for the indemnification? Is it part of SSAD and therefore registrants are protected from bearing the costs
Becky Burr (ICANN Board Liaison)
06:35:44
I don’t understand that question Stephanie. Isn’t the indemnifying party on the hook for behaviors that give rise to damages in the circumstances in which the indemnification applies?
Becky Burr (ICANN Board Liaison)
06:36:26
And the indemnifying party, presumably, would be the requestor
Becky Burr (ICANN Board Liaison)
06:36:45
Presumably and by the terms of the language
Stephanie Perrin (NCSG)
06:37:15
we discussed the fact that registrants who are not covered by GDPR in terms of having the ability to complain to DPA and seek damages should have the ability to seek damages if the system failed them, if their data was breached and caused them harm.
Stephanie Perrin (NCSG)
06:39:16
In other words, the indemnification stops at actors within the ICANN ecosystem, from the impact of errors in the system. Registrants who are not covered by DP law (e.g. in Africa where the laws have passed but not been enacted) have no recourse in the event of a breach
Stephanie Perrin (NCSG)
06:39:55
(some laws, not all laws, or in jurisdictions where there are no laws)
Stephanie Perrin (NCSG)
06:40:26
I have my hand up, do we still have a queue?
Thomas Rickert (ISPCP)
06:41:57
@Stephanie - cover that in the section dealing with the legal risk fund?