EPDP Meeting #47 20 February 2019 High-level Notes/Actions The Support Team will send a clean and red-lined version of the Final Report to the Team and the GNSO Council shortly. Notes & Action items These high-level notes are designed to help the EPDP Team navigate through the content of the call and are not meant as a substitute for the transcript and/or recording. The MP3, transcript, and chat are provided separately and are posted on the wiki at: https://community.icann.org/x/ZwPVBQ. 1. Roll Call & SOI Updates · Attendance will be taken from Adobe Connect · Remember to mute your microphones when not speaking and state your name before speaking for transcription purposes. · Please remember to review your SOIs on a regular basis and update as needed. Updates are required to be shared with the EPDP Team. 2. Discussion of items for amendment and final discussion: · If there is not broad support for a change, we will move on to the next item. · There seemed to be rough consensus around 30 days for disclosure requests for rec. 18. · 30 days may be acceptable, but a substantially shorter timeline will apply for urgent disclosure requests · It doesn't make sense to have a contractual requirement without knowing the volume of requests that will come in. · There could be a scheme that is developed later about how to deal with this. To attach a number at this stage in the game is premature because the number we pick is likely wrong. · Addressing this later does not address the bad actors. · There needs to be a way to block unreasonable requests. · The language that registrars must respond reasonably helps solve the concern with bad actors. The language proposed by Thomas would be acceptable. e. Recommendation 9 – Contractual Compliance – consider clarification (30 minutes) · Add "if needed" to the recommendation and note the current language in the contracts addresses this already. · This change may not fully address the RySG comments. · From a Ry perspective, the group looked at the Charter question, specifically e1. The contract language is fine as is and does not require any changes. · The footnote for Rec. 9 notes the request must be narrowly-tailored to meet the request. · It may be important to keep the data set provided by Compliance in the recommendation. Why is OK to eliminate this? · The existing contracts do not have this enumerated, so why is this enumerated in the report? The data elements are out of place here. · If this is a full list, why does it need to be delineated? · Is it OK with everyone to delete the table, retain the footnote and note what Alan G. just said? · Concerning registration data elements - ry and rrs are required to transmit to ICANN org any WHOIS elements that are requested for Purpose 5. · Add a note, "it doesn't preclude CC from getting other data that are in the compliance processing activities doc" f. Recommendation 12 – Organization field – consider clarification (30 minutes) · Clarification offered by Rrs/Rys to show the org phase-in approach is a registrar obligation, and for registries to publish is optional. · Will registries publish the org field once the phase-in period is complete? · Getting consent requires flags for getting consent and flags for withdrawal of consent. This seems complicated for registries to know if the requisite consent was given. · Transfer of consent is not a simple issue. It's a technical challenge as well as a GDPR challenge. · Registry has to decide or not whether it wants the data, and this is based on risk. · There is not thin or thick at this point; rather, an aggregate minimum data set. Having it and using it for a justified purpose is different than publishing it. · Consent is not mentioned in the implementation advice. · Once we figure out who to transfer consent, then info will get transmitted to the registries · Who is the authoritative source, the registry or the registrar? · It might be best to say the registrar is the authoritative source here. · When we say something is only available at the registrar, once we figure out how to transfer consent, it should apply to all of those fields. · Proposed updated language: This is a Registrar obligation. For a Registry to publish is optional, until such time a way has been found that allows for the transfer of consent from Registrar to Registry. · A future date certain is not certain, so clarity is needed. · The only language regarding implementation appears in Rec. 28 - Feb. 29, 2020. · This is more difficult that some make it seem. · For the period b/w the adoption of the EPDP Policy and the conclusion of the implementation effort set for on or before 29 February 2020. g. Recommendation 17 – Natural v Legal distinctions – consider clarification (30 minutes) · Ry/Rr proposed modification - the language in the parentheses is the previous language. · The updated language from Ry/Rr is meant to clarify the recommendation. · The SSAC proposal seems the opposite of what the group came to, so the disagreement will be noted. · SSAC would like to see a resolution to this = recommending as a possible path forward, in the deliberations in Phase 2. As we deliberate on this, there should be a balance on the cost to the ecosystem, not just the financial burden on contracted parties. · Consider adding a bullet that says: considers the potential benefits. · Add bullet on impact on the Internet/DNS ecosystem of not making the distinction. · It is not just about legal vs natural persons - even with legal persons, there could be personal information of natural persons. · Phase 2 is not a second bite at the apple. · IP/BC change to third bullet makes the language more committal - instead of "will discuss", it is changed to "determine and resolve". It also deletes the second sentence of the recommendation. · No objections were noted to these changes. · For rec. 18, can 30 business days be changed to 30 calendar days? · Change 30 business days to 30 days. h. NEW – Recommendation #14 – Privacy / Proxy Registrations – consider clarification and possible implementation guidance proposed (30 minutes) · One proposed change is to add "affiliated and accredited provider is used" instead of just affiliated. · Accredited is added so that when the policy goes into effect, this language will future-proof the policy. · The second bullet asks for the implementation to be completed within 90 days after the adoption of the EPDP policy recommendations by the board. · It seems tough for this Team to put an implementation date certain on another IRT. · The expansion of accredited is inappropriate at this late stage. · If there is some way to convey to the Council that this work should be done in an expedited manner, that would be preferred. · Isn't the onus on the P/P provider to provide the data, and not the registrar? · Not sure we're in a position to guarantee an implementation date. · Our job is not to future proof - we are looking at the status of things as they are now. We should defer to the competence of the other WGs/IRTs for the future work. · Support staff to put a note that PPSAI is an approved policy that is currently going through implementation. It will be important to understand the interplay between the display of information of affiliated vs. accredited privacy / proxy providers. Based on feedback received on this topic from the PPSAI IRT, the EPDP Team may consider this further in phase 2. Data Retention - Rec. 15 · Add 15 months to account for complaints filed on the 365th date to ensure data is not deleted on Day 366 Recommendation 7 · Small group looked through the workbooks · In the latest version of transfer of data from the registrar to the registry. There are two versions of this - there is one for TLDs where URS applies and where URS does not apply. This was put in the annex due to a previously-raised concern. · The current language of Rec. 7 is problematic b/c it creates an obligation that is not necessary and conflates the URS with the transfer of data from the registrar to the registry unnecessarily. · Proposed solution: requires transfer of registrant fields from a registrar to a registry with URS. Transfer of those fields should be optional based on registry policy (O-CPH). The table of required elements should be changed. URS does not create an obligation to transfer data. Remove the first table and leave the second table. And remove the reference to URS. · URS contemplates the data comes from the registries. Accordingly, there should be a recommendation that the data should come from the registrar. · The URS is not a consensus policy, it is a contractual obligation since the 2012 round. There is not distinction of whether a provider should contact the registry or registrar. As part of the Temp Spec implementation from Annex D, there are specific additional requirements for the Registry Operator and for the registrar. Because data elements would be redacted, in some cases, the provider would contact the registry to retrieve the RNH data. The rationale for doing that is that in today's URS environment, providers contact the registry and not the registrar. · The workbooks are not binding, they are illustrative. 3. NEW - Confirm groups for any recommendations that are designated as having ‘strong support, significant opposition’ as this information is to be included in the Final Report. (15 minutes) (see latest version of Consensus Designations document) · The consensus designations in red are the ones that have changed. · For the org field, we can call that consensus. · What is important to the leadership team - identify the groups that are not supporting the consensus recommendations. · Generally speaking, there are notations within the report that recommendations have consensus/full consensus unless designated differently. The groups who disagree will be noted in the report. We could consider adding this table as an annex. · Action item is that the groups who do not support recommendations are denoted correctly so that everything is accurately documents. For consensus designations, there is no requirement to designate opposition. · When we refer to BC and IPC, but it should be clarified parenthetically that it is 2/3 of one stakeholder group. (2/3 of CSG) · We have a consistency problem with divergence and SS/SO for Rec. 2 and Rec. 16 – these should be the same designation. · Is ISPCP opposed to Rec. 2? The ISPCP has not objected to any recommendations but has recorded some concerns. · For 16 – opposition – IPC, BC, ALAC, SSAC · Council rules apply when voting, but within a WG, we are not viewed within our stakeholder group. · The chart does not reflect the comment about the BC/IPC that they are not able to support the report without the requested changes. This dissent should be captured in a footnote on this chart. · On Rec. 5 – there should be a note about divergence with the tech contact being optional. · Does contact information include tech contact? If it does not, then ALAC would oppose the recommendation. · This is how the consent rec currently reads: "The EPDP Team recommends that, as soon as commercially reasonable, Registrar must provide the opportunity for the Registered Name Holder to provide its Consent to publish redacted contact information, as well as the email address, in the RDS for the sponsoring registrar" · Should contact be removed to address the problem? · ACs should be treated the same as SGs to respect the participation of the groups. · BC/IPC would like to include their statement as an annex/minority statement to the report. 4. Confirm next Steps (15 minutes) 20 February 2019Final Report Submit Final Report or confirm that version submitted on 11 February should be considered finalStaff Support Team / Council Liaison 21 February 2019Consider Final Report for adoptionGNSO Council 4 March 2019Consider Final Report for adoption (if needed)GNSO Council