
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.

44:13
A combination of both which ever happens first

45:12
+1 Margie

51:27
I trust that regulatory developments would also include noteworthy privacy cases or amendments that would serve to strengthen data protection?

51:29
RrSG CommentChange to: "relevant legislative changes (for example, NIS2)"

51:56
+1 it should not be tied to one specific regulation

52:05
(Speaking with disingenuous naïveté)

53:54
@Marc A. - the RySG-suggested change noted above has been applied to the latest version.

54:27
@cailtlin - do you have a link to the latest version

55:10
https://docs.google.com/document/d/1_k0hVA6c2SvQPLiaZAlUllTKdplssofYlRHDkeR4mJ8/edit#

55:31
@caitlin - thank you

56:06
well said, Margie

58:42
Also agree it's wise not to limit the trigger to NIS 2 explicitly

01:01:34
Review Teams don’t usually update consensus policies

01:02:47
Thanks Alan for that clarification, I had not been following!

01:03:33
Margie, understood. They can however review the effectiveness of the policy, evaluate current conditions, and make recommendations to the Board, no?

01:04:09
An effective review mechanism, in my view, is better than a never-ending pdp

01:10:16
It needs to be identified similar to phase one fileds

01:10:23
fields

01:10:42
Connecting this to the way we treated various fields in Phase 1 seems to make sense to me

01:11:56
https://www.icann.org/en/system/files/files/rdap-response-profile-15feb19-en.pdf

01:12:49
The data dictionary should be Internet wide, not specific to ICANN contracts.

01:14:21
@Marc so why not standardize

01:14:44
Agreed: whether the value of the field is disclosed is distinct and separate from the existence of the field.

01:17:10
+1 Alan G

01:18:01
If SSAD is used the standard would reduce the time and effort required for disclosure

01:18:09
@Alan: It’s much better not to conflate the value of the field and its associated disclosure rules. Keep these distinct.

01:18:41
@Steve. Agreed. That is what Phase 1 did.

01:19:28
common sense says we should treat this field like other phase one fields

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.

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

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.

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.

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)

01:25:46
@Amy: The ICANN contracts should refer to fields defined in a standard dictionary of data elements.

01:26:26
A data filed does not BELONG to anyone.

01:27:29
hand raised

01:27:55
Berry you're next

01:31:30
I need to drop for another meeting at this point, handing off to Steve C for SSAC. Thanks, all!

01:32:02
Thank you Berry.

01:34:02
Flagging that a binary requirement would not facilitate existing registrations.

01:34:17
and Bingo was his name-o

01:35:46
The term "unknown" does raise the question, "unknown by whom?" The registrant? The registrar?

01:35:59
"not set" ?

01:36:00
As an example:

01:36:01
Registrant Legal Person: YesRegistrant Legal Person: NoRegistrant Legal Person: Not-Specified

01:36:31
I've said it before, but we are lucky to have Berry

01:36:38
+1

01:36:59
+1 Brian - thanks Berry

01:37:02
Hand raised

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.

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.

01:37:40
hand raised

01:37:47
Berry you're next

01:37:49
@Steve, yes, they are different. And I am using that difference for what I am recommending.

01:39:44
+1 Stephanie

01:42:06
Thanks Velimira!

01:42:11
Correct: Tech Contact is "Optional" as a service offering.

01:42:44
And if it’s offered, it would be helpful to say what it means

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.

01:43:41
yes we can hear you

01:43:49
@Velimira, we can hear you.

01:45:11
First we are trying to ensure that the fdield exists. THEN we can debate whether it must be used.

01:45:52
+1, Velimira's point makes sense

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.

01:56:11
thank you for the clarification @Keith

02:02:24
New hand, Alan?

02:02:36
Yes

02:04:04
Why do we the volunteers have to work the weekend?

02:04:36
+1 Alan G

02:06:11
A gentle reminder that we will need to get consensus from our groups, over the weekend.

02:06:36
It being unfair to ask members to respond to draft reports that might change at the last minute.

02:06:38
Last Question. Will the 40 days pause for the June ICANN meeting as is the norm?

02:08:21
+1 Margie

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.

02:08:35
Thank you all. bye for now

02:09:13
thanks all