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

https://docs.google.com/document/d/1-f9Ml-z9LcxVs9WuX53kIkp29j0JLh6d/edit

it is the only PDP in the list :)

i believe it is a boiler plate also

ODP is on ICANN’s side, so we do not add it here

PDP provides recommendations

that is it

before the implementation

I think that would be the “Implementation Guidance” for the IRT?

The GNSO Operating Procedures include at least: “The PDP Team should carefully consider the budgetary impacts, implementability, and/or feasibility of its proposed information requests and/or subsequentrecommendations.” It might make sense to make the language a little more general.

@Steve - right.

So it is not an IRT, but the PDP WG itself

the PDP WG should be very highlevel and the IRT would have more details

@Edmon - Yes. The theory is that the Council needs that information before approving it

[As does the Board]

agree

Under deliverables, it could just say at a minimum?

Yeah

We can make that revision

B/c draft Final Report is noted as optional in the Ops Procedures.

https://gnso.icann.org/sites/default/files/file/field-file-attach/annex-4-epdp-manual-24oct19-en.pdf

from what i understand and what i see from the link its mostly focused on the initial report

i mean the difference

yes as jeff said, its just same as pdp manual

For the avoidance of doubt, the following sections of the PDP Manual shall not apply to an EPDP:Section 2 (Requesting an Issue Report);Section 4 (Recommended Format of Issue Report Requests);Section 5 (Creation of the Preliminary Issue Report);Section 6 (Public Comment on the Preliminary Issue Report); andSection 7 (Initiation of the PDP)Except as otherwise expressly modified or excluded herein, all other provisions of the PDP Manual shallapply in full to an EPDP, including without limitation the publication of an Initial Report for publiccomments. In the event of a conflict in relation to an EPDP between the provisions of the PDP Manualand the specific provisions in this EPDP Manual, the provisions herein shall prevail.

Bad cut and paste job, but here is some relevant text

….from the EPDP Process Manual

Yeah, the naming is messed up. It really should be a PDP Manual with an Annex on ePDPs. The reality is that there are many sections of the PDP Manual that are incorporated by reference into the "ePDP Manual", so they need to read both anyway

I kind of agree with Maxim. I think we should make it clear that we seek experts from the Registrars to help us answer these questions.

also ‘same registrant’ does not allow to fully understand if it is all entities … so it should be just same entity

new hand

ROIDs are too deep inside of the platforms

Agreed, Maxim

i thought this is what we task staff to do to provide to the WG?

and potentially interfere with GDPR (identification of a person)

I support Jeff in this

I agree with Jeff that the WG should determine what data is needed

new hand

*Might* be needed is a good way to describe it. It’s not intended to be limiting, but it’s an attempt to set the EPDP for success from the start.

Could be helpful to recommend data that the WG might need but let the WG to determine the data they will ultimately use

ROIDs here are tied with the personal data, we do not need to mix the current endless EPDP here

it will add a really toxic item to the PDP

i agree with jeff

Not defending the data point here, Maxim. But the ROID question here is qualitative: do you reuse it or not, and it is not seeking to disclose contact data behind the ID

@Dennis, it is closed info, Registriars do not have to share it, it gives out info, which might be abused

I still believe that it should be included as a Deliverable. I read the PM section, but it is unclear as to what is expected.

if the burden of proof of the same entity is on the entity - we do not need to check ROIDs e.t.c.

something like ‘what technical methods could be used to establish the same entity - in the same Registrar system, across different Registrar’s systems (the latter is toxic from the GDPR perspective though)

old

If the Council expects a Work Plan to be delivered to it, then perhaps that should be included as a "Deliverable". The other PM elements are not Deliverables from the Working Group, but are tools to manage the process. I would remove the Placeholder text completely under the Project Management section

Dennis, I don't think you need to read these. I think we can move on

I read this one minute too late :)

one couple of scripts which are variants is enough

new hand

new

open part of group is free to organize itself

attendance and/or participation is an obligation of WG members

see you all at ICANN70 zooms

thanks all

Thanks everybody!

thx bye