Logo

051040043 - EPDP-Phase 2A Team Call - Shared screen with speaker view
Terri Agnew
37:56
Please review ICANN Expected Standards of Behavior here: https://www.icann.org/resources/pages/expected-standards-2016-06-28-en**Members: reminder, when using chat, please select all panelists and attendees in order for everyone to see chat.
Hadia Elminiawi (ALAC)
44:13
A combination of both which ever happens first
Brian King (IPC)
45:12
+1 Margie
Stephanie Perrin (NCSG)
51:27
I trust that regulatory developments would also include noteworthy privacy cases or amendments that would serve to strengthen data protection?
Marc Anderson (RySG / Verisign)
51:29
RrSG CommentChange to: "relevant legislative changes (for example, NIS2)"
Hadia Elminiawi (ALAC)
51:56
+1 it should not be tied to one specific regulation
Stephanie Perrin (NCSG)
52:05
(Speaking with disingenuous naïveté)
Caitlin Tubergen
53:54
@Marc A. - the RySG-suggested change noted above has been applied to the latest version.
Marc Anderson (RySG / Verisign)
54:27
@cailtlin - do you have a link to the latest version
Caitlin Tubergen
55:10
https://docs.google.com/document/d/1_k0hVA6c2SvQPLiaZAlUllTKdplssofYlRHDkeR4mJ8/edit#
Marc Anderson (RySG / Verisign)
55:31
@caitlin - thank you
Brian King (IPC)
56:06
well said, Margie
Brian King (IPC)
58:42
Also agree it's wise not to limit the trigger to NIS 2 explicitly
Margie Milam (BC)
01:01:34
Review Teams don’t usually update consensus policies
Stephanie Perrin (NCSG)
01:02:47
Thanks Alan for that clarification, I had not been following!
Stephanie Perrin (NCSG)
01:03:33
Margie, understood. They can however review the effectiveness of the policy, evaluate current conditions, and make recommendations to the Board, no?
Stephanie Perrin (NCSG)
01:04:09
An effective review mechanism, in my view, is better than a never-ending pdp
Hadia Elminiawi (ALAC)
01:10:16
It needs to be identified similar to phase one fileds
Hadia Elminiawi (ALAC)
01:10:23
fields
Brian King (IPC)
01:10:42
Connecting this to the way we treated various fields in Phase 1 seems to make sense to me
Marc Anderson (RySG / Verisign)
01:11:56
https://www.icann.org/en/system/files/files/rdap-response-profile-15feb19-en.pdf
Steve Crocker (SSAC)
01:12:49
The data dictionary should be Internet wide, not specific to ICANN contracts.
Hadia Elminiawi (ALAC)
01:14:21
@Marc so why not standardize
Steve Crocker (SSAC)
01:14:44
Agreed: whether the value of the field is disclosed is distinct and separate from the existence of the field.
Margie Milam (BC)
01:17:10
+1 Alan G
Hadia Elminiawi (ALAC)
01:18:01
If SSAD is used the standard would reduce the time and effort required for disclosure
Steve Crocker (SSAC)
01:18:09
@Alan: It’s much better not to conflate the value of the field and its associated disclosure rules. Keep these distinct.
Alan Greenberg (ALAC)
01:18:41
@Steve. Agreed. That is what Phase 1 did.
Hadia Elminiawi (ALAC)
01:19:28
common sense says we should treat this field like other phase one fields
Alan Greenberg (ALAC)
01:20:42
I note that we are EXPLICITLY saying that there is no obligation to fill in the field, so notihng will be revealed that is not desired.
Stephanie Perrin (NCSG)
01:20:47
+1 Steve. Remember that establishing a field for the purpose of disclosure would be rather problematic in data protection terms, particularly if it were not easy to implement and therefore prone to wrongful disclosure
Stephanie Perrin (NCSG)
01:21:47
I do understand that I am speaking at cross purposes to the trend here. I am looking at the matter from the perspective of data minimization, and limited specific disclosures.
Steve Crocker (SSAC)
01:21:49
Phase 1 only specified which data elements would be “public”. In principle, data which is not “public” might be subject to further distinctions regarding who is allowed to see them. (The quotes around “public” are included to emphasize that *none* of this data is actually published in the usual sense of that word. All of the data is accessed through a request and response system.
Amy Bivins (ICANN org)
01:23:20
On the implementation side, ICANN org would need to know whether the EPDP Team intends for a new field (required or optional, public or redacted) should be added (e.g. as an update to CL&D and the RDAP profile)
Steve Crocker (SSAC)
01:25:46
@Amy: The ICANN contracts should refer to fields defined in a standard dictionary of data elements.
Alan Greenberg (ALAC)
01:26:26
A data filed does not BELONG to anyone.
Berry Cobb
01:27:29
hand raised
Keith Drazek (Chair) (Verisign)
01:27:55
Berry you're next
Tara Whalen (SSAC)
01:31:30
I need to drop for another meeting at this point, handing off to Steve C for SSAC. Thanks, all!
Alan Greenberg (ALAC)
01:32:02
Thank you Berry.
Brian King (IPC)
01:34:02
Flagging that a binary requirement would not facilitate existing registrations.
Brian King (IPC)
01:34:17
and Bingo was his name-o
Keith Drazek (Chair) (Verisign)
01:35:46
The term "unknown" does raise the question, "unknown by whom?" The registrant? The registrar?
Sarah Wyld (RrSG)
01:35:59
"not set" ?
Berry Cobb
01:36:00
As an example:
Berry Cobb
01:36:01
Registrant Legal Person: YesRegistrant Legal Person: NoRegistrant Legal Person: Not-Specified
Brian King (IPC)
01:36:31
I've said it before, but we are lucky to have Berry
Keith Drazek (Chair) (Verisign)
01:36:38
+1
Hadia Elminiawi (ALAC)
01:36:59
+1 Brian - thanks Berry
Berry Cobb
01:37:02
Hand raised
Steve Crocker (SSAC)
01:37:02
@Alan: I’m sorry to disagree. There is an important difference between an empty field and a value of unknown. What to display is another matter, but the underlying semantics are different.
Stephanie Perrin (NCSG)
01:37:27
The NCSG position is certainly that the third field must exist and must be unspecified. I think it is useful, potentially, to have a third choice, unspecified, but I of course don’t work with these fields on a daily basis. I fear that empty simply looks like an omission or error.
Berry Cobb
01:37:40
hand raised
Keith Drazek (Chair) (Verisign)
01:37:47
Berry you're next
Alan Greenberg (ALAC)
01:37:49
@Steve, yes, they are different. And I am using that difference for what I am recommending.
Brian King (IPC)
01:39:44
+1 Stephanie
Keith Drazek (Chair) (Verisign)
01:42:06
Thanks Velimira!
Berry Cobb
01:42:11
Correct: Tech Contact is "Optional" as a service offering.
Steve Crocker (SSAC)
01:42:44
And if it’s offered, it would be helpful to say what it means
Berry Cobb
01:43:37
If the Rr chooses to offer it, then they must further process.... meaning that they are displayed in the min. public data set, but may be subject to redaction requirements.
Hadia Elminiawi (ALAC)
01:43:41
yes we can hear you
Terri Agnew
01:43:49
@Velimira, we can hear you.
Alan Greenberg (ALAC)
01:45:11
First we are trying to ensure that the fdield exists. THEN we can debate whether it must be used.
Brian King (IPC)
01:45:52
+1, Velimira's point makes sense
Sarah Wyld (RrSG)
01:54:54
I thought the memo was sufficient and understandable for average-ish readers, but if anyone does want to propose guidance I'm certainly open to reviewing it.
Marc Anderson (RySG / Verisign)
01:56:11
thank you for the clarification @Keith
Keith Drazek (Chair) (Verisign)
02:02:24
New hand, Alan?
Alan Greenberg (ALAC)
02:02:36
Yes
Stephanie Perrin (NCSG)
02:04:04
Why do we the volunteers have to work the weekend?
Stephanie Perrin (NCSG)
02:04:36
+1 Alan G
Stephanie Perrin (NCSG)
02:06:11
A gentle reminder that we will need to get consensus from our groups, over the weekend.
Stephanie Perrin (NCSG)
02:06:36
It being unfair to ask members to respond to draft reports that might change at the last minute.
Alan Greenberg (ALAC)
02:06:38
Last Question. Will the 40 days pause for the June ICANN meeting as is the norm?
Brian King (IPC)
02:08:21
+1 Margie
Terri Agnew
02:08:21
Next meeting: The GNSO Temp Spec gTLD RD EPDP – Phase 2A call is scheduled on Thursday, 20 May 2021 at 14:00 UTC for 90 minutes.
Hadia Elminiawi (ALAC)
02:08:35
Thank you all. bye for now
Brian King (IPC)
02:09:13
thanks all