December 2017 - Gdd-gnso-ppsai-impl

Materials, action items from Tuesday, 19 December 2017 Privacy/Proxy IRT call
by Caitlin Tubergen Dec. 22, 2017

Dec. 22, 2017

Dear Colleagues, Thank you for your participation on Tuesday’s Privacy/Proxy IRT call. For those who could not attend, I encourage you to review the recording and materials on the wiki, https://community.icann.org/display/IRT/19+December+2017. During the call, we continued to go through the comments you provided on the draft PPAA. Below, please find a brief summary of the issues we discussed. As always, we continue to welcome your feedback. Please provide feedback on the issues discussed this week and last week by Friday, 5 January 2018. Data Retention The IRT members on the call agreed to forego additional GDPR discussions at this time. All previously-flagged IRT concerns will be noted for public comment, and we will update the IRT as we receive additional guidance on GDPR matters. If a solution is developed in GDPR before the PPAA is finalized, we will work with the IRT to amend the PPAA accordingly. In reference to section 3.2.2 and 3.2.3, Steve Metalitz suggested adding language to the effect of: “During the Term of this Agreement and for one year thereafter unless applicable law dictates a different period, Provider (itself or by its agent(s)) shall maintain the following records[.]” (Proposed new language is italicized.) Please let us know if you agree with this change and/or if you propose different language. Domain Name Cancellation Ensure any reference to a P/P Provider cancelling/deleting a domain name is removed as Providers cannot cancel/delete names. With respect to section 3.5.17, how should UDRP Providers/Registrars proceed in a UDRP case when an unaffiliated P/P Provider is involved? For example, should the UDRP Provider contact the unaffiliated P/P Provider to verify the underlying registrant/customer information? (Please note the registrar would not be able to provide the underlying registrant information to the UDRP Provider, as it would not have this information.) Question to the IRT: Please provide any additional suggestions/comments in relation to the unaffiliated P/P Provider and UDRP issue. Publication of Information on Websites Section 3.8.3 – publication of fees. Theo Geurts notes this provision may be difficult for wholesale registrars. Steve Metalitz noted that the providers would be responsible for displaying provider fees, not registrar fees. Question to IRT: Please provide further information on why this provision is an issue. Section 3.11 – some IRT members noted Providers should not be required to publish officer information on their websites. Other IRT members disagree and note this information is necessary. Question to IRT: Please provide further information on why the provision of officer information is an issue and/or why the publication of officer information is necessary. Our next IRT meeting will be Tuesday, 9 January. Michelle will be sending out a reminder for that meeting. I have attached an updated Issues List. Please continue to respond to the list with concerns, questions and ideas. I wish everyone a wonderful and restful holiday season, and I look forward to our continued collaboration in 2018! Kind regards, Caitlin -- Caitlin Tubergen Registrar Services and Engagement Senior Manager ICANN 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094 Office: +1 310 578 8666 Mobile: +1 310 699 5326 Email: caitlin.tubergen(a)icann.org

1 0

Materials, action items from Tuesday 12 December Privacy/Proxy IRT call
by Caitlin Tubergen Dec. 15, 2017

Dec. 15, 2017

Dear Colleagues: Thank you for your attendance and participation on this week’s Privacy/Proxy IRT call. If you were unable to attend, I encourage you to review the recording and materials posted on the wiki, https://community.icann.org/display/IRT/12+December+2017. The IRT is making its way through the attached Issues List, and I updated the Issues List to reflect Tuesday’s discussion. On our next call on Tuesday, 19 December, we will discuss the issue of data collection, retention, escrow, GDPR concerns, etc., which is next on the Issues List. Provided we conclude the discussion of data collection, we will continue to work our way through the issues list in order. Please provide any additional input you have on the topics discussed on Tuesday (summary provided below) no later than next Friday, 23 December. Summary of today’s topics, questions and action items (updated issues list, with complete IRT input, attached): Definitional Concerns The IRT members on the call seem to be in agreement that the PPAA definitions that match RAA definitions should not be changed. Specifically, these definitions include: gTLD Zone-File Data (section 1.13) Personal Data (section 1.19) Provider Approval (section 1.21) Registered Name (section 1.24) Registered Name Holder (section 1.25) Reseller (section 1.33) Registered name is “sponsored” (section 1.36) The IRT members on the call expressed no objections to these definitions: Person (section 1.18) Registration Data Directory Service (section 1.28) The following definitions require further discussion and/or amendment: Affiliated Provider (Section 1.4) (Please see my email of 13 December for further information.) Customer; Privacy Service; Proxy Service (Section 1.8; 1.22; 1.24) – The definition of customer was added for the sake of clarity and consistency since the terms beneficial user, customer, licensee, and underlying registrant were not used consistently in the Final Report. The definition of Customer is also cross-referenced in the definition of Privacy Service and Proxy Service; accordingly, these definitions are not an exact match of the Final Report/Privacy/Proxy Specification. Some IRT members expressed concerns with the removal of the term beneficial user, as there was a reason this term was used. No one on the call expressed the particular reason and/or difference between these terms. We are seeking additional feedback on the specific difference and/or concern between customer, beneficial user, underlying registrant, and licensee. It would also be helpful if you could propose definitions of licensee/beneficial user if you believe we need to add more definitions than Customer. Law Enforcement Authority (Section 1.16): IRT feedback: The language re: applicable jurisdiction should be looked at in conjunction with the LEA Framework to specify that the provider may have obligations outside the PPAA, and this definition does not negate that. Service Provider (Section 1.37): Change all references from Provider to Service Provider for consistency with the defined term. Working Group (Section 1.43): There seems to be some disagreement regarding who should comprise the Working Group – if it should just be Service Providers, or if it should include a cross-section of the community. Additionally, a few IRT members suggested deleting the phrase, “provided, that, if the Generic Names Supporting Organization (the “GNSO”) forms a stakeholder group for Service Providers (the “Provider Stakeholder Group”), then following the date of the formation of the Provider Stakeholder Group, the Provider Stakeholder Group shall appoint the representatives of the Service Providers and other members of the community to constitute the Working Group. The Working Group will serve as a working group to consult on amendments to the Service Provider Agreements (excluding bilateral amendments pursuant to Section 6.9).” Additional IRT Feedback is requested on the definitions of Affiliated Provider, Customer, Law Enforcement Authority, Privacy Provider, Proxy Provider, and Working Group. Drafting Concerns Sections 2.3.2 and 2.3.3 General Obligations of ICANN– no IRT members on the call expressed concerns with this section. Section 2.4 Use of ICANN-accredited Providers – IRT member (Margie Milam) suggestion: “intends to abide” is weak language – consider redrafting to “shall abide” or “shall reasonably abide” Section 3.1 General Obligations of Service Provider – IRT members recommend keeping WILL, instead of MAY, in the provision: During the Term of this Agreement, [Service] Provider agrees that it will provide the Services in accordance with this Agreement As always, if you would like to raise any other issues or feedback, please feel free to send to the list at any time. I look forward to Tuesday’s call, where we will continue working our way through the issues list. Kind regards, Caitlin

1 0

Suggested Definitions for 1.4 & 1.5
by Darcy Southwell Dec. 14, 2017

Dec. 14, 2017

These are the revised definitions I would propose from today's meeting regarding Affiliate Provider and Affiliated Registrar: 1.3 “Affiliate” means a Person that, directly or indirectly, through one or more intermediaries, Controls, is controlled by, or is under common control with, the Person specified. 1.4 "Affiliated Service Provider" is a Service Provider that is an Affiliate of a Registrar. 1.5. "Affiliated Registrar" is a Registrar that is an Affiliate of a Service Provider." 1.37 “Service Provider” means a Person that provides Privacy Services or Proxy Services, who that has been Accredited and entered into an agreement with ICANN substantially similar to this Agreement. Thanks, Darcy __________ *Darcy Southwell *| Compliance Officer M: +1 503-453-7305 │ Skype: darcy.enyeart

5 4

Re: [Gdd-gnso-ppsai-impl] [Ext] Re: Materials, action items from 17 Oct Privacy/Proxy IRT call
by Caitlin Tubergen Dec. 12, 2017

Dec. 12, 2017

Dear Colleagues, Further to Sara’s suggestion in this message and the accompanying discussion on last Tuesday’s call, we have compiled a table which breaks down the sections of the draft PPAA, and divides the sections into affiliated and unaffiliated requirements. We can use this table for discussion purposes as we begin going through the updated issues list on tomorrow’s call. Thank you! Kind regards, Caitlin Tubergen Registrar Services and Engagement Senior Manager ICANN 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094 Office: +1 310 578 8666 Mobile: +1 310 699 5326 Email: caitlin.tubergen(a)icann.org From: Sara Bockey <sbockey(a)godaddy.com> Date: Friday, December 1, 2017 at 10:09 AM To: Caitlin Tubergen <caitlin.tubergen(a)icann.org>, "gdd-gnso-ppsai-impl(a)icann.org" <gdd-gnso-ppsai-impl(a)icann.org> Cc: "Roman, Peter (CRM)" <Peter.Roman(a)usdoj.gov>, Sara Bockey <sbockey(a)godaddy.com>, 'Darcy Southwell' <darcy.southwell(a)endurance.com> Subject: [Ext] Re: [Gdd-gnso-ppsai-impl] Materials, action items from 17 Oct Privacy/Proxy IRT call Hi all, In my last-minute reviewing of the PPAA, I’ve had a few additional thoughts: We need to revisit PPAA, Spec 2: Customer Data Accuracy. This entire Spec needs to be revisited and made clearer since the entire spec is dependent on whether or not the Service Provider is affiliated or non-affiliated. It’s very disjointed, it starts out Section 1, this is what you need to do, then in Section 3, it says you don’t need to do this if you are an affiliated Provider, and then in Section 4 it goes back to this is what you need to do and forgets about section 3. It seems to me that this entire section is dependent on if there is an Affiliated Registrar. This section got me thinking and IMHO, in addition to going thru every comment that has been submitted and sorting through those issues, I think we need to take a serious look at the approach of the PPAA. I think the document as it stands is not recognizing the Service Provider as an Affiliate of an ICANN accredited Registrar. I’m wondering if what we really need is 2 separate PPAAs – one for an Affiliated Service Provider and one for a Non-Affiliated Service Provider. For the Affiliated Service Provider, it should set out at the very beginning the affiliate relationship, and both parties would sign. The basic idea would be something like: Service Provider X, as an Affiliate of ICANN accredited Registrar A, enters into this PPAA to provide a privacy/proxy service. Registrar A, as a party to this agreement, agrees to uphold its obligations under the RAA and its related consensus policies. Should the relationship between Service Provider X and Registrar A cease, so shall this agreement, and Service Provider X will have ___ number of days to secure a new affiliate registrar and enter into a new Affiliated PPAA or complete the Non-Affiliated process and sign the Non-Affiliate PPAA. It needs work, I know, but just trying to illustrate the idea. I think this would allow the affiliated agreement to be considerably more light weight. The Non-Affiliate PPAA would be more in line with what we have now (and, granted, would need additional work). If the Affiliate Provider became unaffiliated, it would need to go thru an accreditation process to ensure it meet the requirements. So there would need to be 2 accreditation procedures, but again I’m thinking the Affiliated process would be relatively light weight based on the relationship of the provider to the accredited registrar. Also, we need to correct some of the language in the PPAA. Specifically, as I’ve stated numerous times before, I think staff’s use of “Customer” in place of RNH is problematic when the PPAA is an extension of/referenced in the RAA, particularly when considering the above line of thinking. The 2013 RAA defines “Registered Name” as a domain name within the domain of a gTLD, about which a gTLD Registry Operator (or an Affiliate or subcontractor thereof engaged in providing Registry Services) maintains data in a Registry Database, arranges for such maintenance, or derives revenue from such maintenance, and “Registered Name Holder” is defined as the holder of a Registered Name. This is a service for the RNH, provided via an Affiliate Registrar, the use of “customer” is problematic. I’ll admit I’ve not thought thru all the issues and this is kind of loose, but it’s an idea that came to mind and something we might ought to consider so I’m putting a marker down to discuss the above in case it offers a better path forward. Happy to hear what others think. Sara sara bockey sr. policy manager | GoDaddy™ sbockey(a)godaddy.com 480-366-3616 skype: sbockey This email message and any attachments hereto is intended for use only by the addressee(s) named herein and may contain confidential information. If you have received this email in error, please immediately notify the sender and permanently delete the original and any copy of this message and its attachments. From: Caitlin Tubergen <caitlin.tubergen(a)icann.org> Date: Thursday, November 30, 2017 at 5:05 PM To: "gdd-gnso-ppsai-impl(a)icann.org" <gdd-gnso-ppsai-impl(a)icann.org>, Sara Bockey <sbockey(a)godaddy.com>, 'Darcy Southwell' <darcy.southwell(a)endurance.com> Cc: "Roman, Peter (CRM)" <Peter.Roman(a)usdoj.gov> Subject: Re: [Gdd-gnso-ppsai-impl] Materials, action items from 17 Oct Privacy/Proxy IRT call Thank you, Steve, and thank you to the registrars who submitted comments. I will compile all of the comments, and we can begin going through the comments on Tuesday’s call. If any other IRT members have comments on the draft PPAA, please submit them by the deadline of Friday, 1 December. Kind regards, Caitlin Tubergen Registrar Services and Engagement Senior Manager ICANN 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094 Office: +1 310 578 8666 Mobile: +1 310 699 5326 Email: caitlin.tubergen(a)icann.org From: Gdd-gnso-ppsai-impl <gdd-gnso-ppsai-impl-bounces(a)icann.org> on behalf of "Metalitz, Steven" <met(a)msk.com> Reply-To: "gdd-gnso-ppsai-impl(a)icann.org" <gdd-gnso-ppsai-impl(a)icann.org> Date: Thursday, November 30, 2017 at 2:16 PM To: 'Sara Bockey' <sbockey(a)godaddy.com>, 'Darcy Southwell' <darcy.southwell(a)endurance.com>, "'gdd-gnso-ppsai-impl(a)icann.org'" <gdd-gnso-ppsai-impl(a)icann.org> Subject: Re: [Gdd-gnso-ppsai-impl] Materials, action items from 17 Oct Privacy/Proxy IRT call PPSAI colleagues, I offer the following comments and suggested edits regarding the Oct. 20 redline version of the PPAA. I may have a few other suggestions by tomorrow’s deadline, and will definitely have responses later to some of the other proposed edits that have been sent to the list. (And thanks to Theo and colleagues for their comprehensive review of the document!) First, I would reiterate the suggestions made in my Oct. 21 posting to the list, as follows: Subsection 3.5.3.15: strike “should” and insert “shall,” for consistency with parallel provisions throughout this section 3.5. Section 3.7, third line from the bottom: “employee” should be “employ.” Section 3.17.1: I suggest adding the words “as applicable” or “to the extent applicable” at the end of the section. Not every Disclosure or Publication request that Provider receives will fall under the IP or LEA disclosure frameworks. Section 5.7.3: the notice that the suspended Provider must send to customers should specify “that it is unable to offer or provide the Services for any new registrations” (adding the last 4 words). A suspended Provider can (and indeed must) provide the Services to its current customers. [Note that the phrasing “any additional registrations” might be more accurate here, and in the corresponding provision of 5.7.1 --- otherwise it might be possible for a suspended provider to being providing services for the first time to an existing registration whose registrant decides to engage a service.] Here are some additional suggestions: Section 1.43: strike “comprising the Working Group,” insert “representatives of the Service Providers.” This issue is noted on page 2 of the Discussion Items document. Section 3.5.3.3: since this has to do with p/p services and not with registration per se, the references to “initial registration and each renewal registration” should be changed to something like “each initial agreement to provide Services and each renewal or extension of such agreement.” I believe this is also responsive to Theo’s sticky note on the RrSG redline for this section. Section 3.8.1 (specifying what needs to be stated on request forms) should include a cross-reference to section 3.8.2 (requiring publication of links to request forms in some circumstances). Alternatively, perhaps the order of these two sections should be reversed. Section 3.8.5.5 needs some rephrasing. Reveal is not a defined term in the PPAA, and the provider does not itself Publish data in the RDS (the registrar or registry does that), but can cause it to be Published. This may a rare instance in which use of the passive voice may be preferable (“the circumstances under which the Customer’s identity or contact data will be published in the RDDS….”). Section 3.19: substitute “shall” for “should.” In fact the entire document should be reviewed to see where this change is needed. Section 5.3: this is another issue I raised in my Oct. 21 posting: “Section 5.3 does not give ICANN the right to substitute the new version of the agreement, it gives that right to the provider. Furthermore, 5.3 addresses the scenario in which the new agreement is swapped in during the term of the current agreement. The point I was trying to raise on the call (and I am sorry if this was not clear) is ensuring that all renewals of the agreement at the end of the term reflect the most recent version. As currently drafted, section 5.2 seems to give the provider the option of renewing under the terms of the old agreement (“under the terms and conditions of this agreement”), even if it has been superseded by a new form of agreement that is materially different. This could be fixed by adding a subsection 5.2.5 along the following lines: ‘5.2.5: this Agreement has been superseded by a revised form accreditation agreement for the provision of the Services (“Updated PPAA”) that is materially different from this Agreement, in which case the right of renewal provided by this section shall be under the terms and conditions of the Updated PPAA.’” Section 5.7.4: consider inserting at the end of the first sentence “or its invocation of section 5.5.7,” which is another path ICANN could take to deal with the situation of an uncured “endangerment” scenario. Section 7.4.1: shouldn’t the Working Group be the party to receive the notice re revision of the Agreement? This would be consistent with the rest of section 7.4. Glad to try to answer any questions about these. Steve Metalitz Steven J. Metalitz | Partner, through his professional corporation T: 202.355.7902 | met(a)msk.com Mitchell Silberberg & Knupp LLP | www.msk.com[msk.com] 1818 N Street NW, 8th Floor, Washington, DC 20036 THE INFORMATION CONTAINED IN THIS E-MAIL MESSAGE IS INTENDED ONLY FOR THE PERSONAL AND CONFIDENTIAL USE OF THE DESIGNATED RECIPIENTS. THIS MESSAGE MAY BE AN ATTORNEY-CLIENT COMMUNICATION, AND AS SUCH IS PRIVILEGED AND CONFIDENTIAL. IF THE READER OF THIS MESSAGE IS NOT AN INTENDED RECIPIENT, YOU ARE HEREBY NOTIFIED THAT ANY REVIEW, USE, DISSEMINATION, FORWARDING OR COPYING OF THIS MESSAGE IS STRICTLY PROHIBITED. PLEASE NOTIFY US IMMEDIATELY BY REPLY E-MAIL OR TELEPHONE, AND DELETE THE ORIGINAL MESSAGE AND ALL ATTACHMENTS FROM YOUR SYSTEM. THANK YOU. From: Metalitz, Steven Sent: Tuesday, November 07, 2017 11:42 AM To: 'Sara Bockey'; Darcy Southwell; gdd-gnso-ppsai-impl(a)icann.org Subject: RE: [Gdd-gnso-ppsai-impl] Materials, action items from 17 Oct Privacy/Proxy IRT call I agree with a lot of what Darcy says. Let me make sure my view is clearly stated. Most of the items Darcy identifies are completely appropriate for discussion in our team before the documents are finalized. These issues include: perceived discrepancies between the WG Final Report and the implementation documents; loose ends in the Law Enforcement disclosure framework; and clarifying the status of each of the four documents under review. I support addressing these points on our next call so that we can continue to make progress. And based on the postings made to our list over the last couple of weeks, I would certainly be comfortable with some relaxation of the deadline for proposing edits to the accreditation agreement – if necessary, to December 1. My concerns are focused primarily on the suggestion that we can’t move forward until we determine whether our recommendations are GDPR-compliant. To me that sounds like some on the IRT want to suspend work until ICANN’s separate work on GDPR is concluded. If that is not what is meant, then I would ask proponents of that view to clarify just how they think we should proceed at this point. I am also sad to see the IRTP-C issue brought up again. I thought we had reached agreement that the current suspension of ICANN enforcement of this aspect of that policy could be continued until an appropriate group is formed to address it; or put another way, that we could proceed to get our PPSAI implementation plan out for public comment without delaying it until the IRTP-C issue is resolved. That is my recollection, anyway, but if I am mistaken then please show me how. Finally I will repeat my question of whether our call time on 11/14 remains at 1400 UTC or whether it will be moved an hour later to preserve the usual start time in most Northern Hemisphere time zones. Steve Steven J. Metalitz | Partner, through his professional corporation T: 202.355.7902 | met(a)msk.com Mitchell Silberberg & Knupp LLP | www.msk.com[msk.com] 1818 N Street NW, 8th Floor, Washington, DC 20036 THE INFORMATION CONTAINED IN THIS E-MAIL MESSAGE IS INTENDED ONLY FOR THE PERSONAL AND CONFIDENTIAL USE OF THE DESIGNATED RECIPIENTS. THIS MESSAGE MAY BE AN ATTORNEY-CLIENT COMMUNICATION, AND AS SUCH IS PRIVILEGED AND CONFIDENTIAL. IF THE READER OF THIS MESSAGE IS NOT AN INTENDED RECIPIENT, YOU ARE HEREBY NOTIFIED THAT ANY REVIEW, USE, DISSEMINATION, FORWARDING OR COPYING OF THIS MESSAGE IS STRICTLY PROHIBITED. PLEASE NOTIFY US IMMEDIATELY BY REPLY E-MAIL OR TELEPHONE, AND DELETE THE ORIGINAL MESSAGE AND ALL ATTACHMENTS FROM YOUR SYSTEM. THANK YOU. From: Sara Bockey [mailto:sbockey@godaddy.com] Sent: Tuesday, November 07, 2017 11:07 AM To: Darcy Southwell; gdd-gnso-ppsai-impl(a)icann.org; Metalitz, Steven Cc: Sara Bockey Subject: Re: [Gdd-gnso-ppsai-impl] Materials, action items from 17 Oct Privacy/Proxy IRT call Well said, Darcy. Agree 100%. sara bockey sr. policy manager | GoDaddy™ sbockey(a)godaddy.com 480-366-3616 skype: sbockey This email message and any attachments hereto is intended for use only by the addressee(s) named herein and may contain confidential information. If you have received this email in error, please immediately notify the sender and permanently delete the original and any copy of this message and its attachments. From: Darcy Southwell <darcy.southwell(a)endurance.com> Date: Tuesday, November 7, 2017 at 8:47 AM To: "gdd-gnso-ppsai-impl(a)icann.org" <gdd-gnso-ppsai-impl(a)icann.org>, "Metalitz, Steven" <met(a)msk.com>, Sara Bockey <sbockey(a)godaddy.com> Subject: Re: [Gdd-gnso-ppsai-impl] Materials, action items from 17 Oct Privacy/Proxy IRT call I agree with Theo. The scope has changed and implementation is impacted by GDPR. While I appreciate that Steve wants to move forward expeditiously, I don’t believe we can do so without jeopardizing the creation of an effective program. Further, in just the last week or so, issues have been raised about implementation language contradicting the policy. The role of an IRT is to implement the consensus policy produced in the PDP and we need to spend sufficient time reviewing and discussing the implementation to ensure we’re not changing policy. Similarly, I think there were questions raised about the proposed framework Public Safety Working Group. In addition to policy creep, I believe concerns were expressed that staff failed to modify the proposed framework based on the feedback from IRT participants. Rather than picking through the documents line by line, it seems like we should step back and have a discussion about the concepts to ensure we’re making progress toward an effective implementation that reflects the policy. There have also been repeated questions raised about the over-engineering of this implementation. Because many of the meetings have focused on reviewing language from a specific section (rather than reviewing issues as whole items), it seems like we haven’t gotten past this issue, and should probably take a fresh look at that to ensure we’re not making this implementation more complicated than it needs to be. We all know that doesn’t lead us to a better implementation. Right now, we have four draft documents for review/input: (1) accreditation agreement, (2) de-accreditation process, (3) applicant guide, and (4) data escrow specification. For many members, these require operational and legal review (at a minimum). Many registrars have commented that 1 December is the earliest they can provide full feedback given the complexity of these documents (although not all have committed to that date). Given these issues, as well as the fact that the privacy/proxy challenge stemming from IRTP-C needs to be added to this IRT for a solution, we need to take a step back and address these critical issues first. This isn’t about derailing the IRT; it’s about ensuring we don’t create an implementation that’s an operational nightmare for providers as well as registrants and end users – and that means addressing these critical issues first. Thanks, Darcy From: <gdd-gnso-ppsai-impl-bounces(a)icann.org> on behalf of theo geurts <gtheo(a)xs4all.nl> Reply-To: <gdd-gnso-ppsai-impl(a)icann.org> Date: Monday, November 6, 2017 at 12:27 PM To: <gdd-gnso-ppsai-impl(a)icann.org>, "Metalitz, Steven" <met(a)msk.com>, Sara Bockey <sbockey(a)godaddy.com> Subject: Re: [Gdd-gnso-ppsai-impl] Materials, action items from 17 Oct Privacy/Proxy IRT call Hi Steve, Vicky, Now your argument is logical and makes sense. Yes, as I mentioned before, CPH's will implement privacy services on many different levels to comply with the GDPR, we agree here. My biggest problem with the PPSAI IRT is the changing dynamics. The WG contemplated and discussed and made recommendations based on a very fixed situation. In my opinion, privacy services should not be used as bandaid for data protection problems. Complying with data protection laws was not the driving force during the WG days, and now it is. I think the scope of the IRT has changed and we should deal with this before we move on. We need to think a little smarter and deeper here before we unleash this to many contracted parties who have zero experience with these services and will be required to implement this to comply with data protection laws. So how do we do that? I think a fixed set of procedures and contractual agreements are essential, yet I do not want us to enter into a situation that causes more issues and forces providers into a situation that we need to ask compliance to defer. https://www.icann.org/resources/pages/contractual-compliance-statement-2017… I think that scenario is unwanted for everyone on the IRT is it not? Thanks, Theo Geurts On 6-11-2017 19:40, Metalitz, Steven wrote: I strongly second Vicky’s comments. The ongoing ICANN work re GDPR is of course very important, but let’s not let it derail progress on the path we have moved so far along toward a P/P service accreditation framework to present to the community. In that regard, I have some sympathy (empathy?) for those requesting a relaxation of the comment deadline in light of so much other activity demanding our attention. May I suggest that we try to get as many proposed edits onto the list before our November 14 call (with much thanks to those who have already done so), with the goal of dealing with them then if possible, but leaving the door open for further edits over the next couple of weeks if necessary. Finally, some ICANN groups are adjusting the scheduling of their calls to reflect the return to standard time in North America and Europe. Is this group doing so as well? If our calls stay at 1400 UTC that is now 9 am EST and 6 am for those on Pacific time. Moving to 1500 UTC would retain the pre-existing local start times, I believe. Steve Metalitz Steven J. Metalitz | Partner, through his professional corporation T: 202.355.7902 | met(a)msk.com Mitchell Silberberg & Knupp LLP | www.msk.com[msk.com] 1818 N Street NW, 8th Floor, Washington, DC 20036 THE INFORMATION CONTAINED IN THIS E-MAIL MESSAGE IS INTENDED ONLY FOR THE PERSONAL AND CONFIDENTIAL USE OF THE DESIGNATED RECIPIENTS. THIS MESSAGE MAY BE AN ATTORNEY-CLIENT COMMUNICATION, AND AS SUCH IS PRIVILEGED AND CONFIDENTIAL. IF THE READER OF THIS MESSAGE IS NOT AN INTENDED RECIPIENT, YOU ARE HEREBY NOTIFIED THAT ANY REVIEW, USE, DISSEMINATION, FORWARDING OR COPYING OF THIS MESSAGE IS STRICTLY PROHIBITED. PLEASE NOTIFY US IMMEDIATELY BY REPLY E-MAIL OR TELEPHONE, AND DELETE THE ORIGINAL MESSAGE AND ALL ATTACHMENTS FROM YOUR SYSTEM. THANK YOU. From: gdd-gnso-ppsai-impl-bounces(a)icann.org [mailto:gdd-gnso-ppsai-impl-bounces@icann.org] On Behalf Of Victoria Sheckler Sent: Tuesday, October 31, 2017 5:55 PM To: gdd-gnso-ppsai-impl(a)icann.org; Sara Bockey Subject: Re: [Gdd-gnso-ppsai-impl] Materials, action items from 17 Oct Privacy/Proxy IRT call Please note that ICANN’s work on GDPR’s on a separate track and that one thing we know almost for sure is that the adoption of rational, predictable rules for privacy/proxy will be more important post-GDPR than it ever was. So please let’s get those rules in place as expeditiously as possible. On 30-10-2017 11:32, Sara Bockey wrote: Caitlin, Thanks for the revised docs. A few items at first glance that need to be revised, as I believe they have been discussion/raised before. I will take a closer look and follow up with additional edits, but in the meantime… Edit the definitions of Proxy Service and Privacy Service to match the definitions provided in the Final Report/2013 RAA The definitions of Privacy Service and Proxy Service reflect those in the 2013 RAA. In this context, the 2013 RAA also defines “Registered Name” as a domain name within the domain of a gTLD, about which a gTLD Registry Operator (or an Affiliate or subcontractor thereof engaged in providing Registry Services) maintains data in a Registry Database, arranges for such maintenance, or derives revenue from such maintenance, and “Registered Name Holder” is defined as the holder of a Registered Name. It’s noted that ICANN staff has replace “Registered Name Holder” with “Customer” in many instances, but I question the logic in that since it is inconsistent with the RAA. Edit Sections 3.5.3.3. thru 3.5.3.6 to take into consideration GDPR requirements regarding consent. Consent must be explicitly given for each purpose and can be withdrawn at any time and not a requirement for registration or use of the service. Therefore, 3.5.3.3. – 3.5.3.6 (at a minimum) are not compatible and must be revise. Edit section 3.12.2, as it still contains new language that has been added since the IRT agreement on language in August. The first sentence in its entirety should be removed. The section should start with “Well founded…” Additionally, the following sections need revision or at a minimum further discuss by the IRT Edit Section 3.14 to remove the language re no automation. This is not feasible. This language must be removed: Provider shall not use high-volume, automated electronic processes (for example, processes that do not utilize human review) for sending Requests or responses to Requests to Requesters or Customers in performing any of the steps in the processes outlined in the Intellectual Property Disclosure Framework Specification. Edit Section 3.15 – Labeling – to remove excessive language. Provider shall ensure that each Registered Name for which Provider is providing the Services is clearly labeled as such in the Registration Data Directory Service, as specified in the Labeling Specification attached hereto, and shall otherwise comply with the requirements of the Labeling Specification attached hereto. This language is duplicative and not necessary. Let’s not add unnecessary words to this already long document. If there are doing to be extra works, perhaps mention complying with applicable local laws in light of GDPR. sara bockey sr. policy manager | GoDaddy™ sbockey(a)godaddy.com 480-366-3616 skype: sbockey This email message and any attachments hereto is intended for use only by the addressee(s) named herein and may contain confidential information. If you have received this email in error, please immediately notify the sender and permanently delete the original and any copy of this message and its attachments. From: <gdd-gnso-ppsai-impl-bounces(a)icann.org> on behalf of Caitlin Tubergen <caitlin.tubergen(a)icann.org> Reply-To: "gdd-gnso-ppsai-impl(a)icann.org" <gdd-gnso-ppsai-impl(a)icann.org> Date: Wednesday, October 25, 2017 at 4:44 AM To: "gdd-gnso-ppsai-impl(a)icann.org" <gdd-gnso-ppsai-impl(a)icann.org> Subject: [Gdd-gnso-ppsai-impl] Materials, action items from 17 Oct Privacy/Proxy IRT call Dear Colleagues, Thanks so much for your participation on today’s Privacy/Proxy IRT call. For those who could not attend, I encourage you to review the recording and materials on the wiki, https://community.icann.org/display/IRT/24+October+2017[community.icann.org]. During the call, we discussed an overview of the changes to the draft PPAA. Please note that ICANN proposed a deadline of Tuesday, 14 November for all comments, concerns, and edits to the draft PPAA. The changes from the last iteration, provided to the IRT in July, have been highlighted in the attached issues list. Please respond to the list if you would like to request a longer review period. During ICANN60, we will be presenting an overview of the P/P program’s status to the community. Attached, please find the slide deck for the presentation. To highlight a few notes from the IRT’s discussion this morning, we received feedback to: Edit the definition of Working Group in Section 1.43, to specify that the Provider Stakeholder Group, if formed, shall only appoint the provider representatives of the Working Group, and the GNSO may appoint other members of the community. Add back in the previously-deleted Code of Conduct language in Section 3.5.1. Add back in the previously-deleted review provision in Section 7 of the Customer Data Accuracy Program Specification. If you believe the above items do not reflect the intent of the Working Group’s recommendations, please reply to the list by 14 November 2017. Thank you, and safe travels to those of you attending ICANN 60! Kind regards, Caitlin Tubergen Registrar Services and Engagement Senior Manager ICANN 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094 Office: +1 310 578 8666 Mobile: +1 310 699 5326 Email: caitlin.tubergen(a)icann.org _______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl(a)icann.org https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl _______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl(a)icann.org https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl _______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl(a)icann.org https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl _______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl(a)icann.org https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl

4 3

FW: [Ext] RE: Agenda + Updated Draft PPAA with IRT comments
by Caitlin Tubergen Dec. 7, 2017

Dec. 7, 2017

From: "Roman, Peter (CRM)" <Peter.Roman(a)usdoj.gov> Date: Tuesday, December 5, 2017 at 5:40 AM To: Caitlin Tubergen <caitlin.tubergen(a)icann.org>, "gdd-gnso-ppsai-impl(a)icann.org" <gdd-gnso-ppsai-impl(a)icann.org> Subject: [Ext] RE: Agenda + Updated Draft PPAA with IRT comments Good morning all – I have a few additional comments on the draft: Overall – this agreement seems to misunderstand the point of having a high priority request mechanism. High priority requests are usually emergencies where victims are moments away from danger. Not requiring immediate responses to these requests renders them moot. A request that is answered within 24 hours, but 20 hours after the victim is dead, does not respect the importance of the request or the imminence of the danger. 3.12.2 - If the abuse contact point is not monitored 24/7, how are providers going to respond to high priority requests in time? SPECIFICATION 5: LAW ENFORCEMENT AUTHORITY DISCLOSURE FRAMEWORK SPECIFICATION 3.1 – This is the same issue as for 3.12.2 in the main bod of the agreement, if the point of contact is not required to be available 24/7, it defeats the purpose of the high priority requests. 3.2.1 – This part of the receipt process combined with 4.1 creates a two day window before providers have to even address whether a request is high priority, again defeating the purpose of having a high priority request. 4.1.1 – By waiting to respond until after the Receipt Process is complete, which can take up to two days under 3.2.1, the agreement renders the high priority request provisions moot. 4.1.2 – Responding to high priority requests within 24 hours is not sufficient. A request that is answered within 24 hours, but 20 hours after the victim is dead, does not respect the importance of the request or the imminence of the danger. High priority requests need to be responded to more or less immediately. 4.3.2 – The Provider should be required to disclose changes to the timeframe for notification of the Customer to LEA Requestors with current requests (i.e., “should” should be “must”). If the Customer is a target, notifying the Customer without alerting LEA can lead to the Customer destroying evidence, fleeing, or even threatening or killing informants who led law enforcement to the Customer’s account in the first place. 5.1 – I do not understand the purpose of this provision. LEA is not a party to this agreement and the agreement has no ability to bind LEA actions if the Provider fails to respond to a request. 6.2 – I do not understand the purpose of this provision either. LEA is not a party to this agreement and the agreement has no ability to bind LEA use of the evidence provided by the Provider. Peter Roman Senior Counsel Computer Crime & Intellectual Property Section Criminal Division Department of Justice 1301 New York Ave., NW Washington, DC 20530 (202) 305-1323 peter.roman(a)usdoj.gov From: Caitlin Tubergen [mailto:caitlin.tubergen@icann.org] Sent: Monday, December 4, 2017 11:36 PM To: gdd-gnso-ppsai-impl(a)icann.org Cc: Roman, Peter (CRM) <Peter.Roman(a)CRM.USDOJ.GOV> Subject: Agenda + Updated Draft PPAA with IRT comments Greetings, Colleagues. Thank you for all of your input on the draft Privacy and Proxy Service Provider Accreditation Agreement (“PPAA”). Attached, you will find an updated PPAA, which incorporates the comments received. I am also working on updating the issues list and will be distributing the list some time tomorrow. For tomorrow’s call, we can begin by discussing some of the high-level issues some of the IRT members have raised. Specifically: The concern that the text of the PPAA does not match the WG’s recommendations The idea of having two PPAAs: one for affiliated providers and one for unaffiliated providers The IRT’s preferred path forward for dealing with the comments received Additionally, I’d like to note two things. First, further to Darcy’s message today, the GNSO Council recently voted to move the Transfer Policy (IRTP-C) issue for discussion within the PPSAI IRT. I believe the Council directed this issue to be discussed during the public comment period. Darcy, please feel free to add additional context either on the list or on tomorrow’s call. Lastly, there have been several mentions of GDPR as a potential issue/barrier to the PPSAI implementation. I would like to note that ICANN has engaged legal experts to analyze the impact the European Union General Data Protection Regulation (“GDPR”) will have on various data processing activities under ICANN policies and contracts. Such policies and contracts require or permit various entities that participate in the gTLD domain name system, including registries and registrars, to collect, create, retain, escrow, and publish a variety of personal data elements related to registry/registrar operations, domain name registrations, and registrants. The legal review and analysis is being conducted in iterative phases, and ICANN gathered questions from community discussions and submissions to submit to the legal experts for possible discussion in Part 2 of the analysis. One of the questions included the following: “ICANN org is working with the community to develop implementation details for consensus policy recommendations governing the accreditation of privacy and proxy providers. How should GDPR requirements be factored into developing the accreditation process?” We will certainly keep you apprised of any feedback we receive. See you on our call tomorrow. Kind regards, Caitlin

4 8

Agenda + Updated Draft PPAA with IRT comments
by Caitlin Tubergen Dec. 5, 2017

Dec. 5, 2017

Greetings, Colleagues. Thank you for all of your input on the draft Privacy and Proxy Service Provider Accreditation Agreement (“PPAA”). Attached, you will find an updated PPAA, which incorporates the comments received. I am also working on updating the issues list and will be distributing the list some time tomorrow. For tomorrow’s call, we can begin by discussing some of the high-level issues some of the IRT members have raised. Specifically: The concern that the text of the PPAA does not match the WG’s recommendations The idea of having two PPAAs: one for affiliated providers and one for unaffiliated providers The IRT’s preferred path forward for dealing with the comments received Additionally, I’d like to note two things. First, further to Darcy’s message today, the GNSO Council recently voted to move the Transfer Policy (IRTP-C) issue for discussion within the PPSAI IRT. I believe the Council directed this issue to be discussed during the public comment period. Darcy, please feel free to add additional context either on the list or on tomorrow’s call. Lastly, there have been several mentions of GDPR as a potential issue/barrier to the PPSAI implementation. I would like to note that ICANN has engaged legal experts to analyze the impact the European Union General Data Protection Regulation (“GDPR”) will have on various data processing activities under ICANN policies and contracts. Such policies and contracts require or permit various entities that participate in the gTLD domain name system, including registries and registrars, to collect, create, retain, escrow, and publish a variety of personal data elements related to registry/registrar operations, domain name registrations, and registrants. The legal review and analysis is being conducted in iterative phases, and ICANN gathered questions from community discussions and submissions to submit to the legal experts for possible discussion in Part 2 of the analysis. One of the questions included the following: “ICANN org is working with the community to develop implementation details for consensus policy recommendations governing the accreditation of privacy and proxy providers. How should GDPR requirements be factored into developing the accreditation process?” We will certainly keep you apprised of any feedback we receive. See you on our call tomorrow. Kind regards, Caitlin

1 0

Referral of IRT Part C Privacy/Proxy Registration Implementation Issues to PPSAI IRT
by Darcy Southwell Dec. 5, 2017

Dec. 5, 2017

All, The GNSO Council passed the below resolution during the 30 November 2017 meeting. As GNSO Council Liaison to the PPSAI IRT, I'm communicating this to the entire IRT. Please not that this work is expected to be undertaken only after the upcoming PPSAI IRT comment period. *Motion to Refer IRTP Part C Privacy / Proxy Registrations Implementation Issues to PPSAI IRT* Submitted by Darcy Southwell Seconded by Donna Austin 1. The Generic Names Supporting Organization (GNSO) Council sent a letter (see https://gnso.icann.org/en/correspondence/bladel-to- crocker-01dec16-en.pdf) to the ICANN Board on 1 December 2016 regarding implementation concerns with the Inter-Registrar Transfer Policy ("Transfer Policy") – Part C for privacy/proxy registrations. Specifically, the concerns relate to whether the addition/removal of a privacy/proxy service potentially triggers the 60-day inter-registrar transfer lock described in the updated Transfer Policy. The policy recommendations were silent with respect to the addition/removal of privacy/proxy services, and at the time the policy was implemented, the current issue and potential harms described by the GNSO Council were not brought to ICANN org's attention. 2. In this letter, the GNSO Council requested the Board to instruct ICANN Org to work with the Registrar Stakeholder Group and other interested parties to evaluate alternatives for the implementation concerns related to Transfer Policy Part C. 3. On 16 March 2017, the Board instructed the ICANN President and CEO, or his designee(s), to work with the Registrar Stakeholder Group and other interested parties to evaluate alternatives for the implementation concerns related to Transfer Policy Part C and to report back to the GNSO Council with the results of the discussion.” During this time, enforcement of the policy related to this specific issue has been deferred. 4. The Registrar Stakeholder Group discussed this issue and reached out to other interested parties to evaluate alternatives for the implementation concerns related to IRTP Part C and recommended that this issue is further evaluated by the Privacy & Proxy Services Accreditation Issues Implementation Review Team (PPSAI IRT) as this group is best placed to determine if/how implementation of IRTP Part C for privacy / proxy registrations can be carried out. Resolved, 1. The GNSO Council directs the PPSAI IRT to consider the issue of privacy/proxy registrations and IRTP Part C as outlined in the annex to the GNSO Council letter (see https://gnso.icann.org/en/correspondence/bladel-to- crocker-01dec16-en.pdf) and to put forward recommendations for implementation that are consistent with the IRTP Part C policy recommendations as well as the PPSAI policy recommendations. 2. The GNSO Council requests that this work be undertaken only after the upcoming PPSAI IRT comment period, and that if it appears as though it will cause any significant or unreasonable delay in implementation of privacy/proxy service accreditation implementation, that the GNSO Council Liaison must alert the Council. 3. The GNSO Council encourages registrars and other impacted parties to join the PPSAI IRT to collaborate in these discussions. 4. The GNSO Council requests the GNSO Council Liaison to the PPSAI IRT (in consultation with ICANN org and the IRT) provides regular updates on the timeline for incorporating the issue of privacy/proxy registrations and the Transfer Policy into the work of the PPSAI implementation plan. Where issues emerge during implementation that may require possible policy discussion, the Council requests GNSO Council Liaison to the PPSAI IRT to escalate these issues using the designated procedure outlined in the Final Recommendations Report on Policy & Implementation. 5. The GNSO Council requests the GNSO Council Liaison to the PPSAI IRT to communicate this decision to the PPSAI IRT as soon as possible. Vote Results[gnso.icann.org] <https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_meet…> Best, Darcy __________ *Darcy Southwell *| Compliance Officer M: +1 503-453-7305 │ Skype: darcy.enyeart

2 1

Re: [Gdd-gnso-ppsai-impl] Materials, action items from 17 Oct Privacy/Proxy IRT call
by Sara Bockey Dec. 1, 2017

Dec. 1, 2017

Caitlin, Thanks for the revised docs. A few items at first glance that need to be revised, as I believe they have been discussion/raised before. I will take a closer look and follow up with additional edits, but in the meantime… 1. Edit the definitions of Proxy Service and Privacy Service to match the definitions provided in the Final Report/2013 RAA * The definitions of Privacy Service and Proxy Service reflect those in the 2013 RAA. * In this context, the 2013 RAA also defines “Registered Name” as a domain name within the domain of a gTLD, about which a gTLD Registry Operator (or an Affiliate or subcontractor thereof engaged in providing Registry Services) maintains data in a Registry Database, arranges for such maintenance, or derives revenue from such maintenance, and “Registered Name Holder” is defined as the holder of a Registered Name. * It’s noted that ICANN staff has replace “Registered Name Holder” with “Customer” in many instances, but I question the logic in that since it is inconsistent with the RAA. 1. Edit Sections 3.5.3.3. thru 3.5.3.6 to take into consideration GDPR requirements regarding consent. * Consent must be explicitly given for each purpose and can be withdrawn at any time and not a requirement for registration or use of the service. Therefore, 3.5.3.3. – 3.5.3.6 (at a minimum) are not compatible and must be revise. 1. Edit section 3.12.2, as it still contains new language that has been added since the IRT agreement on language in August. The first sentence in its entirety should be removed. * The section should start with “Well founded…” Additionally, the following sections need revision or at a minimum further discuss by the IRT 1. Edit Section 3.14 to remove the language re no automation. This is not feasible. This language must be removed: * Provider shall not use high-volume, automated electronic processes (for example, processes that do not utilize human review) for sending Requests or responses to Requests to Requesters or Customers in performing any of the steps in the processes outlined in the Intellectual Property Disclosure Framework Specification. 1. Edit Section 3.15 – Labeling – to remove excessive language. * Provider shall ensure that each Registered Name for which Provider is providing the Services is clearly labeled as such in the Registration Data Directory Service, as specified in the Labeling Specification attached hereto, and shall otherwise comply with the requirements of the Labeling Specification attached hereto. This language is duplicative and not necessary. Let’s not add unnecessary words to this already long document. If there are doing to be extra works, perhaps mention complying with applicable local laws in light of GDPR. sara bockey sr. policy manager | GoDaddy™ sbockey(a)godaddy.com 480-366-3616 skype: sbockey This email message and any attachments hereto is intended for use only by the addressee(s) named herein and may contain confidential information. If you have received this email in error, please immediately notify the sender and permanently delete the original and any copy of this message and its attachments. From: <gdd-gnso-ppsai-impl-bounces(a)icann.org> on behalf of Caitlin Tubergen <caitlin.tubergen(a)icann.org> Reply-To: "gdd-gnso-ppsai-impl(a)icann.org" <gdd-gnso-ppsai-impl(a)icann.org> Date: Wednesday, October 25, 2017 at 4:44 AM To: "gdd-gnso-ppsai-impl(a)icann.org" <gdd-gnso-ppsai-impl(a)icann.org> Subject: [Gdd-gnso-ppsai-impl] Materials, action items from 17 Oct Privacy/Proxy IRT call Dear Colleagues, Thanks so much for your participation on today’s Privacy/Proxy IRT call. For those who could not attend, I encourage you to review the recording and materials on the wiki, https://community.icann.org/display/IRT/24+October+2017. During the call, we discussed an overview of the changes to the draft PPAA. Please note that ICANN proposed a deadline of Tuesday, 14 November for all comments, concerns, and edits to the draft PPAA. The changes from the last iteration, provided to the IRT in July, have been highlighted in the attached issues list. Please respond to the list if you would like to request a longer review period. During ICANN60, we will be presenting an overview of the P/P program’s status to the community. Attached, please find the slide deck for the presentation. To highlight a few notes from the IRT’s discussion this morning, we received feedback to: 1. Edit the definition of Working Group in Section 1.43, to specify that the Provider Stakeholder Group, if formed, shall only appoint the provider representatives of the Working Group, and the GNSO may appoint other members of the community. 1. Add back in the previously-deleted Code of Conduct language in Section 3.5.1. 1. Add back in the previously-deleted review provision in Section 7 of the Customer Data Accuracy Program Specification. If you believe the above items do not reflect the intent of the Working Group’s recommendations, please reply to the list by 14 November 2017. Thank you, and safe travels to those of you attending ICANN 60! Kind regards, Caitlin Tubergen Registrar Services and Engagement Senior Manager ICANN 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094 Office: +1 310 578 8666 Mobile: +1 310 699 5326 Email: caitlin.tubergen(a)icann.org

14 39

Further comments on PPAA WAS RE: Materials, action items from 17 Oct Privacy/Proxy IRT call
by Metalitz, Steven Dec. 1, 2017

Dec. 1, 2017

Here are a few additional suggestions on the PPAA. As before I am focusing primarily on flagging issues not already identified in the various submissions from registrar participants in the IRT; I am sure we will have a chance to go through those as part of the process. Again I might possibly have a few more before the end of the day. Spec 2 (Customer Data Accuracy): in paragraph 6, after “clientTransferProhibited,” insert “by Registrar.” I think this would also address the point Theo raises in his sticky note. Spec 3 (RDDS labeling): Some of section 1 may have been carried over a bit too glibly from the corresponding RAA provision. Many of the elements added in the staff’s redline (after Domain Name) are the “thin Whois” data elements related to the underlying registration, not to provision of the Services. Would an unaffiliated Provider necessarily know all this information (other than by getting it from the registrar or registry Whois)? Additionally, shouldn’t the next group of data elements refer to Customer Name, Customer Organization, etc. rather than Registrant Name, etc.? For a proxy service, all (and for a privacy service, almost all ) of this data pertaining to the Registrant is the Provider’s contact data. What we want here is the obligation of Provider to collect a full set of Customer data so that (among other things) this data can be conveniently loaded into Whois if the p/p Services are terminated (i.e., if Publication occurs), or can be communicated to a requester under appropriate circumstances. Spec 5 (LE Authority Disclosure): for most of this we need the input from PSWG, but pending that I’d suggest that the word “applicable” be inserted before “national” in 4.2.2.2. Spec 6 (IP Disclosure Framework): I’ll respond separately to the registrar comments on this but note that there are a few places where we reference rights holders that are not individuals with respect to where they are incorporated. Such entities might take a legal form other than a corporation (e.g., partnership) so in each place we should say “incorporated or organized.” This has already been done in 2.3.3. This issue occurs in 2.1.6.3, 2.2.7.4, 2.3.6.3, and there may be other places. Also, 3.3.1 might better read: “Provider has already caused Customer contact details to be Published in RDDS as the result of termination of the Services;”. The Provider is not actually the one who publishes Whois data, that is the Registrar (and Registry). I believe RDDS is the more future-proof term than Whois and this is reflected in the definition of Publication in 1.23. [image001] Steven J. Metalitz | Partner, through his professional corporation T: 202.355.7902 | met(a)msk.com<mailto:met@msk.com> Mitchell Silberberg & Knupp LLP | www.msk.com<http://www.msk.com/> 1818 N Street NW, 8th Floor, Washington, DC 20036 THE INFORMATION CONTAINED IN THIS E-MAIL MESSAGE IS INTENDED ONLY FOR THE PERSONAL AND CONFIDENTIAL USE OF THE DESIGNATED RECIPIENTS. THIS MESSAGE MAY BE AN ATTORNEY-CLIENT COMMUNICATION, AND AS SUCH IS PRIVILEGED AND CONFIDENTIAL. IF THE READER OF THIS MESSAGE IS NOT AN INTENDED RECIPIENT, YOU ARE HEREBY NOTIFIED THAT ANY REVIEW, USE, DISSEMINATION, FORWARDING OR COPYING OF THIS MESSAGE IS STRICTLY PROHIBITED. PLEASE NOTIFY US IMMEDIATELY BY REPLY E-MAIL OR TELEPHONE, AND DELETE THE ORIGINAL MESSAGE AND ALL ATTACHMENTS FROM YOUR SYSTEM. THANK YOU. From: Metalitz, Steven Sent: Thursday, November 30, 2017 5:16 PM To: 'Sara Bockey'; 'Darcy Southwell'; 'gdd-gnso-ppsai-impl(a)icann.org' Subject: RE: [Gdd-gnso-ppsai-impl] Materials, action items from 17 Oct Privacy/Proxy IRT call PPSAI colleagues, I offer the following comments and suggested edits regarding the Oct. 20 redline version of the PPAA. I may have a few other suggestions by tomorrow’s deadline, and will definitely have responses later to some of the other proposed edits that have been sent to the list. (And thanks to Theo and colleagues for their comprehensive review of the document!) First, I would reiterate the suggestions made in my Oct. 21 posting to the list, as follows: Subsection 3.5.3.15: strike “should” and insert “shall,” for consistency with parallel provisions throughout this section 3.5. Section 3.7, third line from the bottom: “employee” should be “employ.” Section 3.17.1: I suggest adding the words “as applicable” or “to the extent applicable” at the end of the section. Not every Disclosure or Publication request that Provider receives will fall under the IP or LEA disclosure frameworks. Section 5.7.3: the notice that the suspended Provider must send to customers should specify “that it is unable to offer or provide the Services for any new registrations” (adding the last 4 words). A suspended Provider can (and indeed must) provide the Services to its current customers. [Note that the phrasing “any additional registrations” might be more accurate here, and in the corresponding provision of 5.7.1 --- otherwise it might be possible for a suspended provider to being providing services for the first time to an existing registration whose registrant decides to engage a service.] Here are some additional suggestions: Section 1.43: strike “comprising the Working Group,” insert “representatives of the Service Providers.” This issue is noted on page 2 of the Discussion Items document. Section 3.5.3.3: since this has to do with p/p services and not with registration per se, the references to “initial registration and each renewal registration” should be changed to something like “each initial agreement to provide Services and each renewal or extension of such agreement.” I believe this is also responsive to Theo’s sticky note on the RrSG redline for this section. Section 3.8.1 (specifying what needs to be stated on request forms) should include a cross-reference to section 3.8.2 (requiring publication of links to request forms in some circumstances). Alternatively, perhaps the order of these two sections should be reversed. Section 3.8.5.5 needs some rephrasing. Reveal is not a defined term in the PPAA, and the provider does not itself Publish data in the RDS (the registrar or registry does that), but can cause it to be Published. This may a rare instance in which use of the passive voice may be preferable (“the circumstances under which the Customer’s identity or contact data will be published in the RDDS….”). Section 3.19: substitute “shall” for “should.” In fact the entire document should be reviewed to see where this change is needed. Section 5.3: this is another issue I raised in my Oct. 21 posting: “Section 5.3 does not give ICANN the right to substitute the new version of the agreement, it gives that right to the provider. Furthermore, 5.3 addresses the scenario in which the new agreement is swapped in during the term of the current agreement. The point I was trying to raise on the call (and I am sorry if this was not clear) is ensuring that all renewals of the agreement at the end of the term reflect the most recent version. As currently drafted, section 5.2 seems to give the provider the option of renewing under the terms of the old agreement (“under the terms and conditions of this agreement”), even if it has been superseded by a new form of agreement that is materially different. This could be fixed by adding a subsection 5.2.5 along the following lines: ‘5.2.5: this Agreement has been superseded by a revised form accreditation agreement for the provision of the Services (“Updated PPAA”) that is materially different from this Agreement, in which case the right of renewal provided by this section shall be under the terms and conditions of the Updated PPAA.’” Section 5.7.4: consider inserting at the end of the first sentence “or its invocation of section 5.5.7,” which is another path ICANN could take to deal with the situation of an uncured “endangerment” scenario. Section 7.4.1: shouldn’t the Working Group be the party to receive the notice re revision of the Agreement? This would be consistent with the rest of section 7.4. Glad to try to answer any questions about these. Steve Metalitz [image001] Steven J. Metalitz | Partner, through his professional corporation T: 202.355.7902 | met(a)msk.com<mailto:met@msk.com> Mitchell Silberberg & Knupp LLP | www.msk.com<http://www.msk.com/> 1818 N Street NW, 8th Floor, Washington, DC 20036 THE INFORMATION CONTAINED IN THIS E-MAIL MESSAGE IS INTENDED ONLY FOR THE PERSONAL AND CONFIDENTIAL USE OF THE DESIGNATED RECIPIENTS. THIS MESSAGE MAY BE AN ATTORNEY-CLIENT COMMUNICATION, AND AS SUCH IS PRIVILEGED AND CONFIDENTIAL. IF THE READER OF THIS MESSAGE IS NOT AN INTENDED RECIPIENT, YOU ARE HEREBY NOTIFIED THAT ANY REVIEW, USE, DISSEMINATION, FORWARDING OR COPYING OF THIS MESSAGE IS STRICTLY PROHIBITED. PLEASE NOTIFY US IMMEDIATELY BY REPLY E-MAIL OR TELEPHONE, AND DELETE THE ORIGINAL MESSAGE AND ALL ATTACHMENTS FROM YOUR SYSTEM. THANK YOU. From: Metalitz, Steven Sent: Tuesday, November 07, 2017 11:42 AM To: 'Sara Bockey'; Darcy Southwell; gdd-gnso-ppsai-impl(a)icann.org<mailto:gdd-gnso-ppsai-impl@icann.org> Subject: RE: [Gdd-gnso-ppsai-impl] Materials, action items from 17 Oct Privacy/Proxy IRT call I agree with a lot of what Darcy says. Let me make sure my view is clearly stated. Most of the items Darcy identifies are completely appropriate for discussion in our team before the documents are finalized. These issues include: perceived discrepancies between the WG Final Report and the implementation documents; loose ends in the Law Enforcement disclosure framework; and clarifying the status of each of the four documents under review. I support addressing these points on our next call so that we can continue to make progress. And based on the postings made to our list over the last couple of weeks, I would certainly be comfortable with some relaxation of the deadline for proposing edits to the accreditation agreement – if necessary, to December 1. My concerns are focused primarily on the suggestion that we can’t move forward until we determine whether our recommendations are GDPR-compliant. To me that sounds like some on the IRT want to suspend work until ICANN’s separate work on GDPR is concluded. If that is not what is meant, then I would ask proponents of that view to clarify just how they think we should proceed at this point. I am also sad to see the IRTP-C issue brought up again. I thought we had reached agreement that the current suspension of ICANN enforcement of this aspect of that policy could be continued until an appropriate group is formed to address it; or put another way, that we could proceed to get our PPSAI implementation plan out for public comment without delaying it until the IRTP-C issue is resolved. That is my recollection, anyway, but if I am mistaken then please show me how. Finally I will repeat my question of whether our call time on 11/14 remains at 1400 UTC or whether it will be moved an hour later to preserve the usual start time in most Northern Hemisphere time zones. Steve [image001] Steven J. Metalitz | Partner, through his professional corporation T: 202.355.7902 | met(a)msk.com<mailto:met@msk.com> Mitchell Silberberg & Knupp LLP | www.msk.com<http://www.msk.com/> 1818 N Street NW, 8th Floor, Washington, DC 20036 THE INFORMATION CONTAINED IN THIS E-MAIL MESSAGE IS INTENDED ONLY FOR THE PERSONAL AND CONFIDENTIAL USE OF THE DESIGNATED RECIPIENTS. THIS MESSAGE MAY BE AN ATTORNEY-CLIENT COMMUNICATION, AND AS SUCH IS PRIVILEGED AND CONFIDENTIAL. IF THE READER OF THIS MESSAGE IS NOT AN INTENDED RECIPIENT, YOU ARE HEREBY NOTIFIED THAT ANY REVIEW, USE, DISSEMINATION, FORWARDING OR COPYING OF THIS MESSAGE IS STRICTLY PROHIBITED. PLEASE NOTIFY US IMMEDIATELY BY REPLY E-MAIL OR TELEPHONE, AND DELETE THE ORIGINAL MESSAGE AND ALL ATTACHMENTS FROM YOUR SYSTEM. THANK YOU. From: Sara Bockey [mailto:sbockey@godaddy.com] Sent: Tuesday, November 07, 2017 11:07 AM To: Darcy Southwell; gdd-gnso-ppsai-impl(a)icann.org<mailto:gdd-gnso-ppsai-impl@icann.org>; Metalitz, Steven Cc: Sara Bockey Subject: Re: [Gdd-gnso-ppsai-impl] Materials, action items from 17 Oct Privacy/Proxy IRT call Well said, Darcy. Agree 100%. sara bockey sr. policy manager | GoDaddy™ sbockey(a)godaddy.com<mailto:sbockey@godaddy.com> 480-366-3616 skype: sbockey This email message and any attachments hereto is intended for use only by the addressee(s) named herein and may contain confidential information. If you have received this email in error, please immediately notify the sender and permanently delete the original and any copy of this message and its attachments. From: Darcy Southwell <darcy.southwell(a)endurance.com<mailto:darcy.southwell@endurance.com>> Date: Tuesday, November 7, 2017 at 8:47 AM To: "gdd-gnso-ppsai-impl(a)icann.org<mailto:gdd-gnso-ppsai-impl@icann.org>" <gdd-gnso-ppsai-impl(a)icann.org<mailto:gdd-gnso-ppsai-impl@icann.org>>, "Metalitz, Steven" <met(a)msk.com<mailto:met@msk.com>>, Sara Bockey <sbockey(a)godaddy.com<mailto:sbockey@godaddy.com>> Subject: Re: [Gdd-gnso-ppsai-impl] Materials, action items from 17 Oct Privacy/Proxy IRT call I agree with Theo. The scope has changed and implementation is impacted by GDPR. While I appreciate that Steve wants to move forward expeditiously, I don’t believe we can do so without jeopardizing the creation of an effective program. Further, in just the last week or so, issues have been raised about implementation language contradicting the policy. The role of an IRT is to implement the consensus policy produced in the PDP and we need to spend sufficient time reviewing and discussing the implementation to ensure we’re not changing policy. Similarly, I think there were questions raised about the proposed framework Public Safety Working Group. In addition to policy creep, I believe concerns were expressed that staff failed to modify the proposed framework based on the feedback from IRT participants. Rather than picking through the documents line by line, it seems like we should step back and have a discussion about the concepts to ensure we’re making progress toward an effective implementation that reflects the policy. There have also been repeated questions raised about the over-engineering of this implementation. Because many of the meetings have focused on reviewing language from a specific section (rather than reviewing issues as whole items), it seems like we haven’t gotten past this issue, and should probably take a fresh look at that to ensure we’re not making this implementation more complicated than it needs to be. We all know that doesn’t lead us to a better implementation. Right now, we have four draft documents for review/input: (1) accreditation agreement, (2) de-accreditation process, (3) applicant guide, and (4) data escrow specification. For many members, these require operational and legal review (at a minimum). Many registrars have commented that 1 December is the earliest they can provide full feedback given the complexity of these documents (although not all have committed to that date). Given these issues, as well as the fact that the privacy/proxy challenge stemming from IRTP-C needs to be added to this IRT for a solution, we need to take a step back and address these critical issues first. This isn’t about derailing the IRT; it’s about ensuring we don’t create an implementation that’s an operational nightmare for providers as well as registrants and end users – and that means addressing these critical issues first. Thanks, Darcy From: <gdd-gnso-ppsai-impl-bounces(a)icann.org<mailto:gdd-gnso-ppsai-impl-bounces@icann.org>> on behalf of theo geurts <gtheo(a)xs4all.nl<mailto:gtheo@xs4all.nl>> Reply-To: <gdd-gnso-ppsai-impl(a)icann.org<mailto:gdd-gnso-ppsai-impl@icann.org>> Date: Monday, November 6, 2017 at 12:27 PM To: <gdd-gnso-ppsai-impl(a)icann.org<mailto:gdd-gnso-ppsai-impl@icann.org>>, "Metalitz, Steven" <met(a)msk.com<mailto:met@msk.com>>, Sara Bockey <sbockey(a)godaddy.com<mailto:sbockey@godaddy.com>> Subject: Re: [Gdd-gnso-ppsai-impl] Materials, action items from 17 Oct Privacy/Proxy IRT call Hi Steve, Vicky, Now your argument is logical and makes sense. Yes, as I mentioned before, CPH's will implement privacy services on many different levels to comply with the GDPR, we agree here. My biggest problem with the PPSAI IRT is the changing dynamics. The WG contemplated and discussed and made recommendations based on a very fixed situation. In my opinion, privacy services should not be used as bandaid for data protection problems. Complying with data protection laws was not the driving force during the WG days, and now it is. I think the scope of the IRT has changed and we should deal with this before we move on. We need to think a little smarter and deeper here before we unleash this to many contracted parties who have zero experience with these services and will be required to implement this to comply with data protection laws. So how do we do that? I think a fixed set of procedures and contractual agreements are essential, yet I do not want us to enter into a situation that causes more issues and forces providers into a situation that we need to ask compliance to defer. https://www.icann.org/resources/pages/contractual-compliance-statement-2017…<https://www.icann.org/resources/pages/contractual-compliance-statement-2017…> I think that scenario is unwanted for everyone on the IRT is it not? Thanks, Theo Geurts On 6-11-2017 19:40, Metalitz, Steven wrote: I strongly second Vicky’s comments. The ongoing ICANN work re GDPR is of course very important, but let’s not let it derail progress on the path we have moved so far along toward a P/P service accreditation framework to present to the community. In that regard, I have some sympathy (empathy?) for those requesting a relaxation of the comment deadline in light of so much other activity demanding our attention. May I suggest that we try to get as many proposed edits onto the list before our November 14 call (with much thanks to those who have already done so), with the goal of dealing with them then if possible, but leaving the door open for further edits over the next couple of weeks if necessary. Finally, some ICANN groups are adjusting the scheduling of their calls to reflect the return to standard time in North America and Europe. Is this group doing so as well? If our calls stay at 1400 UTC that is now 9 am EST and 6 am for those on Pacific time. Moving to 1500 UTC would retain the pre-existing local start times, I believe. Steve Metalitz [age001] Steven J. Metalitz | Partner, through his professional corporation T: 202.355.7902 | met(a)msk.com<mailto:met@msk.com> Mitchell Silberberg & Knupp LLP | www.msk.com<http://www.msk.com/> 1818 N Street NW, 8th Floor, Washington, DC 20036 THE INFORMATION CONTAINED IN THIS E-MAIL MESSAGE IS INTENDED ONLY FOR THE PERSONAL AND CONFIDENTIAL USE OF THE DESIGNATED RECIPIENTS. THIS MESSAGE MAY BE AN ATTORNEY-CLIENT COMMUNICATION, AND AS SUCH IS PRIVILEGED AND CONFIDENTIAL. IF THE READER OF THIS MESSAGE IS NOT AN INTENDED RECIPIENT, YOU ARE HEREBY NOTIFIED THAT ANY REVIEW, USE, DISSEMINATION, FORWARDING OR COPYING OF THIS MESSAGE IS STRICTLY PROHIBITED. PLEASE NOTIFY US IMMEDIATELY BY REPLY E-MAIL OR TELEPHONE, AND DELETE THE ORIGINAL MESSAGE AND ALL ATTACHMENTS FROM YOUR SYSTEM. THANK YOU. From: gdd-gnso-ppsai-impl-bounces(a)icann.org<mailto:gdd-gnso-ppsai-impl-bounces@icann.org> [mailto:gdd-gnso-ppsai-impl-bounces@icann.org] On Behalf Of Victoria Sheckler Sent: Tuesday, October 31, 2017 5:55 PM To: gdd-gnso-ppsai-impl(a)icann.org<mailto:gdd-gnso-ppsai-impl@icann.org>; Sara Bockey Subject: Re: [Gdd-gnso-ppsai-impl] Materials, action items from 17 Oct Privacy/Proxy IRT call Please note that ICANN’s work on GDPR’s on a separate track and that one thing we know almost for sure is that the adoption of rational, predictable rules for privacy/proxy will be more important post-GDPR than it ever was. So please let’s get those rules in place as expeditiously as possible. On 30-10-2017 11:32, Sara Bockey wrote: Caitlin, Thanks for the revised docs. A few items at first glance that need to be revised, as I believe they have been discussion/raised before. I will take a closer look and follow up with additional edits, but in the meantime… 1. Edit the definitions of Proxy Service and Privacy Service to match the definitions provided in the Final Report/2013 RAA * The definitions of Privacy Service and Proxy Service reflect those in the 2013 RAA. * In this context, the 2013 RAA also defines “Registered Name” as a domain name within the domain of a gTLD, about which a gTLD Registry Operator (or an Affiliate or subcontractor thereof engaged in providing Registry Services) maintains data in a Registry Database, arranges for such maintenance, or derives revenue from such maintenance, and “Registered Name Holder” is defined as the holder of a Registered Name. * It’s noted that ICANN staff has replace “Registered Name Holder” with “Customer” in many instances, but I question the logic in that since it is inconsistent with the RAA. 1. Edit Sections 3.5.3.3. thru 3.5.3.6 to take into consideration GDPR requirements regarding consent. * Consent must be explicitly given for each purpose and can be withdrawn at any time and not a requirement for registration or use of the service. Therefore, 3.5.3.3. – 3.5.3.6 (at a minimum) are not compatible and must be revise. 1. Edit section 3.12.2, as it still contains new language that has been added since the IRT agreement on language in August. The first sentence in its entirety should be removed. * The section should start with “Well founded…” Additionally, the following sections need revision or at a minimum further discuss by the IRT 1. Edit Section 3.14 to remove the language re no automation. This is not feasible. This language must be removed: * Provider shall not use high-volume, automated electronic processes (for example, processes that do not utilize human review) for sending Requests or responses to Requests to Requesters or Customers in performing any of the steps in the processes outlined in the Intellectual Property Disclosure Framework Specification. 1. Edit Section 3.15 – Labeling – to remove excessive language. * Provider shall ensure that each Registered Name for which Provider is providing the Services is clearly labeled as such in the Registration Data Directory Service, as specified in the Labeling Specification attached hereto, and shall otherwise comply with the requirements of the Labeling Specification attached hereto. This language is duplicative and not necessary. Let’s not add unnecessary words to this already long document. If there are doing to be extra works, perhaps mention complying with applicable local laws in light of GDPR. sara bockey sr. policy manager | GoDaddy™ sbockey(a)godaddy.com<mailto:sbockey@godaddy.com> 480-366-3616 skype: sbockey This email message and any attachments hereto is intended for use only by the addressee(s) named herein and may contain confidential information. If you have received this email in error, please immediately notify the sender and permanently delete the original and any copy of this message and its attachments. From: <gdd-gnso-ppsai-impl-bounces(a)icann.org><mailto:gdd-gnso-ppsai-impl-bounces@icann.org> on behalf of Caitlin Tubergen <caitlin.tubergen(a)icann.org><mailto:caitlin.tubergen@icann.org> Reply-To: "gdd-gnso-ppsai-impl(a)icann.org"<mailto:gdd-gnso-ppsai-impl@icann.org> <gdd-gnso-ppsai-impl(a)icann.org><mailto:gdd-gnso-ppsai-impl@icann.org> Date: Wednesday, October 25, 2017 at 4:44 AM To: "gdd-gnso-ppsai-impl(a)icann.org"<mailto:gdd-gnso-ppsai-impl@icann.org> <gdd-gnso-ppsai-impl(a)icann.org><mailto:gdd-gnso-ppsai-impl@icann.org> Subject: [Gdd-gnso-ppsai-impl] Materials, action items from 17 Oct Privacy/Proxy IRT call Dear Colleagues, Thanks so much for your participation on today’s Privacy/Proxy IRT call. For those who could not attend, I encourage you to review the recording and materials on the wiki, https://community.icann.org/display/IRT/24+October+2017<https://community.icann.org/display/IRT/24+October+2017>. During the call, we discussed an overview of the changes to the draft PPAA. Please note that ICANN proposed a deadline of Tuesday, 14 November for all comments, concerns, and edits to the draft PPAA. The changes from the last iteration, provided to the IRT in July, have been highlighted in the attached issues list. Please respond to the list if you would like to request a longer review period. During ICANN60, we will be presenting an overview of the P/P program’s status to the community. Attached, please find the slide deck for the presentation. To highlight a few notes from the IRT’s discussion this morning, we received feedback to: 1. Edit the definition of Working Group in Section 1.43, to specify that the Provider Stakeholder Group, if formed, shall only appoint the provider representatives of the Working Group, and the GNSO may appoint other members of the community. 1. Add back in the previously-deleted Code of Conduct language in Section 3.5.1. 1. Add back in the previously-deleted review provision in Section 7 of the Customer Data Accuracy Program Specification. If you believe the above items do not reflect the intent of the Working Group’s recommendations, please reply to the list by 14 November 2017. Thank you, and safe travels to those of you attending ICANN 60! Kind regards, Caitlin Tubergen Registrar Services and Engagement Senior Manager ICANN 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094 Office: +1 310 578 8666 Mobile: +1 310 699 5326 Email: caitlin.tubergen(a)icann.org<mailto:caitlin.tubergen@icann.org> _______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl(a)icann.org<mailto:Gdd-gnso-ppsai-impl@icann.org> https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl<https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl> _______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl(a)icann.org<mailto:Gdd-gnso-ppsai-impl@icann.org> https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl<https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl> _______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl(a)icann.org<mailto:Gdd-gnso-ppsai-impl@icann.org> https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl<https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl> _______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl(a)icann.org<mailto:Gdd-gnso-ppsai-impl@icann.org> https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl<https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl>

1 0

RrSG comments on the current drafts.
by Theo Geurts Dec. 1, 2017

Dec. 1, 2017

Dear IRT members. Attached the comments from several RrSG members. Thank you for the comments and support and the valuable discussions: Key-Systems, Volker Greimann Netearth One, Chris Pelling Nordreg, Benny Samuelsen One.com, Rieke Poppe 1und1, Thomas Keller Astutium, Rob Golding Godaddy, Sara Bockey, thank you for assisting me with the reviews. DNS Africa, Vlad Dinculescu Best regards, Theo Geurts

2 1