[Gdd-gnso-ppsai-impl] Summary of today's privacy/proxy IRT call, IRT action items

Thu Jan 18 21:34:01 UTC 2018

I don’t agree with Sara regarding whether any of these points represent new policy.  That said I recognize we have not yet reached agreement on them!  See a couple of comments inline below.

[image001]
Steven J. Metalitz | Partner, through his professional corporation
T: 202.355.7902 | met at msk.com<mailto:met at 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 [mailto:gdd-gnso-ppsai-impl-bounces at icann.org] On Behalf Of Theo Geurts
Sent: Thursday, January 18, 2018 1:52 PM
To: gdd-gnso-ppsai-impl at icann.org; Sara Bockey
Subject: Re: [Gdd-gnso-ppsai-impl] Summary of today's privacy/proxy IRT call, IRT action items

Agreed with Sara,

If we are creating new policy, we should move that to the GNSO Council; this is not within the scope of an IRT to create policy.

Regarding WG recommendations.
The recommendations are usually a result of a very long deliberation process, so we need to be careful.
Flagging it for the comment period is not sufficient.

If for whatever reason a recommendation is no longer deemed adequate, then it should be moved to the GNSO Council, we should not overstep our mandate as an IRT.

Thanks,

Theo

On 18-1-2018 18:17, Sara Bockey wrote:
Please see my comments in green below.

Sara

sara bockey
sr. policy manager | GoDaddy™
sbockey at godaddy.com<mailto:sbockey at 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 <gdd-gnso-ppsai-impl-bounces at icann.org><mailto:gdd-gnso-ppsai-impl-bounces at icann.org> on behalf of Amy Bivins <amy.bivins at icann.org><mailto:amy.bivins at icann.org>
Reply-To: "gdd-gnso-ppsai-impl at icann.org"<mailto:gdd-gnso-ppsai-impl at icann.org> <gdd-gnso-ppsai-impl at icann.org><mailto:gdd-gnso-ppsai-impl at icann.org>
Date: Tuesday, January 16, 2018 at 11:15 AM
To: "gdd-gnso-ppsai-impl at icann.org"<mailto:gdd-gnso-ppsai-impl at icann.org> <gdd-gnso-ppsai-impl at icann.org><mailto:gdd-gnso-ppsai-impl at 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/<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.

Steve:  Not sure this creates new policy.  The PPSAI WG indicated that validation/verification requirements on providers should be “in a manner consistent with the requirements outlined in the Whois Accuracy Program Specification of the RAA.”  WG report page 9.  If a new registration triggers a verification obligation on the registrar (and I believe it does), then why wouldn’t a new sign-up to a P/P service trigger the same obligation on the service provider?

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.

 Steve:  The provision cited by Sara (pp.67-68 of the WG report) was in the context of whether responses to disclosure requests would be automated or manual.  It does not really address timing.  So long as we are not asking in the agreement for a provider to refrain from manual processing, then it does not seem inconsistent with the WG report at all.  Indeed, the WG report acknowledges that “there may be a need in certain circumstances to differentiate between a request made by law enforcement authorities and one made by other third parties such as intellectual property rights holders, or private anti-abuse organizations. “  WG report p. 67.  The short timeline for responding to high priority LEA requests would be one such differentiation.

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 at icann.org<mailto:amy.bivins at icann.org>
www.icann.org<http://www.icann.org>

_______________________________________________

Gdd-gnso-ppsai-impl mailing list

Gdd-gnso-ppsai-impl at icann.org<mailto:Gdd-gnso-ppsai-impl at icann.org>

https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl<https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gdd-gnso-ppsai-impl/attachments/20180118/0269601b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2772 bytes
Desc: image001.gif
URL: <http://mm.icann.org/pipermail/gdd-gnso-ppsai-impl/attachments/20180118/0269601b/image001-0001.gif>