[Gnso-epdp-team] Small Team A Meeting #1 - Notes and Action Items

Tue Jan 8 17:55:20 UTC 2019

Dear All, 

Please find below the notes and action items from today’s Small Team A meeting.

Best regards,

Marika, Berry, and Caitlin

Small Team A Meeting #1

Thursday, 8 January 2019

Notes and Action Items

Attendees:

Alan Greenberg (ALAC)

Alan Woods (RYSG)

Ben Butler (SSAC)

Chris Disspain (ICANN Board Liaison)

Diane Plaut (IPC)

Emily Taylor (RrSG)

Farzaneh Badii (NCSG)

Georgios Tselentis (GAC)

Julf Helsingius (NCSG)

Kavouss Arasteh (GAC)

Kurt Pritz (Chair)

Margie Milam (BC)

Matt Serlin (RrSG)

Recommendations Discussed + Proposed Small Team Approach

Recommendation #15

Initial Report Language: 

The EPDP recommends that for the new policy on gTLD registration data, the requirements of the Temporary Specification are maintained in relation to URS and UDRP until such time as these are superseded by recommendations from the RPMs PDP WG (if any).

Proposed Small Team Approach: 

The Small Team considered comments by URS and UDRP Providers (PCRT #9-10), and believe they merit further discussion with the plenary team. Please see PCRT comments 9 and 10 for further detail. 

Regarding comments about access to registration data for the purpose of assessing the merits of a UDRP Complaint (3, 5, 8, 11 of PCRT): The Small Team proposes to preserve these comments for the access discussion in Phase 2 - at which point the EPDP Team can decide if the concerns are appropriately within scope, and if so, how to address the concerns.

Recommendation #18 

Initial Report Language: 

The EPDP Team recommends that ICANN Org must enter into data processing agreements with dispute resolution providers in which, amongst other items, the data retention period is specifically addressed, as this will affect the ability to have publicly available decisions.

Proposed Small Team Approach: 

Having taken careful note of all public comments received on this recommendation, the Small Team proposes to remove the last clause from Rec. 18, noting it is out of scope for the EPDP Team. 

The proposed updated recommendation for consideration by the EPDP Team: The EPDP Team recommends that ICANN Org must enter into data processing agreements with dispute resolution providers in which, amongst other items, the data retention period is specifically addressed.

Recommendation #22

Initial Report Language: 

The EPDP Team recommends that as part of the implementation of these policy recommendations, updates are made to the following existing policies / procedures, and any others that may have been omitted, to ensure consistency with these policy recommendations as a number of these refer to administrative and/or technical contact which will no longer be required data elements:

• Registry Registration Data Directory Services Consistent Labeling and Display

Policy

• Thick WHOIS Transition Policy for .COM, .NET, .JOBS

• Rules for Uniform Domain Name Dispute Resolution Policy

• WHOIS Data Reminder Policy

• Transfer Policy

• Uniform Rapid Suspension System (URS) Rules

Proposed Small Team Approach: 

Having taken careful note of all public comments received on this recommendation, the Small Team noted it is premature to finalize the language of the recommendation at this time. The Small Team recommends the full EPDP Team revisit this language following its finalization of the Final Report to determine if the language needs to be amended, noting specifically the inclusion of administrative/technical contact may need amendment, and the list of Consensus Policies currently listed may need amendment.

Recommendation #6

Initial Report Language:

1. The EPDP Team recommends that ICANN Org enter into legally-compliant data

processing agreements with the data escrow providers.

2. The EPDP Team recommends updates to the contractual requirements for registries and registrars to transfer data that they process to the data escrow provider to ensure consistency with the data elements workbooks that analyze the purpose to provide mechanisms for safeguarding Registered Name Holders' Registration Data.

3. The data elements workbook that analyzes the purpose to provide mechanisms for safeguarding Registered Name Holders' Registration Data Registration Data contains the specifically-identified data elements the EPDP Team recommends be transferred by Registries and Registrars to data escrow providers (see Annex D). These data elements are: <see Initial Report>.

Proposed Small Team Approach:

The Small Team noted the specific data set to be transferred from the contracted party to the data escrow provider must be discussed in a plenary meeting. Following the EPDP Team’s agreement on the data set to be transferred, whether it is a full data set or a minimal data set, the EPDP Team should revisit the specific language of this recommendation, and should also include the agreed-upon data set within the text of the recommendation (instead of referencing a workbook). 

Recommendation #17

Initial Report Language:

The EPDP Team requests that when the EPDP Team commences its deliberations on a standardized access framework, a representative of the RPMs PDP WG shall provide an update on the current status of deliberations so that the EPDP Team may determine if/how the WG’s recommendations may affect consideration of the URS and UDRP in the context of the standardized access framework deliberations.

Proposed Small Team Approach:

Having taken careful note of all public comments received on this recommendation, the Small Team proposes to remove Recommendation 17 as an official recommendation, as this recommendation appears to be an action item instead of a policy recommendation. Instead, the Small Team proposes to preserve the language within the body of the EPDP Team’s Final Report and ensure the request is revisited during Phase 2 of the EPDP Team’s work.

Notes

Thanks to all for your flexibility as we try to work together to discern the best way review the comments. The leadership appreciates the feedback on the approach.
Hesitant to lose a meeting as there is such limited time left before our deadline for the Final Report.
This approach seeks to multiply the Team's capacity by reviewing the non-controversial recommendations with smaller teams.
As we think about how to move forward, we have to find a high bar that would cause us to reconsider the hard-fought compromises in the Initial Report. 
The ultimate goal is to be thoughtful and expeditious at the same time.

Today's Method:

1. Display the discussion table for the purpose/recommendation under review. (Note: the discussion table is a tool for discussion; it is not a replacement of the PCRT.)

2. 5 minutes of silent review of discussion table/PCRT

3.  Question for team:  which concerns merit group discussion? Specifically, do any of the concerns present new information the EPDP Team has not discussed during its formulation of this purpose or recommendation? 

4. Take time to highlight comments made by individuals or organizations who are not represented within the EPDP Team to ensure these voices are heard.

5. Discussion: 

a. Does the concern warrant a change to the purpose/recommendation? If so, the concern is [rationale provided by commenter], and a proposal to address the concern is [described in the comment].

b. If the team does not believe the concern warrants a change to the purpose/recommendation, why not? Answer may include, but is not limited to: out of scope for this EPDP, the EPDP has previously discussed this concern in its formulation of the purpose, recommendation, etc.

6. Closure where possible.

7. Support staff to document outcome of discussion and forward the outcomes to the full EPDP Team.

EPDP Team feedback:
Concern with this approach by the CPH: the time demand and cost of participation is raised with this approach.
Coordination is very difficult in the small team approach - feel very unprepared for this discussion.
We have two meetings - we need to get into the work.

a. Purpose 1 - Establish the rights of a Registered Name Holder 

b. Recommendation #15 - URS / UDRP

The EPDP recommends that for the new policy on gTLD registration data, the requirements of the Temporary Specification are maintained in relation to URS and UDRP until such time as these are superseded by recommendations from the RPMs PDP WG (if any).
You will note there was support for this recommendation across the board, but there some suggested edits provided.
Comments from URS Providers - the amendments seem practical and pragmatic - these are comments we should look to incorporate and make the suggested changes. (PCRT comments 9-10)
Sympathetic to the claims of looking for patterns or proving patterns of bad faith/reasonable use for UDRP; however, we are not in a position to rewrite these claims but we do not have a time to do a thorough review. Question to commenters: is there something we can do, without substantially changing the process, within our scope? Then have the RPM group look into the details? Is there some level of relief we can get without going into too much detail?
The comment about the process being broken does merit more discussion. This is not an access issue. 
The concern could be flagged to the RPM group or an edit put in place.
Amend paragraph 2 (URS Rules) of the Appendix D: Uniform Rapid Suspension by substituting the wording "Examiner" with "Provider". 
Amend paragraph 2 (URS Rules) of the Appendix D: Uniform Rapid Suspension and paragraph 1.2 of Appendix E: Uniform Domain Name Dispute Resolution Policy by substituting the wordings "Doe complaint" with "complaint against an unidentified Respondent" and adding the wording "theComplainant with"  - this helps make it universal language.
Small team outcome: put forward these changes to the EPDP Team.
Second issue - registration data for UDRP complainants 
For the reasons Alan described, it would be a complicated process to release data beforehand, and this is essentially an access discussion.
By getting into when and how much data to disclose at this point, we are straying into access issues. Probably best to park this for now. Reverse WHOIS type of service would not be appropriate because it is not definitive whether a domain name is an abusive registration. Once data is released, there could be research on previous UDRP decisions. The number of decisions alone is not dispositive of bad faith registrations.
Providers at times may redact information from the decisions they publish. This is an access issue, but when we discuss the access, it may well be that we can recommend providing more access than the public gets. We may need to tweak some rules within the UDRP or URS. Perhaps put a placeholder here to discuss at the appropriate time.
OK with deferring the access discussion, but the suggestion is - use it as a means of pushing it into that discussion.
This could be considered within the EPDP or the RPM PDP WG. Is this something that needs to be flagged? EPDP can discuss this in access discussion.
This is out of scope for this EPDP Team. What is suggested is to tweak the process to make it easier for complainants to make their case. The only this we should change at the moment is to make sure the process is compliant. The decision to disclose is up to the individual registry or registrar, not a blanket reverse WHOIS request.
If we talk about this substantively, part of proving the UDRP is showing bad faith, which could involve patterns of abuse. The fact that the UDRP does not work now is a problem for ICANN and for the UDRP. We are talking about multiple look-ups. 
We will propose the two small changes from the providers.
For this discussion and the effects of GDPR and UDRP, when we discuss an access model in Phase 2, we will flag this issue. 
When will the team have the access discussion - this would be helpful. Also note reverse WHOIS is not an ICANN policy - this is a new feature that we may agree this is outside the scope of what we're doing here.
Outcome: PCRT comments 3, 5, 8, 11 regarding access to registration data for the purpose of UDRP/URS filing will be preserved for the access discussion in Phase 2 - at which point the EPDP Team can decide if the concern should be addressed by the EPDP Team/how to address the concern if the Team agrees the concern is appropriately within scope.

c. Recommendation #18 - Data processing agreements with dispute resolution providers (incl. Question #4)

The EPDP Team recommends that ICANN Org must enter into data processing agreements with dispute resolution providers in which, amongst other items, the data retention period is specifically addressed, as this will affect the ability to have publicly available decisions.
Themes seem to be - eliminating clause at the end as this will affect publicly-available decisions. Another comment is eliminating recommendation as this seems to be elimination of URS and UDRP. 
Small Team Feedback:
Once we get to the stage of a decision, the information relating to the registrant is part and parcel of that decision. To the extent there are comments relating to access, we have already disposed of those. To the extent that we would be amending URS or UDRP procedures, that is not our job. Where stakeholder groups are saying the same thing, that is compelling.
Discuss the issue raised by the Forum and George K. regarding decisions being made public.
If you have DPA b/w ICANN and Providers, does this necessarily mean the decisions would not be public? Why is George concerned that the decision won't be public? 
The biggest question we need to look at: who are we trying to deal with. The publication of the decision is by the provider - this is out of scope for us. What we need to figure out more - why are we providing the data to the provider in the first place. In these questions by Tucows, Forum, George - we are missing a key concept - who is the controller? Here, it is the URS/UDRP provider - that is a matter of the contract b/w ICANN and the URS Provider.
This is talking about an agreement b/w ICANN and providers. It looks like the comments are meant to cover other issues that may come up in the DPA.
Consider deleting the text after data retention period. The whole issue is whether decisions are public or not is not a WHOIS issue - this is an issue of how providers do their work. This seems to imply that WHOIS has a bearing on publicly-available decisions. This simply notes ICANN has to enter into data processing agreements.
Given that the issue of publicly-available decisions and redaction is a concern of many commenters, I suggest we leave it as drafted.
As this recommendation is, we’re giving a suggestion – probably keep in mind decisions, so this is not a major issue to leave it in.
Outcome - Having taken careful note of all public comments received on this recommendation, the EPDP small team has decided to remove the last clause from Rec. 18 (noting it is out of scope).

d. Recommendation #22 - Impact on other policies 

EPDP Team Preliminary Rec #22.

The EPDP Team recommends that as part of the implementation of these policy

recommendations, updates are made to the following existing policies / procedures, and any others that may have been omitted, to ensure consistency with these policy

recommendations as a number of these refer to administrative and/or technical contact which will no longer be required data elements:

• Registry Registration Data Directory Services Consistent Labeling and Display

Policy

• Thick WHOIS Transition Policy for .COM, .NET, .JOBS

• Rules for Uniform Domain Name Dispute Resolution Policy

• WHOIS Data Reminder Policy

• Transfer Policy

• Uniform Rapid Suspension System (URS) Rules

Should we include the PPSAI policy, AWIP, and ERRP? 

>From the comments and text, better to postpone this recommendation and possibly add to final report as we are still evolving and shouldn’t have a laundry list of policies that need to be updated that are not there.

Addition of the PPSAI policy request – this is something that we need to be clear about, so this should be reviewed within the plenary.

This recommendation should stay in the books and in the Final Report, but it shouldn’t be finalized right now as the team is still working. 

Could we recommend to the larger group that the part re: admin/tech be eliminated at this time?

Proposed outcome: this team discussed removing the clause at the end “as a number of these” and this group discussed and generally supported the inclusion of PPSAI 

Is this work for an implementation review team, or is this work for the GNSO? 

e. Recommendation #6 - Escrow Providers

EPDP Team Preliminary Rec #6:

1. The EPDP Team recommends that ICANN Org enter into legally-compliant data

processing agreements with the data escrow providers.

2. The EPDP Team recommends updates to the contractual requirements for registries and registrars to transfer data that they process to the data escrow provider to ensure consistency with the data elements workbooks that analyze the purpose to provide mechanisms for safeguarding Registered Name Holders' Registration Data.

3. The data elements workbook that analyzes the purpose to provide mechanisms for safeguarding Registered Name Holders' Registration Data Registration Data contains the specifically-identified data elements the EPDP Team recommends be transferred by Registries and Registrars to data escrow providers (see Annex D). These data elements are: <see Initial Report>.

One major issue is lack of in-depth review of data elements workbooks. We may consider putting this onto the face-to-face agenda. 

What is the best way to do this? Is there a way to use a small team, for example?

Perhaps allocate homework to individuals – go through the easy ones first.

Task: did we learn anything new from the comments? No – these are the predictable positions we have heard from the stakeholder groups all along. We discussed this in BCN, but we did not reach an agreement. There doesn’t seem to be much new in the public comment.

Regarding what information is provided to the data escrow provider – BC recommended all data except specific TLD data should be provided to the escrow provider.

This could come out of the data mapping Alan G discussed.

Most people agree data escrow that all data or minimal data set is copied. If we come to the agreement that which data is necessary for the processing activity, then there is not a problem with the recommendation. 

Where we are: The exercise of determining the data flows and specific data set are necessary. 

Recommendation 6 is agreed to by everyone, but the specific data set needs to be agreed to by the EPDP Team. Other proposed edits to the language can be assessed following plenary review of the data set. 

f. Recommendation #12 - Reasonable access

g. Purpose 4 - Safeguarding RNH's Registration Data

h. Recommendation #17 - Input from RPM PDP WG to inform subsequent access discussion

EPDP Team Preliminary Rec #17.

The EPDP Team requests that when the EPDP Team commences its deliberations on a standardized access framework, a representative of the RPMs PDP WG shall provide an update on the current status of deliberations so that the EPDP Team may determine if/how the WG’s recommendations may affect consideration of the URS and UDRP in the context of the standardized access framework deliberations.

Potential items for discussion – UDRP providers should be included in this consultation, is this an action item rather than a policy recommendation?

This is an action item and not a policy recommendation. Suggestion – delete this as a recommendation but include as an action item in Phase 2 of the work.  If WIPO would like to be included on the EPDP Team, this needs to go to the GNSO Council. 

Where is the appropriate place for this? 

Perhaps see how this could potentially be included in the Final Report, but not specifically as a policy recommendation. Consider including this in the body of the Final Report, but not include as a specific policy recommendation. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20190108/ec437ed1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4621 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20190108/ec437ed1/smime-0001.p7s>