
27:46
is there no sound?

28:17
There is Volker … mayhems not for you

28:23
*mayhaps

28:27
I hear nothing :-(

28:55
thanks for upgrading me to panelist

29:01
@Terri: Your audio is breaking up a little.

29:12
You’re welcome, Milton

30:08
@Marc, we will check into your link issue.

30:31
Same issue for me too…thanks Terri!

31:43
As a reminder, March webinar links are different than April webinar links. Make sure you are using your panelist join information for March.

32:49
please select all panelists and attendees in order for everyone to see chat

32:49
good question, Janis

32:57
@Janis: No temp spec expiration deadline.

34:44
Ok I lost all that - was it just me? Seems Zoom is a teensy teensy best buggy / over burdened today

36:27
@Alan, would a dial out on the telephone help?

37:40
These are all ICANN org purposes or functions, Becky. Not third parties. Does ICANN even need a SSAD to get this data?

38:05
Thanks Terri… it seems to have resolved thank you!

41:00
apologies for being late

41:46
@Amr When you say they are covered you mean those are pusporses covered in Phase one by whom?

42:18
@Georgios: by the EPDP phase 1 recommendations, which have already been adopted by the ICANN Board.

42:43
There are specific purposes in phase 1 that cover the supermajority of items listed here, no?

43:06
I am not sure why I am asking this question, but if ICANN Org wants that language to be included, is ICANN Org willing to confirm that it can be helf fullly accountable for any issues that might arise with it? #devilsadvocate

44:08
@Becky: I didn’t thank you for providing this email. Yikes!! Thanks. :-)

44:23
ICANN will need it, yes. Third parties?

44:48
the mission does not identify tasks, therefore the data elements cannot be identified from the mission. However, processing of the data to fulfil the purpose of SSR according to the mission is essential

45:17
You’re not answering my question about third parties Becky

45:28
+1 Becky

45:33
Are we talking ICANN access or third party access?

46:38
thanks

46:55
the mission does not identify tasks, therefore the data elements cannot be identified from the mission. However, processing of the data to fulfil the purpose of SSR according to the mission is essential

47:01
FWIW ICANN would not necessarily be using 6(1)f

47:21
Reminder, please select all panelists and attendees in order for everyone to see chat.

47:22
FWIW ICANN would not necessarily be using 6(1)f

47:23
Milton, this is clearly about ICANN access, otherwise we would be back in the quandary of conflation identified by the Commission

47:36
OK, thanks for finally answering that

48:02
The paper itself specifically speaks to ICANN’s processing.

48:10
SO IT IS CLEAR NOW THAT PURPOSE TWO IS EXCLUSIVELY ABOUT DISCLOSURE TO ICANN NOT THIRD PARTIES

48:42
It is about ICANN’s processing of personal information Milton

48:57
What you need to be sure of is that ICANN cannot process the data out of its mission and also the proportionality element has to be respected. So there is no reason no oppose this purpose, what are we afraid of?

49:14
As long as ICANN acknowledges its role and responsibilities under Purpose 2.

49:31
+1 to James -- this is a reasonable resolution of Purpose 2 and based upon the Bylaws.

50:18
I am still having a great deal of difficulty with this.

51:07
ICANN does not control all this data. Does this explanation make it some kind of deus ex machina which can reach in at any time and control the data?

51:12
Didn't we agree that the terms of the privacy policy was not something we were planning to make recommendations on?

51:25
I believe we did Margie

51:28
I think the clarification that this is for ICANN‘s use is very helpful.

51:40
Amr is correct, we would need to provide a disclosure to registrants, that is not a problem - and it will be on ICANN as a controller to do so

52:01
Can we get NCSG over the line if we include that as mentioned in caps by Milton in this chat?

52:32
can you repeat it, Janis

52:54
Thomas: speaking only for me, answer to your question is yes

52:59
+1 to adding the statement to the report

53:18
I was hoping we would add it to the report

55:24
I would need an extensive clarification about ICANN’s role and accountability to get this “over the line”

55:51
@Janis: Right. Thanks.

56:13
From Me to All panelists: (10:29 AM)
I would need an extensive clarification about ICANN’s role and accountability to get this “over the line”

57:06
From Me to All panelists: (10:25 AM)
ICANN does not control all this data. Does this explanation make it some kind of deus ex machina which can reach in at any time and control the data?

57:54
Link to Can't Live with items: https://docs.google.com/document/d/186a4k-ls0cjbhvWQi_HfryDN1PVjfaSKvWMDKLcVQYM/edit#

58:08
@ Janis Can you remind us please whether intermediate results are expected from the study and if yes by when?

58:47
It is one thing for this group not to dictate to ICANN the terms of its privacy policy. I have had pretty good attendance and participation on this group, and I am still remarkably unclear as to what ICANN has stated as its precise role as a controller, co-controller, or processor, and this is as I have repeated forever, a very critical issue.

59:27
Whatever that role is, it is not a carte blanche access to RNH data for vague universal purposes.

01:08:47
So what Alan G is saying is the ePDP will carry on for years based on that…

01:09:00
Doesn’t look like we’re going to reach any consensus on this.

01:09:20
@James: +1. We need to recognize where we’re unlikely to reach consensus on.

01:09:26
I think it boils down to the question whether we are willing to accept fragmentation of treatment of registration data at the global level based on these criteria. The real question is, will further work change the consensus level (or the absence thereof) in this group. If not, we should not go into overtime for that.

01:10:23
Have we not had this discussion both in Phase 1 and in Phase 2…agreed that consensus on this issue is very unlikely even with additional time

01:10:35
@Matt: =1

01:10:38
+1

01:10:57
This is not jurisdictional

01:11:32
This is not the geo-distinction issue.

01:12:08
Why are we talking about jurisdiction?

01:12:23
@Janis: could you ask participants not to characterize the positions, let alone motives, of other EPDP members?

01:12:33
Separating “classes” of registrant based upon the type of entity or geographic location would appear to conflict with Becky’s SSR memo

01:14:24
Not jurisdictional? LOL LOL LOL

01:15:32
for the sake of legal universality differentiation between legal and natural persons is required.

01:16:44
we should end this and if the 'GNSO wants more, let it scope another pdp

01:16:46
No one is talking now about geographic distinction

01:16:56
the "e" of epdp is enough of a joke already!

01:17:30
We’ve already exhaustively discussed legal vs natural in phase 1 (pending the survey right now), and we’re unlikely to reach consensus on it from a policy perspective, not a legal one. Do we need to list all our reasoning again? We can, if necessary.

01:18:03
+1 james

01:19:16
I think it’s clear that privacy law -allows- us to make this distinction, but we have numerous reasons why -requiring- it is unacceptable. Thx.

01:19:23
I told you at the start you would be wasting your money

01:19:24
+1 Margie. The Bird & Bird memo provides helpful guidance on this.

01:20:25
+1 on moving forward via a small group and I volunteer to participate. We may yet be able to identify where we have consensus on a few key issues.

01:20:55
sorry, need 5 minutes

01:20:57
On th point of timing …. Can we also point out that the recommendation regarding the study in phase I does not state that th

01:21:03
..at we have to wait for the study

01:21:17
Only hat depending on the timing of the research, to use it if available.

01:21:25
one minute

01:21:30
.

01:21:57
ready now

01:22:01
There is no reason to delay issuing the addendum *IF* it allows us to continue talking about the issue after issuance.

01:22:09
Recommendation 17 - 3 - The EPDP Team will discuss the Legal vs. Natural issue in Phase 2. Depending onthe timing of the research, its discussions may inform the scope of research and/oruse its findings

01:22:26
All I’m getting today is that we must -

01:22:42
@AlanW: +1

01:23:20
I clearly agree with Volker on this.

01:23:42
+1 Volker and Alan W

01:23:49
Ä‘

01:24:09
@Volker: +1000

01:24:30
pls ignore the last message from me. Sent by accident.

01:24:30
Im dropping off and Steve is on in my place

01:24:38
GAC also supports work on legal /natural.

01:24:56
I see no reason to delay the addendum for the issue of natural vs legal. It won’t change anything.

01:25:08
Thanks Thomas…I was just trying to figure out what you were getting at ;-)

01:25:12
let's achieve closure

01:25:16
To be clear, we must publish today. Just say that we have not reach closure on how to address L/N.

01:25:20
I need to drop at the top of the hour. Thanks, all.

01:25:50
There are more comments in the input form than N/L - can we discuss those today?

01:26:43
Folks - I need to drop. Sarah Wyld will take my place on RrSG. Thanks!

01:26:58
an addendum to the addendum?

01:27:35
@MarkSV: +1

01:27:45
As I noted, running this small group in parallel risks affecting reviewing the comments on the Initial Report, which is part of critical path.

01:29:18
+1 Laureen to form a small group

01:29:19
No small group.

01:29:29
No small group.

01:29:35
Even if this group runs in parallel, it wont be a part of the addendum report, thus any possible outcome from the small team if it were to be included in the Final report, then it will delay it.

01:29:50
exactly, Berry

01:30:39
At huge risk ......

01:30:54
Did I read a different legal opinion?

01:30:54
No small group, This is an utterly intractable issue.

01:31:09
@ Berry, Janis is suggesting that we treat small group work as a comment that we consider in finalizing report. I don't think that would jeopardize critical path/deadline for final report.

01:32:56
I have been proposing from the get go that organizations that wish to self identify as corporations can self identify and propose a certification/accreditation method. Crooks are unlikely to sign up, but hey when did that ever stop this group from considering crazy ideas. However, this proposal has been studiously ignored.

01:33:03
@Laureen but it does divert already stretched resources on a timeline with zero slack where the focus of resource should be on reviewing public comments. Which btw, not all groups have submitted by yesterday's deadline.

01:33:18
no we may not

01:33:25
I don't think we all agree with that interpretation of the legal advice

01:33:52
I disagree with Steve

01:34:54
Based on this entire conversation, it seems the only way forward is to indicate we did not address the issue and reach consensus and get this back to the GNSO for their action

01:35:07
+1 Matt.

01:35:11
basically what Marc is saying :)

01:35:19
+1 Matt

01:35:36
Janis+1 lets move on

01:37:02
The addendum says “the EPDP Team will269 not be able to consider the findings within the timeframe that has been established for270 the delivery of the Final Report.” That is not accurate. Majority of this EPDP understands we MAY publish legal person data, but prefers that we do not. Let’s say so.

01:37:44
yes

01:38:50
The NCSG previously said that we should not go ahead with the Bird & Bird questions because it is not a legal matter but a policy matter. so from a legal point of view we do agree that it may be possible however the parties objecting to this are looking at it from a policy point of view and not a legal point of view, this is what our discussions lead to and suggest

01:39:29
I don't think this parallel option considers how much work we have ahead for the group to review comments.

01:39:41
+1 Berry

01:39:57
+1000 Berry

01:40:47
We have fundamental disagreements as to how helpful that advice is

01:41:29
can we circle round this for now and come back to this at the end of our call?

01:41:33
if reviewing legal reports will not change anything, why do we even have a budget for legal adivce?

01:41:35
The BC comment did not suggest a small team. We want the EPDP to state its conclusion, even if not by consensus

01:41:48
there is no conclusion

01:41:52
But the point is that this is not an issue of lack of time, it's an issue of lack of interest on the part of some members of epdp.

01:42:26
@Volker — we suggest the conclusion is that data for Legal Persons MAY be published but that EPDP majority do not want to publish.

01:42:29
we never reached a formal conclusion on this, so anything more would be a lie to serve an agenda

01:43:11
and personally, I think MAY is fine

01:43:21
I don’t believe it to be a lack of interest rather the resistance to continue to discuss issues that we have already spent countless hours on without reaching consensus

01:43:28
The decision not to publish for legal persons is a policy decision that some in this epdp make, not a legal question whose answer we don't know

01:43:41
as I said again and again, I like options on disclosure and publication

01:44:03
there should not be a position that it MAY NOT be published

01:46:15
it is entirely one-sided.

01:46:37
I disagree with that characterization of the EC input

01:46:43
Just out of curiosity, what happens to the model if lazy registrars who are not represented in this group just publish data based on poor (or non-existing) legal analysis, and there are complaints and court cases.

01:46:49
I disagree with everything but the first sentence

01:47:30
@Milton: +1

01:48:25
Taking my hand down. Milton said what I wanted to. The text may be accurate, but not complete. The narrative is applicable to all parties. What the BC is asking is for a narrative tilted in its favor.

01:48:28
Furthermore, statements about EC reps should always indicate which area in the commission they represent.

01:48:47
(Not that I am endorsing the inclusion of that language)

01:48:50
I would like to go on the record that after consultation of the ISPCP, that the ISPCP does not wish that the accuracy discussion shall further burden the EPDP work, but that it is an important topic to be addressed and further worked on in other policy work.

01:48:51
Also, I would point out that there is no information "contained in the SSAD"

01:49:08
the SSAD does not hold data, it is an avenue to request disclosure

01:49:29
+ all the numbers Sarah

01:49:47
The B&B legal memo on Accuracy says that the existing structures are sufficient, so I don't think we need to discuss it further here

01:50:51
Again +1 Sarah. B&B were very clear.

01:51:03
@Ben, can we address the "?" in the comment. Does SSAC support that statement as is?

01:51:14
@Sarah: +1

01:51:16
Berry, the sentence before should be removed as well.

01:51:21
All after "treated"

01:51:29
thanks

01:51:38
retracted. thx

01:53:02
they just want to remove the more specific reference to 6 1 f.

01:54:07
I am ok with the deletion

01:54:48
I like that Recommendation: Do nothing

01:54:59
Do No Harm!

01:57:19
@Steve: Sigh…, it’s like I said nothing. :-(

01:57:26
Agree with Steve here. Disclosure is the wrong word here

01:57:48
we all agree with the deletion as far as i can tell

01:57:58
+2 Steve B.

01:59:36
=1 Volcker

01:59:42
+1

02:00:13
so it'd be "therefore, publication of uniform masked email addresses is not currently feasible under the GDPR"

02:00:26
+1 Volker - add "uniform"

02:00:40
Preliminary Conclusion?

02:00:41
+1 Sarah

02:01:06
Agreed, Janis

02:01:18
hooray

02:01:27
sorry

02:02:10
It allows publication of masking emails, the issue is *uniform* masked emails

02:06:44
+1 Steve

02:07:51
For the part of BC and IPC, our rationale for disagreement on Legal Person and Accuracy were already provided.

02:09:28
I said that it is about ICANN’s processing of personal data about registrants. I cannot rule out the possibility that there will never be an instance in which ICANN, as a controller, shares information with a third party as part of that processing.

02:10:04
Thanks for that clarification Becky.

02:10:29
@Becky: Yes…, that’s our concern.

02:10:59
Disclosure is a form of processing, so vague language does not exclude it.

02:11:02
We're venturing into minority statements. Can all these be removed and disagreements be posted in the public comment?

02:11:29
@Berry: Aren’t minority statements normally included in reports?

02:11:39
Milton is right here

02:11:41
Final Reports after Consensus calls.

02:12:34
OK to delete it;

02:13:23
sorry :-)

02:13:35
Milton is making an important distinction.

02:13:39
But Milton, we agree with Becky that the purpose does NOT foreclose 3rd party disclosure as part of ICANN processing

02:14:10
@amr, I don’t think that distinguishes ICANN’s purpose from any other purpose. From time to time a controller may disclose information to a third party consistent with the requirements of GDPR.

02:14:17
@Milton it is an ICANN purpose however, ICANN may share the data with third parties

02:14:25
No, Hadia

02:14:31
But the purpose is not to disclose

02:14:43
exactly -

02:14:50
Don’t agree with Hadia

02:15:08
Becky: then that needs to be stated explicitly

02:15:08
Indeed, as Becky has stated, there may be exceptional circumstances where ICANN feels it has the authority to disclose to third parties. However, that is not the same as third parties’ purposes finding a home in ICANN’s purposes. Obviously, all stakeholders have an interest in maintaining SSR.

02:16:09
so given the EU advice about not conflating icann purposes with third parties, we need to add some wording to Rec 23 to say what Becky said - that the purpose is not to disclose to third parties

02:16:25
@Milton how can ICANN guarantee that there won't be some circumstances that would require the sharing of the data

02:17:04
Hadia, they don’t have to

02:17:09
there may be - but that is only as required for icann’s limited mission. we just need to make it clear that this is not a “we collect data with purpose to disclose

02:17:13
+1 Stephanie You express exactly what I wanted to say

02:17:18
Dropping comment is ok, but rewording Rec is not.

02:17:52
it does!

02:18:08
Milton, I’ve said repeatedly that Purpose 2 as supported by the Board articulates a purpose for ICANN’s processing of personal data about registrants. The basis of the purpose is to eliminate the conflation problem identified by the Commission.

02:18:24
@Becky: Understood, and not disagreeing. Just trying to explain why not being specific on this is problematic from an NCSG (registrant) perspective. I’m not even sure having a vague purpose on SSR grants the legal certainty ICANN org should be seeking.

02:18:32
We can add a foot note pointing back to Phase 1 report, Rec #1

02:18:49
Thank you for pointing that out Marc.

02:18:58
The way this is going, we will not be able to publish this today :-(

02:20:11
no one has proposed that Becky (prohibited)

02:20:23
just want to make it clear it’s an ICANN purpose, as Marc proposed

02:21:40
It still requires clarification in my view, mostly because only a few understand what it really means. Specificity as to examples, underlying reasons, likely frequency etc ought to be provided to ensure it is not abused

02:23:15
Sorry all … I must drop!

02:23:16
Thank you Becky this is clear

02:23:52
@Amr yes you an Becky are saying the same thing

02:24:00
and

02:24:19
+ 1 Berry

02:24:25
Apologies, must now move to another call

02:24:32
Same.

02:24:53
I need to drop as well

02:24:55
Thanks all

02:25:42
thanks, all

02:26:34
Janis — are we saying that no “minority statements” will be in this Addendum,?

02:26:53
no. Disagreeements to be posted in public comment.

02:26:58
Thanks all

02:27:01
minority statements are for final report.

02:27:03
Thank you all bye for now