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

Members: lease select all panelists and attendees in order for everyone to see chat. Attendees and note, the raised hand option has been adjusted to the bottom toolbar.

https://docs.google.com/spreadsheets/d/17qLMYb3HC7qGYPQveXbUq5ZSzvedrQ3t8AdVdrRIdrw/edit#gid=0

I'm sorry, what is the WBS column?

I am the human sacrifice of the RRSG to the legal team

Thanks Berry. I continue to marvel at and try to learn from your spreadsheets

Since the Council meeting is later today, we're hopeful we can do the approval over the Council mailing list as to expedite this task.

Sorry, the CPH to provide an update on IRT status?

@Sarah - an update on the status of implementation of rec #6.

Thanks Marika

Link to goog doc: https://docs.google.com/document/d/1weQemSQ0-884ILbhmR3OLzUWouyGXMKH/edit

The aim of the yellow highlighted text was to translate the input provided in the comments. But of course, if we’ve missed something, please speak up.

+1 Marc

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

Especially those definitions that were derived from legal committee materials :-)

@marika it makes sense reviewing these definitions first by the legal committee

we need to be clear on the definitions in order to be clear on the legal impact

I'm troubled by the idea of creating a definition with the goal of a specific outcome (correlation)

@Melina, I agree anonymized in relation to whom?

It will be important to ensure definitions we agree on are used not only during our work in the EPDP but also in the IRT and beyond.

Agree Sarah.

To Milton's point, I would draw the team's attention to the CPH suggested problem statement, lower down in this document

agreed sarah it is all about what problem we are dealing with and what is the acceptable way to solve it

it cannot be published

if it is not anonymized

Agree, email is there as an option. I think our job here is to provide guidance on how one could implement an email address while adhering to data protection requirements. Not to require an email address in all cases.

agree Sarah

link to instructions from GNSO council that Sarah mentioned:https://community.icann.org/pages/viewpage.action?pageId=150177878

Lost Markia there

+1 Margie we need some more time to react to this

i would love that if we just follow what Bird & Bird suggested as definitions in their legal memo: if its the same email used for multiple entries from one person, its pseudynomized; if it's one address for one entry and never repeated, it's anonymized. why did we ask for legal advice and not listening to them?

+1000 Manju

I ask the same thing about the advice provided with regard to the Legal/Natural issues ;-).

+1 ALan

“uniform” means the same for each individual registrant?

Are there forms that do not comply with the policy requirements set out in phase 1?

Is that the issue? noncompliance?

"contactability" without being able to fill in a web form is a glorified Facebook poke

If the form is not being relayed that's certainly a Compliance problem

Seems like we have heard a lot from stakeholders telling us this is a problem

I don’t see any driving of us toward conclusions, quite the contrary

I see endless repetitions of the same debate and no motion toward conclusion. unfair to suggest Keith’s handling of this is biased

As recommendation #13 is still in the implementation phase, doesn’t further guidance on web forms not belong in the IRT discussions?

agree Marika

obviously an IRT issue

Folks, I just sent a sample relay to the ePDP list. These forms (at least at my Registrar) are functioning as intended. If other registrars cannot provide the same functionality, it should be raised with Compliance.

Where a Registrar redacts the data element values listed in Section 10.3.1.8 or 10.3.1.12, in lieu of “REDACTED”, Registrar MUST Publish an email address or a link to a web form for the Email value to facilitate email communication with the relevant contact, but MUST NOT identify the contact email address or the contact itself. [Rec 13]

We have the Webinar next Tuesday on L vs. N, and yes the agenda next Thursday will focus more on that topic.

@Keith -- much appreciated. Want to make sure we have sufficient opportunity to deal with both anonymized emails and the treatment of legal information.

@James: missing from many registrars' forms is the possibility of "facilitating email communication" - surely merely delivering a non-message via email as a protocol does not achieve the intended outcome of being able to write an email to the registrant

happy to move along for today, and unfortunately I need to drop at the top of the hour. Thanks all.

Good points, Sarah.

That is maybe a thing that could exist but it certainly does not at this time

(Alan G's suggestion)

There is no reason for it to exist

That’s right Sarah- we can certainly talk about whether it should be addressed in the policy

Right - it goes back to agreeing on a problem statement and what is in scope for this phase

@Milton - as mentioned earlier, it essentially becomes a “tracking cookie” for the DNS

exactly, so why are we considering it

That is a huge conflation of client data and registrant data -

We are talking about the latter only surely?

I'm not sure what this has to do with our work here, but maybe that's because the problem statement is as yet unclear

And, didn't James just explain that in some privacy/proxy services we see pseudonymization in the public-facing email address? I do think that's a good example

so as I predicted, Margie is arguing for correlation, this is really about correlation, not about the definitions

Is revisiting the SSAD response requirements in scope for this phase?

You mean by subpoena?

so if we want to make progress, we have a debate about whether correlation of published contact data is legal.

if you can get it upon request that means you’re getting from the SSAD? what is it to do with publishing?

Good question there Manju

@Mark Thanks so it is the domain name that generates (has generated) another unique string that stays with it.

We need to understand if this is in scope

My hand is up

Also where data is released via the SSAD - this undermines all anonymization and psedonymization - we need to consider the ling tail of such efforts with all processes considered - not just the mere act of ‘correlation’

*long

+1 Alan

RIght! I thought our job here was to provide guidance on how to do this pseudonymization or anonymization properly, for those cases where the CP has decided to do so according to Rec 13

ENISA: “there is still a large threat of re-identification..."

Agree = IF published, how to do it right

Sounds like Laureen is agreeing that pseudonymized email is a major identification risk and special measures would be needed to reduce risks.

Hi folks…need to drop a few minute early. Thanks.

+1 safeguards are required and just to note there is no such thing as risk free and DPAs are not looking for 100% anonymization

Laureen was talking about reducing risk through pseudonymized emails -- which make sense.

+1 Margie

Perhaps a bit more nuanced Milton -- I agree that the real issue is how to mitigate the risk of identification IF the anonymized/pseudonymized data is published.

Thanks Marika for the clarification. Yes, the guidance from Council, not just the original charter.

https://docs.google.com/document/d/1e2-rVF2wh-821tct76O50QdWwn4ZcIqS/edit#heading=h.gjdgxs

https://docs.google.com/document/d/1QlM4O_vwx7cQ11DJ_Lx2kqhyyRgDkMXG/edit#heading=h.gjdgxs

to the list.

Thanks, all

Thank you all - bye for now

Thank you all!