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.

A combination of both which ever happens first

+1 Margie

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

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

+1 it should not be tied to one specific regulation

(Speaking with disingenuous naïveté)

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

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

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

@caitlin - thank you

well said, Margie

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

Review Teams don’t usually update consensus policies

Thanks Alan for that clarification, I had not been following!

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

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

It needs to be identified similar to phase one fileds

fields

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

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

The data dictionary should be Internet wide, not specific to ICANN contracts.

@Marc so why not standardize

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

+1 Alan G

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

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

@Steve. Agreed. That is what Phase 1 did.

common sense says we should treat this field like other phase one fields

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.

+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

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.

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.

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)

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

A data filed does not BELONG to anyone.

hand raised

Berry you're next

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

Thank you Berry.

Flagging that a binary requirement would not facilitate existing registrations.

and Bingo was his name-o

The term "unknown" does raise the question, "unknown by whom?" The registrant? The registrar?

"not set" ?

As an example:

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

I've said it before, but we are lucky to have Berry

+1

+1 Brian - thanks Berry

Hand raised

@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.

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.

hand raised

Berry you're next

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

+1 Stephanie

Thanks Velimira!

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

And if it’s offered, it would be helpful to say what it means

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.

yes we can hear you

@Velimira, we can hear you.

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

+1, Velimira's point makes sense

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.

thank you for the clarification @Keith

New hand, Alan?

Yes

Why do we the volunteers have to work the weekend?

+1 Alan G

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

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

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

+1 Margie

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.

Thank you all. bye for now

thanks all