+1 to Sara's comments and recommendations. Thanks, Eric On Thu, Jan 18, 2018 at 12:17 PM, Sara Bockey <sbockey@godaddy.com> wrote:
Please see my comments in green below.
Sara
*sara bockey*
*sr. policy manager | **Go**Daddy™*
*sbockey@godaddy.com <sbockey@godaddy.com> 480-366-3616 <(480)%20366-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 <gdd-gnso-ppsai-impl-bounces@icann.org> on behalf of Amy Bivins <amy.bivins@icann.org> *Reply-To: *"gdd-gnso-ppsai-impl@icann.org" <gdd-gnso-ppsai-impl@icann.org
*Date: *Tuesday, January 16, 2018 at 11:15 AM *To: *"gdd-gnso-ppsai-impl@icann.org" <gdd-gnso-ppsai-impl@icann.org> *Subject: *[Gdd-gnso-ppsai-impl] Summary of today's privacy/proxy IRT call, IRT action items
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.
It is not necessarily that Section 3 needs to be moved to the beginning, but that it should be asserted in the first paragraph that if you are an Affiliated Provider and therefore your Affiliated Registrar is performing or has already preformed this task, the entire Specification does not apply to you. To me, this Specification is for Non-Affiliated Providers.
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.*
I’m concerned that this creates new policy, at least as related to non-affiliated providers. This issue would need to be sent to the GNSO for consideration.
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.
I am concerned that the processing/responding timeline proposed by PSWG is beyond the scope of the WG recommendations and creating new policy.
Please see Category F of the Final Report. The WG agreed that a point of contact should be “designated” rather than a “dedicated” and that none of the WG recommendations should be read as being intended to alter (or mandate the alteration of) the prevailing practice among P/P service providers to review requests manually or to facilitate direct resolution of an issue between a Requester and a customer.
Most, if not all, current Service Providers operate M-F, 9-5. They are not 24/7 operations. As the request for response within a 24-hour period is beyond the prevailing practice of providers, if PSWG wishes for this request to be considered, then we need to send the issue to the GNSO for consideration. Flagging it for public comment, as suggested by staff, is not sufficient.
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 <(202)%20249-7551>
Fax: +1 (202) 789-0104 <(202)%20789-0104>
Email: amy.bivins@icann.org
www.icann.org
_______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl@icann.org https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl