
34:45
Hi all!

36:43
Please review ICANN Expected Standards of Behavior here: https://www.icann.org/resources/pages/expected-standards-2016-06-28-en

37:10
Members: please select all panelists and attendees in order for everyone to see chat.

47:54
Thank you, Volker

55:41
This word doc can be found on the mailman message sent with the agenda. Links to DOCX at bottom. https://mm.icann.org/pipermail/gnso-epdp-team/2020-June/003443.html

59:44
It depends. Categories are not, rationale probably would contain inferences.

59:49
so we are still trying to turn the hybrid model into a centralized model :-(

01:00:11
The nature of the question is personal info

01:00:46
+1 Margie, rationale needed to improve recommendations

01:00:53
Instead of rationale, would concerns be addressed if ‘reason for denial’ is used instead?

01:01:42
+1 Alan G

01:01:48
Members: please select all panelists and attendees in order for everyone to see chat.

01:02:36
+1 Marika

01:03:00
Please note that the logs include no personal data

01:04:29
Unfortunately, we do not really have agreement on what the "hybrid model" that we "agreed to" really is.

01:05:14
What Milton says is the model is not what I thought we agreed to, and I don't think I am lone.

01:05:25
...alone

01:05:49
@Alan how is that possible at this late stage??? Have we not all been clear about how this hybrid model was meant to work??

01:05:51
My understanding of hybrid is not consistent with Milton’s view either

01:05:54
well, Alan, I don’t know where we are if we are not working with the hybrid model. Your suggestion essentially reverses 90% of the work we have done

01:06:08
And I think calling it a “glorified ticketing system” isn’t really accurate

01:06:11
If it helps inform future automation later (or doesn't), that doesn't matter. This is to help the CGM make better recommendations.

01:06:22
@Volker: +1

01:07:07
I don’t understand what the value of an automated recommendation is.

01:07:17
…, by the CGM, that is.

01:07:22
What is that supposed to achieve?

01:08:19
@Amr, I understood it to help CPs make a decision. They've never had to make these decisions before, and many of them don't have in-house counsel, data protection officer, etc. In any event, a recommendation is non-binding.

01:08:30
your voice is fading, Janis

01:09:09
@Brian: Thanks, but what I’m actually trying to figure out is how an automated recommendation is practically going to help CPs make those decision?!

01:09:19
I think I recall Thomas mentioning that the outcome of decisions to disclosed could be beneficial to other CPs in that CPs collectively can learn from the results.....in addition to stats being submitted to SSAD for reporting etc.

01:09:22
+1 Janis

01:09:57
We do not have a common understanding of what we are talking about, as is so often the case.

01:10:07
@Amr: "Requests from this requestor, for this purpose, receives data 3% or 97% of the time" would be helpful, IMO.

01:10:34
+1 to Volker's suggestion drop down menu

01:11:30
We need to see that drop down box in order to agree. This is a policy issue, not implementation.

01:12:05
@Amr, I disagree. This is about transparency and optimizing a system

01:13:25
Transparency and optimizing a system for the disclosure of personal information to third parties is not necessarily what OUR SG is looking for in this process. We are looking for respect for human rights and data protection

01:13:36
And human rights includes due process

01:13:42
They are not mutually exclusive

01:16:16
This has been in the draft for a long time

01:16:22
Note that the documentation of rationale is not something new or that has changed since the Initial Report - as Janis noted, this question is about what, if anything, gets shared with the CGM. There appears to be support for sharing the reason for denial with the CGM.

01:16:40
The SSAD will prove to be useful to everyone. Having consistent and transparent operation of the system is useful to registrants, users and ultimately the CPs as well

01:17:10
SSAD has no value that I can think of to registrants. Just costs us more money.

01:18:29
to be fair milton, this was not intended to be an automation enabler but rather a recommendation that can be followed or not. this was agreed at the f2f you could not attend

01:18:48
Reason

01:19:44
Based on how this is going, why don't we just declare failure and give ourselves a few days off for the rest of the week.This does not bode well for PDP 3.0.

01:21:50
@Stephanie, I agree that this must not contain any personal data. Can we add "will not contain personal data"?

01:22:28
@Stephanie: +1

01:23:27
I might be wrong, but I think you are partially talking past each other. The proposed hybrid model can move to more centralization, which does not equal automation.

01:23:58
+1 Thomas

01:24:24
+1 Thomas, and can live with the language on the screen

01:25:44
Thanks, Dan.

01:26:24
That’s an implementation detail

01:26:25
Note that the reference to rationale comes from other requirements where this is documented.

01:26:58
d. Responses where disclosure of data (in whole or in part) has been denied MUST include: rationale sufficient for the requestor to objectively understand the reasons for the decision, including, for example, an analysis and explanation of how the balancing test was applied (if applicable). Additionally, in its response, the Contracted Party MAY include information on how public registration data can be obtained.

01:27:19
Yup. No essays, no legal memos.

01:29:16
@Brian: Good catch.

01:29:31
Thanks Brian!

01:29:49
@Dan, you bet. Good catch.

01:33:10
So delete the extra step?

01:33:53
Yes

01:34:30
@Chris: Would you mind speaking closer to your mic?

01:34:40
Much better. Thanks. :-)

01:36:02
7.2.1

01:37:06
Do we just need to delete the word further?

01:37:40
Marika here is some proposed language for the first open question:

01:38:03
“In all instances when a request is approved or denied, the CP will send to the CGM a simple indicator of the reason for the decision

01:38:07
"

01:38:50
Agree that we should delete the word "further" to avoid assuming that balancing test is always required.

01:39:37
Marika, have you hired come crickets for the background noise on your line?

01:40:46
Just to give you a change from the bird sounds :-)

01:41:06
:-)

01:41:19
the Marika insect orchestra! Great concept

01:45:00
is required (by whom?)

01:45:01
@Dan: A Chinese CP determining its lawful basis is also consistent with the Policy.

01:45:06
@Thomas: +1

01:46:11
+1 Thomas

01:46:14
Very much agree with Thomas.

01:47:09
Precisely Thomas. This was supposed to be a global policy at the level of the GDPR. What is required here may be something like, “For greater clarity, under no circumstances would an individual lose the protection of this policy for their personal data, should they and the data controllers be operating from jurisdictions without data protection.

01:47:28
Dan, are you in effect proposing geographic differentiation?

01:48:10
Hello Milton. No, I am not.

01:48:59
The contract of course - would also be a legal basis - for those places not covered by a 'legislative enactment'.

01:49:09
@AlanW: +1

01:49:27
CPs *are* allowed to make geographic distinctions. I think this edit removes that discretion

01:49:38
As Janis likes to consistently remind us, the first “S” in SSAD is “Standardized”.

01:49:38
This was the whole idea. You are required by contract to meet a GDPR based policy

01:49:51
@Thomas: +1

01:53:37
@Margie @AlanG: Are we finally agreeing that the phase 1 rec is about treating registration data differently, and not only being limited to redaction? ;-)

01:54:21
Ala, I thought ALAC was supposed to be advocating for individual internet users, regardless of their jurisdiction

01:54:33
AlanG

01:55:52
But all registrants are individual internet users

01:55:59
@Volker: +1

01:56:44
Thanks Volker. Language like that would solve our question.

01:57:16
@Milton, IBM Corp is a registrant but not an indiv. Int users.

01:57:50
IBM corp is not an individual internet user. Amazing that I have to explain the individual basis of representation in AL to someone in ALAC

01:58:22
Corps and businesses are represented in constituencies/SGs. The whole point of AL was to represent individuals.

01:58:37
Perhaps replace proposed language with "if applicable"? MUST determine its own lawful basis, "if applicable". . .

01:59:07
@Milton, I was reacting to your statement that ALL REGISTRANTS ARE INDIV INT. USERS.

01:59:13
+1 Laureen

01:59:26
“From Alan Greenberg (ALAC) to All panelists: (11:20 AM)
+1 Margie.
@Stephanie, but not all registrations are subject to GDPR.” The whole point of this policy, is that all registrations will be subject to this policy, which will set the bar at the GDPR.

01:59:58
And AlanG I am explaining to you that you seem more concerned with IBM than with individual internet users.

02:00:29
Otherwise, we will be encouraging all lazy contracted parties to operate from Turks and Caicos. Or some other jurisdiction unlikely to pass DP law, or enforce it.

02:00:57
Apologies as I will need to drop in about 10 minutes

02:02:27
Or is not prohibited from disclosing?

02:02:43
The way I read the suggestion: If there is no privacy law, no legal check whatsoever needs to be applied. Are we really ok with potentially not having any protection for certain registrants???

02:03:11
@Milton: +1

02:04:38
Thomas, exactly. We are not OK with that

02:05:24
And content on a website does not always equal domain name that the registrar is limited to…

02:05:38
Content is relevant to UDRPs

02:05:38
@Matt: +1

02:06:06
+100 Thomas. We will never agree to this

02:08:54
+1 James

02:10:16
@James: +1

02:10:34
If we have already agreed that IP cannot be a blanket reason for denial, why do we need the ‘content’ phrasing? IP issues relating to content are still IP issues.

02:12:03
@Milton: Exactly!! +1

02:13:01
you already have that right under DMCA, Mark

02:13:09
you don’t need the SSAD

02:13:25
The web host does not have the RDS data

02:13:26
Temp spec already covers that Marc SV - disclosure is not necessary to contact the registrant.

02:13:46
registrars are required to forward on that message.

02:13:49
DCMA does not apply universally. We are not talking about right, we are talking about ability.

02:14:22
@MarkSV: We’re not saying that you can’t contact a website admin over infringing content. Just saying that unless there is an infringement in the domain name string itself, you need to find another way to initiate contact other than having registration data disclosed to you.

02:14:36
They can pursue all kinds of legal remedies without the RDS data, including takedown under DMCA

02:14:55
I need to drop now

02:15:18
That's abuse management - not IP

02:15:23
oh .. what james said

02:15:37
@James content is relevant in case of DNS abuse (Phishing)

02:15:50
Phishing & IP are linked

02:16:13
The phishers need to use the IP or copyrights to trick the consumers

02:16:15
No one here is suggesting we aren’t following those policies @Alan

02:17:45
@Volker: Exactly!!

02:17:53
I will also point out, this was a subject that was very strongly opposed to by members within the RrSG…

02:17:55
One idea: delete the rest of the recommendation starting with “…nor can the disposition …

02:18:55
Plus a URS/UDRP can be filed without the disclosure (again phase I) - the content does not become more relevant or less by knowing who the registrant is? Unless of course you don't communicate with your own company and it turns out to be you …. which … is bad management and policy … we can't solve for that at ICANN.

02:19:43
I *think* Margie’s idea is ok...

02:19:48
and none of that prohibits us from doing the disclosure anyway

02:19:59
That sounds ok to me, but thinking on my feet right now.

02:20:12
sounds ok

02:22:36
https://docs.google.com/document/d/17gGzz6K-zKuSK71FluHCowZo3p6tFEd3/edit

02:31:37
I appreciate Amr's motivation. But the GGP was not acceptable because of specific details of how a GGP is created and how its Recs are handled. By not having those details specified for the Standing Comm, we are left with unknowns whether it devolves into something equivalent to a GGP or is very different.

02:31:40
Let’s move the discussion on Rec 19 to tomorrow, we are not going to accomplish anything today

02:33:24
The point is that it is practically extremely difficult to block a topic being introduced to this committee.

02:34:17
Thanks all…same time, same place tomorrow…

02:34:39
Thank you all - bye for now

02:34:42
Without knowing HOW the output of the SC will be addressed, we do not know if it is acceptable or not.