- Gdd-gnso-ppsai-impl - lists.icann.org

Final IRT Feedback Due EOD Sunday 28 Jan: draft LEA framework
by Amy Bivins Jan. 24, 2018

Jan. 24, 2018

Dear Colleagues, Thanks so much for your active participation on today's Privacy/Proxy Accreditation Program IRT call. If you were unable to attend, I encourage you to listen to the recording. Today, we continued discussing the LEA disclosure framework specification in the draft PPAA (pp. 50-54 of the draft contract, attached). The discussion today confirmed that there is continued uncertainty regarding two items in the draft framework. Please submit any final feedback that you have on these topics to the list this week. After this final feedback period, if this issue/these issues are unresolved, they will be specifically identified as unresolved in the call for public comments. Section 3.1: As drafted, this section requires Providers to publish on their websites the designated LEA contact (e.g. email address, telephone number, form or other means for LEA to obtain the designated LEA contact information). Summary of Issue: Many members of the IRT support the deletion of the requirement that this contact (or a means to obtain this contact) appear on the Provider's website. The RAA does not require registrars to publish the registrar LEA contact on the registrar website (See RAA 3.18.2). There appear to be at least a few possible paths forward: 1. Keep language as-is. 2. Delete the second sentence of 3.1, which requires that this information be posted on the Provider website. 3. Replace the second sentence of 3.1 with language such as that suggested by Steve Metalitz, "Provider shall provide to LEA an appropriate means for LEA to obtain the designated LEA contact information." 4. Language from Section 3.18.2 of the RAA could be adapted for this agreement by changing "Registrar" to "Provider" or by making additional edits: 3.18.2 Registrar shall establish and maintain a dedicated abuse point of contact, including a dedicated email address and telephone number that is monitored 24 hours a day, seven days a week, to receive reports of Illegal Activity by law enforcement, consumer protection, quasi-governmental or other similar authorities designated from time to time by the national or territorial government of the jurisdiction in which the Registrar is established or maintains a physical office. 5. We could keep the language as-is for now, note any remaining disagreement about whether the contact (or a way to obtain it) should be posted on the Provider's website during the public comment period, and request community feedback on potential paths forward. 6. Some other path (please explain). Timeline for Providers to Action "High Priority" Requests From LEA Summary of Issue: The current PPAA draft contains a two-step process for Providers upon receipt of a request from LEA. (1) Within two business days, the Provider must review the request and confirm to the LEA requester that it has been received and contains the relevant information required to meet the minimum standard for acceptance (See 3.2.1). (2) The Provider must then action the request in accordance with the priority level (within 24 hours for "high priority" requests (4.1.2); or within the timeline requested by LEA, if possible, for other requests (See 4.1.3). Note 1: The RAA requires (See Section 3.18.2) that "Well-founded reports of Illegal Activity submitted to these [dedicated LEA] contacts must be reviewed within 24 hours by an individual who is empowered by Registrar to take necessary and appropriate actions in response to the report." Note 2: There is some uncertainty, as this is currently drafted, as to whether the 2 business day review period applies before the 24 hour response time for "high priority" requests. Section 4.1.1 states that "Upon completion of the Receipt Process Specified in Section 3 of this Specification, Provider will action, in accordance with Sections 4.2 and 4.3 of this Specification, the disclosure request in accordance with the Priority Level." Upon the resolution of the issue below, we will review the specification as a whole to ensure it reflects the intended result. IRT questions: 1. Should Providers be required to action all "high priority" requests within 24 hours of receipt, as recommended by PSWG (and not apply the 2 business day "receipt period" first)? 2. If no, do you see a compromise short of applying the current 2 business day receipt period prior to the 24-hour period for actioning a "high priority" request? Thanks so much for your continued input on these topics. Next week, we will pick up our discussion with the IP Disclosure Framework Specification. Best, Amy Amy E. Bivins Registrar Services and Engagement Senior Manager Registrar Services and Industry Relations Internet Corporation for Assigned Names and Numbers (ICANN) Direct: +1 (202) 249-7551 Fax: +1 (202) 789-0104 Email: amy.bivins(a)icann.org<mailto:amy.bivins@icann.org> www.icann.org<http://www.icann.org>

2 3

Agenda for tomorrow's PP IRT meeting
by Amy Bivins Jan. 22, 2018

Jan. 22, 2018

Hello, All, Thanks so much for your input on the list last week. Tomorrow, we will pick up where we left off last week, continuing to discuss the LEA disclosure framework specification. We will continue to discuss remaining IRT comments that we have received on the remainder of the specifications. I'm also attaching for your information the most recent data escrow specification, which is not included in the current PPAA draft, but will be included in the next version. This document was last discussed by the IRT in October, and we have received no recommendations for edits to it since then. Unless any additional IRT feedback on this reveals a need for changes, this will be included as-is in the next PPAA draft. Best, Amy Amy E. Bivins Registrar Services and Engagement Senior Manager Registrar Services and Industry Relations Internet Corporation for Assigned Names and Numbers (ICANN) Direct: +1 (202) 249-7551 Fax: +1 (202) 789-0104 Email: amy.bivins(a)icann.org<mailto:amy.bivins@icann.org> www.icann.org<http://www.icann.org>

3 2

Summary of today's privacy/proxy IRT call, IRT action items
by Amy Bivins Jan. 18, 2018

Jan. 18, 2018

Dear Colleagues, Thanks so much for your active participation on today's privacy/proxy IRT call. If you were unable to attend, I encourage you to listen to the recording, which is available on the wiki, https://participate.icann.org/p8nkvqvkvyr/ Today we began reviewing the most recent round of IRT member comments on the PPAA specifications. Some high-level notes regarding our discussions are below. Please send any additional input you have on the topics discussed today to the list no later than the end of this week. Next week, we will pick up where we left off today on the LEA disclosure framework specification. Specification 1: Customer Data Accuracy Specification Issue 1: Re: IRT member comment-this specification needs to be revisited, confusing as to how this is impacted by Affiliate/TPP status Proposed Solution: Move Section 3 to the beginning of this specification. Issue 2: Should Section 1 be edited to add an additional trigger-when the privacy and/or proxy service is enabled? Rationale: PP Service could be turned on in response to a WHOIS accuracy complaint, resulting in the shielding of potentially inaccurate information instead of validation/verification. IRT Feedback on this proposal was mixed. Additional feedback is requested. Issue 3: In Section 5, IRT member recommended that all references to registrars to terminate or suspend should be removed. Rationale: Registrars are not bound by this contract. IRT Feedback: At a minimum, registrars should be notified if PP service is suspended or terminated due to inaccurate customer contact information. This will trigger registrar obligations under the RAA to validate/verify. Issue 4: In Section 6, does addition of "by Registrar" solve issue (to clarify that PP provider cannot place names on clientHold or TransferProhibited status)? IRT Feedback seemed to support this change. Specification 2: Registration Data Directory Service Labeling Specification Issue 1: Is this specification attempting to require retention of this data, or to simply identify what information should appear in WHOIS for PP registrations? Assuming the latter, this specification should be updated (perhaps in introductory language in Section 1, and potentially moving up section 3) to clearly note this purpose. In addition, labeling requirements for "registrant organization" field should be added as an example in Section 1. Sections 3.2.1 and 3.5.3 should also be reviewed to ensure consistency across contract text, data retention specification and this specification. Specification 3: Consensus Policies and Temporary Policies Specification Issue 1: Feedback from Theo Geurts (Re: Section 1.2.1)-how does a privacy service endanger the security or stability of the internet? Comments on today's call: IRT member comment-this should only be included if there is a specific purpose for this; Other IRT members-there are instances where someone acting in a manner that could endanger security/stability may be hiding behind a PP service Proposed Next Steps: If no further IRT feedback to the contrary, reasons to keep this section appear to have been identified. Issue 2: IRT member Feedback Re: Section 1.3-I think we can delete all sections in 1.3 as they deal with domain name registrations in general rather than providing a privacy service. We could say privacy providers should not practice warehousing, but that is not what it currently says. Comments from today's call: At least some of these sections appear to be relevant to PP services (see, e.g. Sections 1.3.6) Proposed Next Steps: If IRT members would like to identify any sections that they believe should be deleted, please send specific suggestions to the list this week. Specification 4: Law Enforcement Authority Disclosure Framework Specification Issue 1: Proposal to change references to "national or international law" to "applicable law" Comments from today's call: No issues raised on call Proposed next steps: Update language throughout specification if no contrary input from IRT. Issue 2: Timeline for processing/responding to "high priority" requests Current status: PPAA draft provides for two business days for providers to process LEA requests and ensure they meet minimum standards for acceptance (Section 3.2.1). If a request meets criteria for "high priority" request, provider must action the request within 24 hours (Section 4.1.2) Comments from today's call: Timeline for provider responses to high priority LEA requests was revisited. PSWG representative stated that this is too long. Some Rr representatives on call reiterated prior feedback that receipt process may require legal/outside review, and that 2 business days is appropriate timeframe. Proposed next steps: This discussion mirrors points raised in prior discussions regarding this framework (summary of most recent discussions in August, including results of IRT poll regarding potential changes from "2 business day" review period, attached). This topic will be continued next week. If there is continued disagreement among IRT stakeholders after Tuesday's call, this item will be specifically flagged for community input in the call for public comments. Best, Amy Amy E. Bivins Registrar Services and Engagement Senior Manager Registrar Services and Industry Relations Internet Corporation for Assigned Names and Numbers (ICANN) Direct: +1 (202) 249-7551 Fax: +1 (202) 789-0104 Email: amy.bivins(a)icann.org<mailto:amy.bivins@icann.org> www.icann.org<http://www.icann.org>

6 5

Regrets for today's call
by Darcy Southwell Jan. 16, 2018

Jan. 16, 2018

My apologies, but I will not be able to make the 16 January call. __________ *Darcy Southwell *| Compliance Officer M: +1 503-453-7305 │ Skype: darcy.enyeart

2 1

Materials, action items from today's IRT call
by Amy Bivins Jan. 12, 2018

Jan. 12, 2018

Dear Colleagues, Thanks so much for those of you who participated on today's IRT call. For those of you who could not attend, I encourage you to listen to the recording, which will be available on the wiki shortly, https://community.icann.org/display/IRT/09+January+2018. Today, we picked up our discussion of the IRT's feedback on the PPAA draft in Section 3.12, and we proceeded through the end of the text of the contract (prior to the specifications). A brief high-level summary of the input received today is below. IRT Action Items 1. If you have further input on these or any other points discussed on the call, please send them to the list this week. 2. If you have any further input on the PPAA draft, you must send this to the list this week. 3. If you have further comments related to the distinction between requirements for affiliated and non-affiliated providers in the attached chart (first distributed in December), specifically related to the suggestion from some IRT members that ICANN should revisit the possibility of having a separate agreement for affiliates, you must send this to the list this week. If ICANN does not receive further input on this, we will continue to proceed with this single agreement. ICANN Org Action Items 1. ICANN Org will begin reviewing and incorporating IRT feedback on PPAA into next PPAA draft. 2. ICANN Org will alert IRT to discussion topics for next week no later than EOD Friday. 3. ICANN Org is finalizing next draft of other implementation materials (applicant guide, Policy document) for IRT review prior to opening public comment period. ICANN Org also must provide updated PPAA specifications to IRT for discussion so that these can be finalized prior to opening public comment period. 4. Our aim is to finalize discussions on all materials identified above prior to ICANN61. Summary of IRT Input Received on 9 January Call Section 3.12: IRT members supported deleting the new text in 3.12.2 that was added to reference the LEA framework (this will be saved for the framework itself). Section 3.14: IRT members supported deleting the new text that was added to reference text from the final report. In its place, text from the final report should be added to the IP framework specification. Section 3.16 (Relay): IRT members recommended editing Section 3.16.2 to change "concerning" to "for Relay to" to narrow this provision to encompass only Relay requests. IRT members said ICANN should revisit 3.16.6, which appears to be too broad. It appears this section should apply only to section 3.16.5, and should be renumbered 3.16.5.1. Section 3.17 (Reveal): In prior feedback, some IRT members said this was inconsistent with Final Report. IRT members are invited to identify how this is substantively different than the Final Report on-list if you would like to discuss this further. IRT members also said that ICANN should revisit 3.17 to ensure that Final Report requirements (p. 70) are included regarding customer notifications and notifications regarding a provider's decision to comply with a request (or not). Section 3.19 (Record Keeping): IRT members pointed ICANN to prior feedback re: suggested language on reporting mechanism. ICANN will revisit this recommendation and also check for an update re: the reporting interface. Section 5.3 (Right to Substitute Amended Agreement): Copy edits previously suggested by Steve Metalitz-ICANN will revisit. This may have been drafted to mirror RAA, and consistency will be the goal if there is an analogous RAA provision. Section 5.5 (Termination). IRT feedback is specifically requested on Section 5.5.9-right of ICANN to terminate a PPAA where an Affiliate's PPAA or RAA is terminated. Initial IRT feedback indicated this may be too broad. Perhaps termination of affiliate agreement should be a reason to check compliance status rather than resulting in termination automatically. Section 7.4 (Negotiation Process). This could be edited to remove reference to "Stakeholder Group" and this could be addressed if a Stakeholder Group/Constituency/ETC is ever created. Section 7.4.4.3-if this is a community-appointed WG (if "stakeholder group" deleted), this reference to bearing costs of mediation should be deleted. Section 7.4.5.2. IRT members are encouraged to review this section specifically, in re: feedback on-list. Section 7.5 (Synchronization Amendment). IRT members encouraged ICANN to review text that was previously suggested (see issues list) to simplify 7.5.1 Best, Amy Amy E. Bivins Registrar Services and Engagement Senior Manager Registrar Services and Industry Relations Internet Corporation for Assigned Names and Numbers (ICANN) Direct: +1 (202) 249-7551 Fax: +1 (202) 789-0104 Email: amy.bivins(a)icann.org<mailto:amy.bivins@icann.org> www.icann.org<http://www.icann.org>

2 4

Additional notes, background for 9 January IRT Call
by Amy Bivins Jan. 9, 2018

Jan. 9, 2018

Dear Colleagues, In advance of our meeting on Tuesday, I'm including a few background points that may have been forgotten or lost since it's been awhile since we have discussed the upcoming PPAA sections we expect to cover during the meeting. Reviewing the IRT's feedback on the substance of the draft contract, we will likely be able to make it through the rest of the PPAA draft (not including the specifications) next week. With respect to the feedback received on PPAA Section 3.12 (abuse contact): Per discussion on IRT calls in early 2017, we began drafting this section with RAA requirements where Final Report was silent (final report mentioned "designated" rather than "dedicated" contact but was otherwise silent on specific abuse contact requirements. The IRT supported this approach at the time. We adapted RAA requirements, per IRT discussions and Final Report, to allow for abuse contact options other than an email address (per recommendation in final report--"to address increasing volumes of spam" associated with the publication of an abuse contact email address (see p. 62 of Final Report). Re: PSWG feedback--this "abuse contact" provision governs when other frameworks (LEA or IP) do not apply IRT feedback re: Section 3.12.2 is noted-I believe the edits were added in an attempt to capture the requirements of the LEA framework, but this can be handled within the framework itself. Section 3.14: This edit was proposed based on text from Final Report in the IP framework-this was discussed briefly on a prior IRT call but can be discussed further. Section 3.17: IRT feedback was that this does not read consistently with Final Report. IRT members who raised this point are asked to explain why/how they believe this is inconstant with the Final Report, as our interpretation of this text is that it has the same meaning as the Final Report. Section 3.19: This requirement was included in the Final Report. Please provide any further feedback on these or any other aspects of the PPAA and issues identified in the issues list on the list prior to our call next week. Best, Amy Amy E. Bivins Registrar Services and Engagement Senior Manager Registrar Services and Industry Relations Internet Corporation for Assigned Names and Numbers (ICANN) Direct: +1 (202) 249-7551 Fax: +1 (202) 789-0104 Email: amy.bivins(a)icann.org<mailto:amy.bivins@icann.org> www.icann.org<http://www.icann.org>

6 5

Reminder--IRT feedback requested by 5 January on items discussed at last meeting
by Amy Bivins Jan. 2, 2018

Jan. 2, 2018

Dear Colleagues, Hello, and happy new year! This is a reminder that your feedback is requested by Friday, 5 January, on the issues discussed on the most recent IRT call (set forth in greater detail below). For next week’s meeting, on 9 January, we will pick up where you left off at the last meeting—at Section 3.12 (abuse contact) of the draft PPAA (see also starting at p. 20 on the attached issues list). We will proceed as far as we can next week on the issues list. I’m also working to put together an updated project status update so that we can see where we are on all of the project deliverables and better estimate when we will be ready for public comment, and I hope to have that ready to share with you next week. Please continue to respond to the list with issues, comments and any other feedback that you would like to add to the attached issues list. Best, Amy Amy E. Bivins Registrar Services and Engagement Senior Manager Registrar Services and Industry Relations Internet Corporation for Assigned Names and Numbers (ICANN) Direct: +1 (202) 249-7551 Fax: +1 (202) 789-0104 Email: amy.bivins(a)icann.org<mailto:amy.bivins@icann.org> www.icann.org<http://www.icann.org> From: Gdd-gnso-ppsai-impl [mailto:gdd-gnso-ppsai-impl-bounces@icann.org] On Behalf Of Caitlin Tubergen Sent: Thursday, December 21, 2017 10:40 PM To: gdd-gnso-ppsai-impl(a)icann.org Cc: Roman, Peter (CRM) <Peter.Roman(a)usdoj.gov> Subject: [Gdd-gnso-ppsai-impl] Materials, action items from Tuesday, 19 December 2017 Privacy/Proxy IRT call 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<mailto:caitlin.tubergen@icann.org>

1 0

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