- Gnso-epdp-team - lists.icann.org

Memo to ICANN re: Purpose O
by Kurt Pritz Dec. 21, 2018

Dec. 21, 2018

Hi Dan & Trang: After our last call, Benedict and I briefly spoke some more about the proposed “Purpose O” for ICANN research related to stability and security issues. In that discussion, we reiterated the position of many on the EPDP call that it seemed awkward that Benedict was the key (even sole) proponent of this purpose and that it seemed logical that ICANN should be championing this. For me, it seems reasonable that a full understanding of this purpose for processing registration data should be available - to give the EPDP team the opportunity to hear, in some detail, the benefits, costs and risks of this “purpose” so that they have full information and can decide if it should be included. If ICANN agrees that they should have access to data for SSR research, what is the best way to bring this information to the EPDP team? I would suggest David Conrad or John Crain present to our group to inform our discussion and flesh out the material in the “purpose O” as currently written. ICANN staff could describe the effect of GDPR on research efforts, i.e., what could be done prior to 25 May that can no longer be done? What is necessary to overcome any GDPR barriers placed in the way of ICANN SSR research? I think reticence on the part of ICANN to participate in this part of the EPDP deliberation would be interpreted as lack of ICANN support for these types of projects and an indication that their value does not rise to the level of importance indicated by Benedict and others. That would be fine with me but I wanted you to understand the implication as I see them. As you heard, Benedict was in a tough position defending the access to data by ICANN. On a different but related topic, can ICANN report on the status of the Whois Accuracy Reporting System Project? During the recent call I believe Alan Greenberg stated that he thought it was “stopped” but the Trang said it was not closed off and might be starting again. I ask this because this project will be discussed at an upcoming meeting and, to me, it might fall under “Purpose O” as it is a study of finite duration, approved by the community and currently stopped. I understand it does not fall under the aegis of the Office of Technology but It could be described by the ICANN group championing it. I understand that this falls under GDD. In any event, a status, including the effects of GDPR on this project would benefit the discussion. Let me know your thinking and if I can provide any additional communication. Best regards, Kurt

2 1

FW: EPDP questions to ICANN org
by Marika Konings Dec. 21, 2018

Dec. 21, 2018

Dear EPDP Team, Hereby the response from ICANN Org to the following questions: Question: What is the rationale for the bolded wording in this Temporary Specification section: As soon as commercially reasonable, Registrar MUST provide the opportunity for the Registered Name Holder to provide its Consent to publish the additional contact information outlined in Section 2.3 of Appendix A for the Registered Name Holder. Response: The “As soon as commercially reasonable” language was added in Section 2.3 of Appendix A of the Temporary Specification because Implementation of this requirement would take development time on the part of the contracted parties. However, due to the timing of the Board adoption of the Temporary Specification, there was recognition that additional time would be needed to implement the requirement. The “MUST” language goes back to our stated objective of preserving the existing WHOIS to the greatest extent possible while complying with the GDPR. Giving as many registrants as possible the ability to have their full contact information published was in keeping with this stated objective. Question: What was the community input into this Temporary Specification section that, in each of the two cases, led to the wording, “as soon as commercially reasonable,” and “MUST“? Response: As far back as the development of the Calzone model, various parts of the community communicated to ICANN that registrants should be afforded the ability to have their full contact information published. See the Working Draft Non-Paper -- Selected Interim GDPR Compliance Models & Comments<https://www.icann.org/en/system/files/files/gdpr-draft-compliance-models-co…> dated 07 Feb 2018. During development of the Temp Spec, contracted parties pointed out that this requirement would require development time to implement in their platforms. These will also get posted here: https://community.icann.org/x/ahppBQ. Best regards, Caitlin, Berry and Marika

1 0

Recordings, Attendance & AC Chat / GNSO Temp Spec gTLD RD EPDP / Thursday, 20 December 2018
by Nathalie Peregrine Dec. 21, 2018

Dec. 21, 2018

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 Thursday, 20 December 2018 at 14:00 UTC. These have also been posted on the agenda wiki page: https://community.icann.org/x/FAvVBQ MP3: https://audio.icann.org/gnso/gnso-epdp-gtld-registration-data-specs-20dec18… AC Recording: https://participate.icann.org/p774a1erueg/<https://participate.icann.org/p774a1erueg/?OWASP_CSRFTOKEN=42cbcfdcadb04b8a…> ** 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

Notes, action items - EPDP Meeting #36 - 20 December 2018
by Caitlin Tubergen Dec. 20, 2018

Dec. 20, 2018

Dear All, Below, please find notes and action items from EPDP Meeting #36 below. Thank you, and happy holidays to all! Best regards, Marika, Berry, and Caitlin -- EPDP Team Meeting #36 20 December 2018, 1400 UTC High-Level Notes/Actions Alan Greenberg, EPDP leadership and staff support team to review input received in reference to and produce updated version for handling data of proxy registrants and data in privacy registrations for EPDP Team review on the mailing list. Kurt and Kristina to compile additional parameters and information necessary for ICANN org to begin the procurement of external legal counsel. There was a discussion concerning the potential collision between the ongoing discussion of EPDP issues and the comment period currently underway - and in particular the risk of continuing EPDP discussions before the comment period is closed and comments are read. For the benefit of the EPDP team and the DNS community, nothing discussed in the meetings prior to the closure of the comment period will obviate the full consideration of comments in the formulation of the final report. 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. Welcome and Updates from EPDP Team Chair Review of outstanding action items Other updates, if applicable Use today's meeting to review proposed language in relation to some of the issues that have been under discussion Note to be sent to the GNSO Council later today in relation to status of letter to EDBP letter - no letter sent at this point in time, to be further considered by EPDP Team at later stage. Reminder, public comment forum will close on Friday 21 December at 23:59 UTC. Important to avoid repeat comments during meetings - need to wrap up when all points have been made. Need to consider how to effectively review public comments. How to assess whether comments have sufficient background / rationale to trigger re-examination? Not dependent on who puts forward the comment, but based on the substance / rationale. Staff and leadership will be working on a public comment review tool to facilitate review of public comments. No small team in place at the moment or foreseen to review comments. Note that submissions, including names and affiliation, can already be reviewed here: https://docs.google.com/spreadsheets/d/1GUf86Ngo97g74wLyDmeBv8lGcUtjLJWjsEd…. 3. Continue review of list of topics for further discussion: in today’s meeting we will review potential wording developed from previous discussions for certain Temp Spec / Policy Recommendations to assess where there are areas of agreement. Privacy/Proxy Services - how the P/P records appear in the public WHOIS (review of language developed in previous meeting) The EPDP recommends that in the case of a domain name registration where a Privacy/Proxy service, offered or made available by Registrar or its Affiliates in connection with a registration is used, (e.g. where data associated with a [Privacy/Proxy customer] is masked), Registrar MUST return [unredacted data] in response to [RDDS] quer[ies], including the existing privacy/proxy pseudonymized email. Note: bracketed wording references suggestions from James and Marc A. Language was developed during previous meetings, bracketed wording references suggestions for changes that were shared on the mailing list by James and Marc A. Whatever language is agreed to needs to work once PPSAI is implemented as well as today's world. PPSAI recommends that to the extent feasible P/P registrations need to be clearly labelled in WHOIS. No need to do PPSAI's work, but future-proofing recommendation is important. If there are further suggestions on how this language can address both the current situation as well as the expected future state, please share those with the list. Is the implication of this recommendation that underlying customer information would be revealed? P/P is registrant of record, so P/P information would be displayed, not underlying customer information. Consider clarifying this in the text so this is clear. Will still need to consider whether publication of data is considered personal data as not all P/P may be using anonymized data. This puts CPs at risk if this data is published in a blanked manner, some caution may need to be exercised. Also need to factor in difference between privacy and proxy providers. Privacy registrations are under the name of the registrant, while contact info is P/P provider. For proxy providers, all the info provided is P/P. So for privacy registrations there would be personal data involved (registrant name). Could this be addressed by just stating privacy/proxy service, on the assumption that they would self-identify now, and required identification following PPSAI implementation. Different proposals made during the call, to be further considered. Alan Greenberg to take first stab at bringing these different versions together. Action item: Alan Greenberg, leadership and staff support team to review input received and produce updated version for EPDP Team review on the mailing list. Consent by the Registrant to Publish and/or Disclose for technical contact Current language in Temp Spec, Section 7.2.1/ Appendix C – Section 2.3 contains this requirement: Registrar MAY provide the opportunity for the Admin/Tech and/or other contacts to provide Consent to publish additional contact information outlined in Section 2.4 of Appendix A. Margie to introduce issue: Whether registrars should seek consent from those listed as additional contacts (admin/tech) to having their information as reflected in the Contact data be published rather than be redacted. This is an issue that would be available to both natural persons and legal persons. Proposed outcome: confirm this requirement [IPC/BC/SSAC support confirmation.] This may be a question for legal counsel as there are questions around what can be done, what contractual arrangements would need to be taken to make this GDPR compliant. Not sure that it is possible to come to agreement on the information that is currently available. Art 14 of the GDPR would need to be considered (information provided that is not from the data subject) - would be helpful to get further input on how this article may apply. Would registrars need to obtain consent from tech contact? What happens if consent is withdrawn ? Does 14.2.d mean that consent is to be obtained in the first place? EDPB letter made it clear that if a registrant that uses someone else's data, they would need to 'inform' that person. Need confirmation that this obviates the consent requirement as well as liability. Note that current language says 'MAY' - so it is up to registrars to determine whether necessary measures have been taken to do this in a GDPR compliant manner. Does not impose any new requirements, but allows registrars to offer this as a service. Absent this recommendation, it is still possible for contracted parties to offer such a service? There may be a data field to show appropriate consent was given, but this may not be possible within this framework of the EPDP. In the EPP, Section 2.9 - you can attach contact disclosure fields to each field. The format for data escrow does not include disclosure preferences, but because this is based off of EPP, this would be possible. If we took this language out of the Temp Spec, registrars would not be barred from getting appropriate consent and publication - should we let the market decide? Should this question be put to the legal team? Geographic Differentiation Discuss proposed draft recommendation (see attached document) Discussion, next steps Talked about two things 1) Clarification from EPDP did not apply to our situation 2) could work with outside counsel or DPAs. Even with clarity, we're still confronted with a complex situation. Postulated rules engine, or at least initial research in how it might work; or some preliminary study. Until we figure these issues out, the work required might take longer that the time the EPDP has. Point of order - these two issues (Geo & Tech Contact) are out for public comment and these discussions may impact/conflict the input received. [Attempt to recap conversations and see where we are as this was identified as an outstanding issues after the Initial Report] Who is in charge of language to the EDPB - differing viewpoints should be captured. What is the question and what is the scope of the clarification? The answer to this hinges on external advice. If we can rely on the registrant to certify that the information is accurate and belongs to them and they have sought consent, we should be able to rely on the country the registrant provides. We cannot have this discussion until we solve the first problem. Rules engine is not a commonly-understood term. Perhaps not all EPDP Team Members have the same understanding of what a rules engine is. A rules engine could just be a flowchart on a piece of paper. It could also be coding or software that makes decisions based on input it receives, and these are separate and distinct things. While it is called a rules engine, it is a flowchart concept, factoring in various factors (such as location) and determining which rules apply. This should be done by ICANN in consultation with legal counsel. This is not a unique situation to the domain industry. >From the EWG Final Report: More specifically, “rules engine” refers to a feature that could be implemented within the RDS to manage (a) the storage, collection and processing of domain name information based on Registrant, Contact, Registrar, Registry, and RDS jurisdictions (represented by the following data elements: Registrant and Contact Country Code, Registrar and Registry Jurisdictions), and (b) data protection laws of the applicable jurisdictions, in accordance with ICANN's future defined policy for the RDS. Things may have changed since the first postulation of the rules engine, so attention must be paid when building this. The Initial Report is out for public comment, so there are no major contributions we can make until we take into account the public comment. Caution the team against trying to push any new decision on critical questions we are asking the public to comment on. The rules engine could start with a flowchart, but this could be unwieldy and unmanageable as things change. There are a few ways to implement something like this in a practical fashion. What this language is intended to convey is that the language as written is that its at the discretion of the registrar when to differentiate geographically until such time as an authoritative body relieves the registrar of the liability or until such time as a rules engine relieves the risk. Summarizing at this point may dangerously undermine the public comment process. Rules engines are as much of an implementation issue as imaginable. This is not within our scope and is an implementation issue. While the EWG was in favor of a rules engine, this is work of an IRT to implement this. A solution presented the EWG was binding corporate rules (BCRs) – it’s easier to make exceptions to comply with local law and operate from there. I thought the group agreed that is not possible for the contracted parties to differentiate? The rules and policy that are going to used to feed this algorithm are going to be used by the rules engine are definitely within our scope. What are the rules that will direct how this algorithm will work? We do not know, and the determination of that will exceed our time limit, so we should think about in our future deliberations how we will address must vs. mays and what requirements should be and should not be. First meeting of the legal team Team is staffed with Kurt and Rafik as chair and vice-chair, Leon as the board liaison, Diane, Margie, Tatiana, Kristina, Laureen, Emily, Hadia, Benedict, Thomas, Dan Halloran The majority of the meeting was spent discussing processes. Some topics discussed were how questions are raised to this team. The Team will hone questions put forward by the EPDP Team. How will the Legal Team report back to the whole team? We also discussed working methods – email vs. teleconferences and how to answer questions – is there previously received advice, or are there questions that can be answered without going to legal counsel? The next call is scheduled for 2 January 2019. There are three EDPB questions and volunteers will begin honing the questions independently. In the meantime, ICANN will undergo its procurement process for outside legal counsel. Has the team decided on what type of attorney/law firm the group wants to proceed with? ICANN org needs more detail before it can begin the procurement process. Kurt to clarify additional details necessary to begin procurement process. 4. Wrap and confirm next meeting to be scheduled for Thursday, 3 January 2019 at 14.00 UTC Confirm action items Confirm questions for ICANN Org, if any

1 0

Draft FY20 Operating Plan and Budget Now Available for Your Feedback - ICANN CEO- Göran Marby
by Nathalie Peregrine Dec. 20, 2018

Dec. 20, 2018

https://www.icann.org/news/blog/draft-fy20-operating-plan-and-budget-now-av… Draft FY20 Operating Plan and Budget Now Available for Your Feedback As a not-for-profit organization working in the public interest, one of the ICANN organization's most important responsibilities is to develop an annual operating budget. We posted our Draft Operating Plan and Budget for Fiscal Year 2020<https://www.icann.org/news/announcement-2-2018-12-17-en>. Long-term financial planning and fiscal responsibility is necessary, and can only be achieved when the ICANN org, Board, and community work together to properly plan. In FY20, we continue to anticipate minimal growth in funding; it is forecasted at $140.1 million, up 2% from FY19. Expenses are budgeted below funding at $137.1 million. As a result of the budgeted increase of the Reserve Fund, the budgeted funding is slightly higher than last year. We've budgeted to contribute approximately $3 million (2 to 3% of the total budget) to the Reserve Fund, which will not have any negative impact to planned work. Annual allocation to the Reserve Fund will be the standard approach, at least until it is replenished to the minimum target level. This simply is the right thing to do. Constituency and fellowship travel support will remain at the same level as FY19, as will the ICANN org staff, which stands at approximately 400 people. To ensure the best support for the community's work, we have controls in place to hire or replace staff only when clearly required, but we still ensure the best support for the community's work after driving efficiency improvements. We've also brought the timeline for Public Comment forward to begin before the end of 2018. We've extended the comment period to 53 days to give you more time to review the documents. You will find five detailed documents, with content broken into six modules by topic: Contractual Compliance and Consumer Safeguards, Direct Policy Support, DNS Marketplace and Identifier Ecosystem, Technology and DNS Security, Engagement, and Reviews. The FY20 planning cycle is the final year of the current strategic plan, which makes it a transition year, as we are developing the 2021-2025 Strategic Plan in parallel. During FY20, we will use the new strategic plan to plan for FY21. You, the community, play an essential role in planning for the year ahead. We need and want your feedback and input. I look forward to productive discussions about this proposed Budget over the coming months before it's finalized in March 2019. Please take action! Share your comments here<https://www.icann.org/news/announcement-2-2018-12-17-en> during the Public Comment process. David A. Olive | Senior Vice President Policy Development Support ICANN | Internet Corporation for Assigned Names and Numbers 801 17th Street NW, Suite 400 | Washington, DC 20006<x-apple-data-detectors://3>

1 0

Meeting Invitation: Alternates & Observers / GNSO Temp Spec gTLD RD EPDP call / Thursday, 03 January 2019
by Andrea Glandon Dec. 20, 2018

Dec. 20, 2018

Dear all, Non-members can follow the EPDP call taking place on Tuesdays and Thursdays via the audio cast or view only Adobe Connect room. As requested and discussed on Tuesday's (14 August 2018) meeting, please note that an additional Adobe Connect room has been created for use by interested alternates and observers to be able to view-only the main EPDP Team Adobe Connect room. The view-only room will also broadcast the audio of the EPDP Team AC room, however, those in the view-only room will not be heard. Note that the audio cast stream will also remain available for now for those that prefer to use that option to listen live to the EPDP Team meeting. View-Only Adobe Connect room for alternates and observers: https://participate.icann.org/gnso-epdp-observers Meeting Audio Cast (for alternates and observers) To join the event, click on the link: Listen in browser: http://stream.icann.org:8000/stream01 [stream.icann.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__stream.icann.org-3A8000…> Listen in application such as iTunes: http://stream.icann.org:8000/stream01.m3u [stream.icann.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__stream.icann.org-3A8000…> Agenda wiki page: https://community.icann.org/x/-Aj_BQ Thank you. Kind Regards, Andrea

1 0

Re: [Gnso-epdp-team] language re: affiliated privacy/proxy companies
by Alan Greenberg Dec. 20, 2018

Dec. 20, 2018

If we use the “offered or made available by Registrar or its Affiliates” language, we need to add "or offered by an accredited P/P provider" “known Privacy or Proxy service” seems to cover both cases, although with someone vague language if the PPSAI ever completes. Alan From: Mark Svancarek (CELA) Sent: Wednesday, December 19, 2018 12:37 PM To: Anderson, Marc <mcanderson(a)verisign.com>; jbladel(a)godaddy.com; caitlin.tubergen(a)icann.org Subject: RE: [Gnso-epdp-team] language re: affiliated privacy/proxy companies Alternately: "or offered by an accredited P/P provider" Although this assumes that PPSAI proceeds. From: Mark Svancarek (CELA) Sent: Wednesday, December 19, 2018 11:41 To: 'Anderson, Marc' <mcanderson(a)verisign.com<mailto:mcanderson@verisign.com> >; jbladel(a)godaddy.com<mailto:jbladel@godaddy.com>; caitlin.tubergen(a)icann.org<mailto:caitlin.tubergen@icann.org> Subject: RE: [Gnso-epdp-team] language re: affiliated privacy/proxy companies Marc, I would prefer: “known Privacy or Proxy service” Which is a superset of “offered or made available by Registrar or its Affiliates” /msv From: Gnso-epdp-team < gnso-epdp-team-bounces(a)icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Anderson, Marc via Gnso-epdp-team Sent: Wednesday, December 19, 2018 09:09 To: jbladel(a)godaddy.com<mailto:jbladel@godaddy.com>; caitlin.tubergen(a)icann.org<mailto:caitlin.tubergen@icann.org> ; gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] language re: affiliated privacy/proxy companies Hi all, James makes a good point, I support his edit. Caitlin’s proposed text has a typo showing “proxy/proxy” where I assume “privacy/proxy” is intended. I have concerns with the text “…Registrar MUST return in response to any query full WHOIS data…” More specifically, I don’t think “any” actually means “any” in this context, “full” is undefined and should more appropriately be “unredacted” and WHOIS should be replaced with RDS or RDDS. I suggest: “…Registrar MUST return unredacted data in response to RDDS queries… “ I understand the reason for this recommendation is so that Registrars do not redact registration data that is already protected by a known Privacy or Proxy service. If the Privacy/Proxy service is operating as intended than personally identifiable information of the registrant has already been removed from the RDDS record and so further redacting it is redundant and creates an unnecessary hurdle for a requestor with a legitimate need to access the actual registration data behind the service. While Caitlin’s proposed language is generally clear, sometimes an explanation of the intent can be helpful in particular when it comes time to implement the policy. I suggest adding text along these lines: The intent of the working group in making this recommendation is that Registrars should not redact registration data that is already protected by a known Privacy/Proxy service. Redacting the RDS data of a Privacy/Proxy service provider shouldn’t be necessary for GDPR compliance and creates an unnecessary hurdle for a requestor with a legitimate need to access the actual registration data behind the service. On our Tuesday call we discussed the fact that it is not always know to the registrar that the registration is from a privacy/proxy service. I used the words “known Privacy or Proxy service” while Caitlin uses “offered or made available by Registrar or its Affiliates”. I’m not sure which is better and perhaps this is a question for registrars. I’m sensitive to registrars potentially getting sideways with compliance over this. On last Thursday’s (meting #34) call, Marika talked to us about the “policy change impact” section of the report which could include information on how to measure compliance. While we agreed on Thursday’s call to table that until we are a little further along in our policy recommendations, that does have me wondering if there is language we could add so that Registrars and compliance are on the same page as to how this should be implemented and enforced? We also spoke about the currently on hold Privacy/Proxy implementation effort. I understand them to be on hold waiting our final policy recommendations as that may inform or otherwise impact their work. I am maybe being overly cautious here, but I want to make sure nothing in our recommendations conflicts with or constrains the Privacy/Proxy group. Our group is responsible for GDPR compliance, their group for implementing a Privacy/Proxy policy. Some overlap may be unavoidable but we should leave Privacy/Proxy policy to them. I’m thinking adding language that this recommendation is subject to that policy might be prudent. If there is no conflict then this recommendation stands, but if it conflicts with their policy, then their policy takes precedent. Thanks, Marc From: Gnso-epdp-team < gnso-epdp-team-bounces(a)icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of James M. Bladel Sent: Wednesday, December 19, 2018 8:15 AM To: Caitlin Tubergen < caitlin.tubergen(a)icann.org<mailto:caitlin.tubergen@icann.org>>; GNSO EPDP <gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org> > Subject: [EXTERNAL] Re: [Gnso-epdp-team] language re: affiliated privacy/proxy companies Hi All- This language is mostly ok (thanks Caitlin!), but the parenthetical example sideswipes the natural vs. legal debate. Recommend we change this: (e.g. where data associated with a natural person is masked) To this: (e.g. where data associated with the Privacy/Proxy customer is masked) Thanks- J. ------------- James Bladel GoDaddy ________________________________ From: Gnso-epdp-team < gnso-epdp-team-bounces(a)icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of Caitlin Tubergen < caitlin.tubergen(a)icann.org<mailto:caitlin.tubergen@icann.org>> Sent: Tuesday, December 18, 2018 18:48 To: GNSO EPDP Subject: [Gnso-epdp-team] language re: affiliated privacy/proxy companies Dear All, Following up on an action item from today’s EPDP call, please find draft language regardingregistrar disclosure of privacy/proxy data to a requestor (section 2.6 of Appendix A of the Temp Spec).For ease of reference, the updated language is italicized. The EPDP Team recommends that in the case of a domain name registration where a Privacy/Proxy service,offered or made available by Registrar or its Affiliates in connection with a registration isused, (e.g. where data associated with a natural person is masked), Registrar MUST return in response to any query full WHOIS data, including the existing proxy/proxy pseudonymized email. (emphasis added) Please respond to the list if you have any issues with the above draft language. Best regards, Marika, Berry, and Caitlin _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team(a)icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team

1 0

Re: [Gnso-epdp-team] language re: affiliated privacy/proxy companies
by Mark Svancarek (CELA) Dec. 19, 2018

Dec. 19, 2018

Forwarding to list From: Mark Svancarek (CELA) Sent: Wednesday, December 19, 2018 12:37 PM To: Anderson, Marc <mcanderson(a)verisign.com>; jbladel(a)godaddy.com; caitlin.tubergen(a)icann.org Subject: RE: [Gnso-epdp-team] language re: affiliated privacy/proxy companies Alternately: "or offered by an accredited P/P provider" Although this assumes that PPSAI proceeds. From: Mark Svancarek (CELA) Sent: Wednesday, December 19, 2018 11:41 To: 'Anderson, Marc' <mcanderson(a)verisign.com<mailto:mcanderson@verisign.com>>; jbladel(a)godaddy.com<mailto:jbladel@godaddy.com>; caitlin.tubergen(a)icann.org<mailto:caitlin.tubergen@icann.org> Subject: RE: [Gnso-epdp-team] language re: affiliated privacy/proxy companies Marc, I would prefer: "known Privacy or Proxy service" Which is a superset of "offered or made available by Registrar or its Affiliates" /msv From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Anderson, Marc via Gnso-epdp-team Sent: Wednesday, December 19, 2018 09:09 To: jbladel(a)godaddy.com<mailto:jbladel@godaddy.com>; caitlin.tubergen(a)icann.org<mailto:caitlin.tubergen@icann.org>; gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] language re: affiliated privacy/proxy companies Hi all, James makes a good point, I support his edit. Caitlin's proposed text has a typo showing "proxy/proxy" where I assume "privacy/proxy" is intended. I have concerns with the text "...Registrar MUST return in response to any query full WHOIS data..." More specifically, I don't think "any" actually means "any" in this context, "full" is undefined and should more appropriately be "unredacted" and WHOIS should be replaced with RDS or RDDS. I suggest: "...Registrar MUST return unredacted data in response to RDDS queries... " I understand the reason for this recommendation is so that Registrars do not redact registration data that is already protected by a known Privacy or Proxy service. If the Privacy/Proxy service is operating as intended than personally identifiable information of the registrant has already been removed from the RDDS record and so further redacting it is redundant and creates an unnecessary hurdle for a requestor with a legitimate need to access the actual registration data behind the service. While Caitlin's proposed language is generally clear, sometimes an explanation of the intent can be helpful in particular when it comes time to implement the policy. I suggest adding text along these lines: The intent of the working group in making this recommendation is that Registrars should not redact registration data that is already protected by a known Privacy/Proxy service. Redacting the RDS data of a Privacy/Proxy service provider shouldn't be necessary for GDPR compliance and creates an unnecessary hurdle for a requestor with a legitimate need to access the actual registration data behind the service. On our Tuesday call we discussed the fact that it is not always know to the registrar that the registration is from a privacy/proxy service. I used the words "known Privacy or Proxy service" while Caitlin uses "offered or made available by Registrar or its Affiliates". I'm not sure which is better and perhaps this is a question for registrars. I'm sensitive to registrars potentially getting sideways with compliance over this. On last Thursday's (meting #34) call, Marika talked to us about the "policy change impact" section of the report which could include information on how to measure compliance. While we agreed on Thursday's call to table that until we are a little further along in our policy recommendations, that does have me wondering if there is language we could add so that Registrars and compliance are on the same page as to how this should be implemented and enforced? We also spoke about the currently on hold Privacy/Proxy implementation effort. I understand them to be on hold waiting our final policy recommendations as that may inform or otherwise impact their work. I am maybe being overly cautious here, but I want to make sure nothing in our recommendations conflicts with or constrains the Privacy/Proxy group. Our group is responsible for GDPR compliance, their group for implementing a Privacy/Proxy policy. Some overlap may be unavoidable but we should leave Privacy/Proxy policy to them. I'm thinking adding language that this recommendation is subject to that policy might be prudent. If there is no conflict then this recommendation stands, but if it conflicts with their policy, then their policy takes precedent. Thanks, Marc From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of James M. Bladel Sent: Wednesday, December 19, 2018 8:15 AM To: Caitlin Tubergen <caitlin.tubergen(a)icann.org<mailto:caitlin.tubergen@icann.org>>; GNSO EPDP <gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org>> Subject: [EXTERNAL] Re: [Gnso-epdp-team] language re: affiliated privacy/proxy companies Hi All- This language is mostly ok (thanks Caitlin!), but the parenthetical example sideswipes the natural vs. legal debate. Recommend we change this: (e.g. where data associated with a natural person is masked) To this: (e.g. where data associated with the Privacy/Proxy customer is masked) Thanks- J. ------------- James Bladel GoDaddy ________________________________ From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of Caitlin Tubergen <caitlin.tubergen(a)icann.org<mailto:caitlin.tubergen@icann.org>> Sent: Tuesday, December 18, 2018 18:48 To: GNSO EPDP Subject: [Gnso-epdp-team] language re: affiliated privacy/proxy companies Dear All, Following up on an action item from today's EPDP call, please find draft language regardingregistrar disclosure of privacy/proxy data to a requestor (section 2.6 of Appendix A of the Temp Spec).For ease of reference, the updated language is italicized. The EPDP Team recommends that in the case of a domain name registration where a Privacy/Proxy service,offered or made available by Registrar or its Affiliates in connection with a registration isused, (e.g. where data associated with a natural person is masked), Registrar MUST return in response to any query full WHOIS data, including the existing proxy/proxy pseudonymized email. (emphasis added) Please respond to the list if you have any issues with the above draft language. Best regards, Marika, Berry, and Caitlin

1 0

Question to ICANN re: Dispute Resolution Providers Data Processing Agreements
by Kurt Pritz Dec. 19, 2018

Dec. 19, 2018

Dear Dan and Trang: I am writing to you in your capacity as the ICANN organisation liaisons to the EPDP Team. As you may recall, the EPDP Team discussed issues related to the EPDP Team’s assessment of responsible parties, specifically in relation to dispute resolution providers. For more information regarding the Team’s assessment of responsible parties vis-à-vis ICANN and dispute resolution providers, please refer to p. 20 of the Initial Report <https://gnso.icann.org/sites/default/files/file/field-file-attach/epdp-gtld…>. As you recall, Recommendation #18 provides: “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.” In an email on the topic, the ICANN organization stated, “[a]dditional discussions and analyses may be needed on this topic.” This comment specifically went to the EPDP indication that, in dispute resolution processes, ICANN is the sole data controller. Following the discussion during the EPDP Team’s meeting <https://community.icann.org/display/EOTSFGRD/2018-12-04+EPDP+Team+call+%2331> on 4 December 2018, the Team agreed that no changes to Recommendation #18 were required. If ICANN org disagrees with or wishes to discuss the Recommendation #10 or EPDP Team’s assessment regarding the responsibility of the parties, please engage with the EPDP Team at your earliest convenience and in time to inform its deliberations as it prepares its Final Report. This, we think, will require a response prior to the end of year ICANN shutdown. Thanks very much for taking time to consider this. Sincerely, Kurt

2 1

Question to ICANN re: Data Escrow Data Processing Agreements
by Kurt Pritz Dec. 19, 2018

Dec. 19, 2018

Dear Dan and Trang: I am writing to you in your capacity as the ICANN organisation liaisons to the EPDP Team. As you may recall, the EPDP Team discussed Recommendation #6 from its Initial Report <https://gnso.icann.org/sites/default/files/file/field-file-attach/epdp-gtld…> during its meeting <https://community.icann.org/display/EOTSFGRD/2018-12-04+EPDP+Team+call+%2331> on 4 December 2018. The EPDP Team agreed to update the language of Recommendation #6 to the following: “[t]he EPDP Team recommends that ICANN Org develop legally-compliant data processing agreements with the data escrow providers.” While you are likely aware of this recommendation, the EPDP Team thought it important to request in writing that ICANN commence development of legally-compliant data processing agreements with its approved data escrow providers. The EPDP Team discussed and documented <https://community.icann.org/display/EOTSFGRD/e.+Data+Elements+Workbooks> the associated processing activities and responsible parties for registrar data escrow and registry data escrow. Please refer to Purpose E data processing workbooks <https://community.icann.org/display/EOTSFGRD/e.+Data+Elements+Workbooks> for additional information. In its analysis, the EPDP Team has identified ICANN as the controller and the contracted parties and data escrow providers as processors. Accordingly, the EPDP Team encourages you to proceed with developing legally-compliant data processing agreements with those roles as described here and in the Initial Report. If ICANN org disagrees with or wishes to discuss the EPDP Team’s request, analyis or assessment, please engage with the EPDP Team at your earliest convenience and in time to inform its deliberations as it prepares its Final Report. This, we think, will require a response prior to the end of year ICANN shutdown. Thanks very much for taking time to consider this. Sincerely, Kurt

2 1