February 2019 - Gnso-epdp-team

Consensus Designations
by Kurt Pritz 20 Feb '19

20 Feb '19

Hi Everyone: Attached is the consensus designation table that will be included as an Annex in the Final Report. Please let me know of questions or corrections. Thx & regards, Kurt

1 0

Notes and action items from EPDP Team Meeting #47
by Caitlin Tubergen 20 Feb '19

20 Feb '19

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

1 0

Modified GAC Statement
by Heineman, Ashley 20 Feb '19

20 Feb '19

Hello all. My sincerest apologies for any potential confusion, but please find a mildly revised version of the GAC Statement to the Final Phase 1 Report. This attempts to clarify some confusion around our concerns pertaining to the organization field as well as to update where we stand on Recommendation 18 in light of today's call. EPDP support staff, please kindly use this version for including in the report and apologies again for sending in a revised version.

1 0

Consensus Designations
by Kurt Pritz 20 Feb '19

20 Feb '19

Hi Everyone: We spent a lot of today looking at past PDPs and levels of Consensus designations. I also considered your emails regarding consensus designations and appreciate the experience you have had as Chair or members of previous PDPs. We particularly examined the Curative Rights PDP, IGO/NGO PDP and the Registration Abuse Policies WG (and others). In those we found examples of designations of consensus where 4 of 15 members disagreed or representatives of three different GNSO groups disagreed. I have thought to take a conservative approach to consensus designations because I do not want to inflate the perceptions around our levels of agreement. To me a label of “Stong Agreement / Significant Opposition” should be an indication to the Council that such a recommendation should be favorably considered for adoption. However, past precedent indicates a broader definition of “Consensus” is appropriate. Therefore, I have adjusted some of the designations in accordance with the Alan's, Thomas’ and other emails. I chose not to conflate the number of groups with the voting scheme of the GNSO Council. I think that is the province of the Council, i.e., discussion at the Council level and the voting scheme will come into play there as items with “Strong Support" are considered. The report will necessarily list those in opposition to t certain recommendation. Please check the attached to determine support (or the opposite) is accurately reflected. During the call tomorrow, we will check to see if any levels of support have changed based on the discussion and email exchanges. Please write back with questions. Kurt

4 3

Re: [Gnso-epdp-team] [Ext] Re: Confirming objections to recommendation #16 - geographic basis
by Marika Konings 20 Feb '19

20 Feb '19

Milton, please note that the reference here to ‘group’ was not intended to refer to stakeholder group but to ‘group’ as used in the EPDP Team Charter, more specifically the table on page 12-13. Best regards, Caitlin, Berry and Marika From: "Mueller, Milton L" <milton(a)gatech.edu> Date: Tuesday, February 19, 2019 at 22:11 To: Marika Konings <marika.konings(a)icann.org> Cc: "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org> Subject: [Ext] Re: [Gnso-epdp-team] Confirming objections to recommendation #16 - geographic basis Marika and Caitlin Another reminder that the relevant groups from the GNSO are Stakeholder Groups, not constituencies. IPC and BC are two thirds of the Commercial Stakeholder Group, they are not each of them the equivalent of RySG, RrSG or NCSG, ALAC, GAC or SSAC. The correct way for you to list the groups not supporting Rec 16 would be: ALAC SSAC 2/3 of CSG (IPC and BC) Please correct this mistake going forward. Milton L Mueller Professor, School of Public Policy Georgia Institute of Technology On Feb 19, 2019, at 12:26, Marika Konings <marika.konings(a)icann.org<mailto:marika.konings@icann.org>> wrote: Dear EPDP Team, Per today’s meeting, the staff support team has currently noted the following groups as not supporting recommendation #16 (“The EPDP Team recommends that Registrars and Registry Operators are permitted to differentiate between registrants on a geographic basis, but are not obligated to do so.”): * ALAC * SSAC * IPC * BC If your group is missing, or your group’s position has changed as a result of today’s discussion, please let us know as soon as possible so this can be accurately documented in the Final Report in relation to this recommendation, as well as factored into the consensus designation process. Best regards, Caitlin, Berry and Marika Marika Konings Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings(a)icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<https://urldefense.proofpoint.com/v2/url?u=http-3A__learn.icann.org_courses…> and visiting the GNSO Newcomer pages<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gn…>. _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team(a)icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team

3 2

Fw: [council] Vote deferral requested
by Ayden Férdeline 20 Feb '19

20 Feb '19

For information purposes, please be aware of this email that was sent to the GNSO Council mailing list. If the Council Chair responds, I will forward his correspondence along. Ayden Férdeline ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, February 20, 2019 2:08 PM, Marie Pattullo <marie.pattullo(a)aim.be> wrote: > Dear Keith, > > On behalf of the BC, we would like to request that the Council vote on the Phase 1 EPDP Report be postponed until Monday 4th March so as to permit the continuation of the very practical ongoing discussion within the EPDP Team on the unresolved policy recommendations. > > Thanks in advance, > > Scott & Marie > > Marie Pattullo > > Senior Trade Marks and Brand Protection Manager > > [cid:image001.png@01D48358.C5A0D6C0] > > European Brands Association > > Avenue des Gaulois 9 · 1040 [Brussels](https://www.google.com/maps?q=9+avenue+des+Gaulois+%0D%0AB-1040++… · Belgium > > T: +32 2 736 03 05 > > M: +32 496 610 395 > > E: marie.pattullo(a)aim.be > > W: [www.aim.be](http://www.aim.be/) > > EU Transparency Register: [1074382679-01](http://ec.europa.eu/transparencyregister/public/consultation/displaylobbyist.do?id=1074382679-01) > > [LinkedIn icon](https://www.linkedin.com/company/aim---european-brands-association/) [Twitter icon](https://twitter.com/AIMbrands)

1 0

Point of clarification Re: Purpose 2
by Ben Butler 20 Feb '19

20 Feb '19

Hi Kurt, Marika, and team. In reviewing the recent concern designations that were sent to the team, I noticed that SSAC’s position was listed as opposed to Purpose 2. In reviewing the deliberations within SSAC, this should instead be “support with comments”. Our concerns with Purpose 2 were concerning vagueness in the language, but overall, we are supporting purpose 2 and look forward to the work on this area in Phase 2. Just wanted to clarify that so as to make the consensus designation efforts clearer. Thank You. -Ben

1 0

For review - updated language recommendations #11 and #18
by Marika Konings 20 Feb '19

20 Feb '19

Dear EPDP Team, As discussed during today’s meeting, please find attached the updates discussed and agreed to for recommendation #11 (city field) and #18 (reasonable access). Please share with the list as soon as possible if in your view these changes do not align with the agreements reached today. Best regards, Caitlin, Berry and Marika Marika Konings Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings(a)icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<https://urldefense.proofpoint.com/v2/url?u=http-3A__learn.icann.org_courses…> and visiting the GNSO Newcomer pages<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gn…>.

4 5

GAC statement to phase 1 final report
by Heineman, Ashley 20 Feb '19

20 Feb '19

Dear Kurt, Please find attached a statement for including in the phase 1 final report from the GAC small group. FWIW - this does NOT represent an objection to the consensus calls or the report itself. Thanks kindly, Ashley Heineman Sent from my Verizon, Samsung Galaxy smartphone

3 3

Recordings, Attendance & AC Chat / GNSO Temp Spec gTLD RD EPDP / Tuesday, 19 February 2019
by Nathalie Peregrine 20 Feb '19

20 Feb '19

Dear all, Please find the attendance and AC chat attached to this email, and the MP3 and AC recording below from the GNSO Temp Spec gTLD RD EPDP call held on Tuesday, 19 February 2019 at 14:00 UTC. These have also been posted on the agenda wiki page: https://community.icann.org/x/EYU2Bg MP3: https://audio.icann.org/gnso/gnso-epdp-gtld-registration-data-specs-19feb19… AC Recording: https://participate.icann.org/p3sgzxt3fww/ ** Please let me know if your name has been left off the list ** Mailing list archives of the GNSO Temp Spec gTLD RD EPDP : https://mm.icann.org/pipermail/gnso-epdp-team/ Main wiki page for the working group: https://community.icann.org/x/IYEpBQ Thank you. Kind Regards, Andrea Glandon

1 0