2018-07-09 Small team EPDP scope/composition call

Notes/ Action Items

Action Items and Notes 

BC is still uncomfortable with a phased approach, but would perhaps be OK with a staggered approach.  We should not put in an artificial deadline or barrier to doing the work for access.  In scoping the charter, we should not say the EPDP Team cannot discuss access until the Initial Report.  If there is time and motivation and the gating questions have been answered, the EPDP team should begin the work.  Questions about RDAP have been answered.  BC position: allow the EPDP Team to figure out how much work they can get done rather than set up arbitrary barriers from the beginning.

Others are OK with using “staggered” instead of “phasing”.

The new document is hard to follow.  In some cases, the comments do not line up with the appropriate body text, so it is difficult to follow.  Confirming all IPC comments are in the new document.  We may be losing ground.  Suggest going through this document line by line sooner rather than later.  Perhaps we should revert back to the document where everyone put their comments in.

Concerned we have not looked at the IPC comments in any detail.

Language has been added regarding questions the EPDP team would need to consider with respect to the temp spec with an eye toward the task of the group to certify, reject or replace the temp spec as consensus policy or not.  The decision we need to make is the temporary spec vs. what is in the annex – from that, things become clearer.  If we can answer the question of the staggering of the work, the path forward is more obvious.  In terms of an arbitrary deadline for the staggering of the work, it is critical that the group focuses on the temp spec, making sure the Initial Report is published within the next 8-10 weeks to meet all of the timelines required.  Access will be discussed as part of the temporary specification.  The gating questions must be addressed and the focus on the temp spec an initial report is critical.

BC would like access to be part of the Initial Report.

The Temp Spec has a 12-month window associated with it.  How we have established the timeline in the EPDP - initial report needs to confirm or not the Temporary Specification.  We also need to account for the staggered approach - the things that fall outside the time pressure -- what would that timeline look like for the rest of it to be completed? 

There is time pressure on access.  Contracted parties have contract pressure, but there is a lot of work that cannot happen because there is no access.  The other issue is trust.  There is no trust that if access is pushed to the end completely that we will have a model at all in the next 12 months.  If we allow the EPDP team to choose how they’re going to work on this and give them some rules (such as gating questions), if they happen to get through the gating questions quickly and there are parts of the team that would like to push forward and work on access, they would not be limited by the charter.

We first have to get through the primary questions before we move to the matter of access, which is what we decide once we decide purposes and legality.  Fixing the Temporary Spec and getting the primary questions settled needs to come first.  The EPDP Team cannot focus on data access to third parties as the primary question.  Registrars are obliged to give access, just not illegal access.  We are setting ourselves up to fail again if we begin with access. 

If we can all agree on the gating questions that would inform the work of the access discussion, we can acknowledge that in the charter.   Let's call out the questions rather than calling out an arbitrary deadline.  Rather than the initial report being the pivot point, we should include the questions that must be answered for the EPDP team to begin discussing access.  We can’t build the access model until basic questions have been answered.

The scope of this EPDP has to be focused on the temp spec, in that we are looking at a staggered or phased approach.  The previous proposal was not to touch the access model design until the Initial Report.  A compromised path forward may be to identify the gating questions that must be answered as part of the temp spec discussion before we move into the access design, but it does not have to be pending the publication of the Initial Report.  Once the gating questions have been answered, a parallel effort on access design can be undertaken.

There may be a false dichotomy between temp spec and access: perhaps we are saying access is in the temp spec, but there are some questions that need to be answered before the design of the access model can be started.

We keep saying "after we deal with the temp spec, then we can deal with access."  Perhaps you are trying to draw a distinction b/w what is in the temp spec.  Let's not use the word access as a catch-all for concepts in the annexes, since access is in the temp spec.  The team needs to start going through this document line by line and see if the group has any concerns with proposed changes made.  Also suggest an additional call tomorrow.

Where we are: The group needs to go through the IPC comments as we have not had the opportunity yet.  There is a note within Phase 1 that says questions that are gating to Phase 2 and review or take out this language in some way.  Take out this language and not refer to Phase 1 or Phase 2 within the scope. 

IPC comments: First comment: in the mission and scope, we appear to be missing a principle of why we are doing this.  The IPC suggests we should add after ICANN consensus policy: This

EPDP Team is being chartered to determine, at a minimum, if the Temporary Specification for gTLD Registration Data should become an ICANN Consensus Policy, as is or with modifications, in accordance with the mandate to collect data set forth in ICANN’s Bylaws and the related principle of ensuring continued availability of the WHOIS service to the greatest extent possible and other processing of gTLD registration data while complying with the GDPR and avoiding fragmentation of WHOIS. As part of this determination, the EPDP Team is, at a minimum,

expected to consider the following elements of the Temporary Specification and answer the charter questions below. The EPDP Team shall consider the impact of its responses to these questions on any existing consensus policies, which shall be preserved in accordance with the principle above we should do our best to not do away with other consensus policies that are already in place (have as small a footprint as possible).

The IPC believes the principle should we require parties to collect data to the extent possible without violating GDPR.   Also, the EPDP Team cannot do this in a vacuum, and the decisions the team makes could affect other consensus policies – we should do our best not to affect other consensus policies and leave as small a footprint as possible.

Disagree with the proposed addition, and if you are trying to keep WHOIS as is, this will be problematic.  Response from the document: This suggested replacement paragraph raises so many issues that NCSG has historically contested, that it would be simpler to dump it and stick with the original above. To enumerate a few: 1. The "mandate to collect data" was set by the US govt, in the US, and is overbroad when viewed in the context of other countries' data protection laws. It has been in contention from the inception of ICANN. 2. We disagree with the goal of maintaining the WHOIS service to the greatest extent possible. WHOIS is dead. 3. Avoiding fragmentation of WHOIS....does not make sense. RDAP permits much greater articulation and specificity of data access, and avoids dataflow that violates DP law. 4. Preserving existing policies? Why? Data practices at ICANN have long been non-compliant

with DP law. Existing policies such as data retention, the thick transition, the [ridiculous] WHOIS conflicts with law do not map to data protection law requirements, and put contracted parties and ICANN at risk, not to mention ignoring the rights of registrants. Please, if this is the kind of intervention we are going to get all the way through this EPDP, we will never finish. Just drop this paragraph.

Can we take the fragmentation of WHOIS out?

The proposed principle of no fragmentation of registration data may be a sticking point, so to the extent others are open to taking this out, that may be helpful. 

Are there benefits of fragmentation that are not thought of in the IPC comments?  It is hard to imagine taking this out unless others can set forth reasons why it should come out.

Under question b1) Should registrars continue to collect contact data for Registrant, Tech, Admin and Billing contacts?  IPC does not think this is a useful question to ask. Instead this should be: Is there a legal reason registrars should not continue to collect all data elements for each contact?

This question about admin, billing, and tech, this is under legal consideration now.  This is not a question of preference, it is a question of what is legal and that will be based on what is the purpose and what is legal to display or to transfer or to provide access to based on that purpose.  

No verbal objections to proposed changes in b2 and b3.

e) remove Compliance - keep it just "ICANN".  No objections.

e2 insertion) Should ICANN act as the primary manager?

Concerns about this proposed language (e2): this jumps too far ahead for purposes of this discussion.  This proposed language makes assumptions we should not be making at this point.  This may be something to consider later, but it’s not appropriate for this part of the charter.

Perhaps earmark e2 as a later question for the discussion.

There appears to be a fundamental concern with the proposed e2 language, so perhaps we should park this issue for now.  Perhaps IPC could look at rephrasing. 

IPC – note for the larger group that this potential solution was suggested, but there was not consensus in the smaller EPDP scoping team to include it.

j) remove capitalization for all references to Uniform Access Model.  The capitalization seems to indicate this notion is more concrete than it is. (No objections.)

Insert j2)  “Under Section 4 of Appendix A of the Temporary Specification, what is meant by “reasonable access” to Non-Public data and what criteria must CP be obligated to consider in deciding whether to disclose Non-Public Registration data to an outside party requestor? Who determines the scope of, and method for, “reasonable access” and the specific criteria for such access? What are the criteria for determining if a legitimate interest of the outside party outweighs the interests of the registrant, and what criteria need to be considered to determine if the legitimate interest of the outside party overridden by the interests or fundamental rights or freedoms of the registrant? What are exemplar scenarios for each of the foregoing?" This gets to the heart of comparing the legitimate interest of the outside party vs. the fundamental rights of the registrant.

Attempting to get around the individual needs of the request.  You cannot have a one-size-fits- all.  We need to come up with specific types of inquiries.  This is why it will take a while to come up with an implementation model.  Trying to put that language into the scoping document will not work.

j2) concerns about the inclusion of this.

Concerns about inclusion of proposed j6.  We need to be cautious about including this level of language in the charter.  This does not recognize the importance of the gating questions that we have described or the tiered access approach.  These individual use cases and requestors of data will be on a spectrum.  The group needs to be cautious about including this level of language in the charter.  We need to focus first and foremost on questions coming up with questions of legitimate use based on the various types of requests.

Action item: Caitlin + Donna to review this document, taking into discussion the conversation we had earlier regarding phased approach. 

OK with removing Phase 1 and Phase 2 language as it appears the group agreed to this, subject to agreement on the gating questions, noting this is a significant departure from initial positions of the contracted parties.