[Gnso-epdp-team] Notes, Actions - Small Team A - Meeting 2, 10 January 2018

Fri Jan 11 01:33:36 UTC 2019

Dear All,

Below, please find notes from Small Team A’s call on 10 January 2018.

Thank you.

Best regards,

Marika, Berry, and Caitlin

--

Small Team A 

10 January 2019

High-level Notes Actions

Purpose 4

Initial Report Language:

Provide mechanisms for safeguarding Registered Name Holders' Registration Data in the event of a business or technical failure, or other unavailability of a Registrar or Registry Operator.

Proposed Updated Language:

Provide mechanisms for safeguarding Registered Name Holders' Registration Data in the event of a business or technical failure of a Registrar or Registry Operator, or unavailability [of a Registrar or Registry Operator, as defined in the Registrar Accreditation Agreement and Registry Agreement, respectively.]

(See below notes for further discussion.)

Purpose 6

Initial Report Language:

Coordinate, operationalize, and facilitate policies for resolution of disputes regarding or relating to the registration of domain names (as opposed to the use of such domain names), namely, the UDRP, URS, PDDRP, RRDRP, and future developed domain name registration-related dispute procedures for which it is established that the processing of personal data is necessary

Proposed Updated Language:

Coordinate, operationalize, and facilitate policies for resolution of disputes regarding or relating to the registration of domain names (as opposed to the use of such domain names, [but including where such policies take into account use of the domain names]), namely, the UDRP, URS, PDDRP, RRDRP, [and the TDRP.]

(See below notes for further discussion.)

---

Notes

Reminder of Review 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.

For purpose of reviewing Tuesday's work, the Leadership Team compiled a brief summary including Initial Report Language, Proposed New Language (where applicable) and the accompanying rationale.
We plan to send these summaries to the full team so that the full team is able to review and approve (where possible).
We will communicate to the team that we would like the EPDP Team to give deference to the discussion of the representative small teams.
Purpose 4 - Safeguarding RNH's Registration Data

For past, present and registered names holders - should not add this b/c retention periods need to be put in place. We also haven't discussed legacy - it's not as easy as changing the purpose. 
In the interest of transparency and full documentation, we understand the nuance in Purpose 1, but there is no harm in having a separate purpose that deals with disclosure to a third party. It's a good point, but it's OK to have a separate purpose.
"Or Other unavailability" is indeed vague, and support removal.
Is there something we did not cover with "other unavailability", if not - remove it.
Concern with removal - if you look at a registrar who does not have a business failure - their computers are running, but they don't do anything - that is not a technical or business failure, but they are functionally not providing the service.
Could consider RAA failure or ICANN termination
Would not apply George K's comment due to data retention periods
Important to be specific about what other unavailability means. Concepts such as reasonable and substantial are well understood - it's a non trivial type of failure - this is something more lasting or serious.
Past and present - even if you step behind the scenario where you are covered by data retention - that is unclear. This could include historic lookups, and am therefore uncomfortable with this suggestion.
Another choice of words - operational failure, de-accreditation, termination by ICANN
concept that is missing is substantial or sustained or longlasting failure 
Personal data may be processed for the purposes of escrow within the purpose since that is in the contract.
Provide mechanisms for safeguarding Registered Name Holders' Registration Data in the event of a business or technical failure of a Registrar or Registry Operator, as defined in the contract. [upon expiration without renewal or termination of this Agreement].
Provide mechanisms for safeguarding Registered Name Holders' Registration Data in the event of a business or technical failure of a Registrar or Registry Operator, as defined in the contract. [upon expiration without renewal or termination of this Agreement].
We need to be sure to include business and technical failure b/c sometimes deposits are transferred on a temporary basis, so there is not always a termination.
Proposed language: Provide mechanisms for safeguarding Registered Name Holders' Registration Data in the event of a business or technical failure of a Registrar or Registry Operator, or unavailability of a Registrar or Registry Operator, as defined in the Registrar Accreditation Agreement and Registry Agreement, respectively.

Purpose 6 - Coordinate Rights Protection Mechanisms

Few recommendations to change the words at the beginning - one suggestion is to change it to "operationalize" and also add the word "establish"
Remove "future developed policies"
Comments regarding the "use" of such domain names
Others would like to interject language - DRPs also have to do the use of domain names and to make that clearer.
Third change - enumeration of DRPs - some believe PDDRP and RRDRP should be taken out. Others suggested all should be taken out since there may be other dispute resolution processes such as disputes in court.
Why should future developed DRPs be removed - there is no reason to assume there won't be a DRP in the future.
The reason we should not put in future type language such as that - you have to be very specific with the data subject. This does not work. Where there is an envisaged processing of personal data - it has to go through a privacy impact assessment at that time not now.
It is not inconceivable to have a new policy in the future and the specificity could be given at that time.
Like the inclusion of future-developed policies - but this is not a die in the ditch issue.
This should be taken out b/c it causes problems to keep it in as it will affect the legitimacy of this purpose. 
Should we include a recommendation that future policies need to go through a privacy impact analysis?
This purpose could be subsumed by Purpose 2. We put this here b/c it is a major type of action and registrants should be aware of it. We should keep it and be specific about what policies affect it. You may not need data to file a PDDRP or RRDRP, but you may need data to address a complaint.
Action: Support Staff to Memorialize how future policies are affected by this.
Possible edit: Coordinate, operationalize, and facilitate policies for resolution of disputes regarding or relating to the registration of domain names (as opposed to the use of such domain names), namely, the UDRP, URS, PDDRP, and the RRDRP.
Either delete the parenthetical, or it needs to map to the bylaws
Regarding the first words - do any of these comments present new information that warrant a change?
We may need facilitate to account for the compliance function.
It is important to limit the purpose - in favor of specificity
For the PDDRP and RRDRP may need to process registration data.
It's not just the registration - it's also the use - adding the wording use and or registration of domain names would cover Alan and Margie's points 
We may need to include mediation.
Should we have the three words, or not. Should we have the parenthetical or not. Should we list the policies or not. Should we include procedures outside of ICANN policy or not. 
Action: Alan G. to summarize the discussion for the group.
Problem with suggestion of referring to DRPs listed in the by-laws is that consensus policies may not be listed in the bylaws. Respect language the group has settled on.
Provide Option 2 but highlight the additional discussion
Coordinate, operationalize, and facilitate policies for resolution of disputes regarding or relating to the registration of domain names (as opposed to the use of such domain names, but including where such policies take into account use of the domain names), namely, the UDRP, URS, PDDRP, RRDRP, and the TDRP.

Recommendation #12 - Reasonable access

Majority of comments seem to allude to a unified access model
Is there anything in the comments that would cause us to amend this recommendation?
Sympathetic to concerns about predictability - we need some proposals around this.
We have two issues here: (1) inclusion of access into final report; (2) some of the detailed comments - only way to address comments fairly - thank you for your comments - they will be taken into account in Phase 2, otherwise the team will relitigate the same issues.
This is a controversial area - the stakeholders have well thought through and predictable lines
Disagree - you cannot ask a blanket approval - what this does is it creates predictability for knowing how and where to process a request. Proposal to have this conversation with the broader team.
This is a controversial topic, but it is within our scope at this juncture. We've put a lot of work into this as a team - where we are - we should add more detail in relation to the comments without going backwards.
Read this as a - we can't wait for the full UAM - we need something in the meantime.
This is a discussion for the plenary. We need to address the intermediate stage long before we have the full UAM - we need to talk about making sure there is enough specificity so contracted parties need to understand what they need to do - and that compliance can enforce.
This is not a discussion in Phase 1 of the access model. 
It is unclear what various folks are asking for - what are we doing in plenary - there is consensus on the fact that this is not a small team issue. We are saying we cannot solve this in the timeline of the EPDP; therefore, current requirements must remain in place until Phase 2.
Do public comments necessitate a change? Proper form is in plenary. We had come to a good place - this was not as controversial as we expected it to be. We could put down you must respond within three days, but not every access request can be responded to within three days. There are many considerations to this - these things take time, and arbitrary timelines can be problematic.
Needs to be understanding that we will do our best. Let’s not squander the good will – many comments may have missed the point of this recommendation. 
If we get through this in the plenary, we can put this in the real policy. The real issue is the recommendation as written says – we will make no changes until we have the UAM implemented. We may never have a UAM, so we need to do something as an intermediate step.
The reason to have the clarity in the policy now that these are the things the policy should cover on both sides – for CPH and the parties requesting access.
I don’t understand why this recommendation is no longer OK – and not sure why people think further conversation on this could be productive in Toronto.
Recommendation – discuss in plenary, focus on how to translate these into temp spec language, and then ask the question – what can be standardized in the info registrars provide to the public on this. For those who would like amendments – please come prepared to discuss what those specific changes could be.

Recommendation #14 - Responsible parties

What relationships exist for what purposes – we need to do a purpose by purpose analysis of where these relationships exist – this discussion could be settled in plenary.

Purpose 1 - Establish rights of RNH

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20190111/1d58f853/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/20190111/1d58f853/smime-0001.p7s>