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

Thu Jan 18 18:52:20 UTC 2018

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 | **Go**Daddy^™ *
>
> *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> on 
> behalf of Amy Bivins <amy.bivins at icann.org>
> *Reply-To: *"gdd-gnso-ppsai-impl at icann.org" 
> <gdd-gnso-ppsai-impl at icann.org>
> *Date: *Tuesday, January 16, 2018 at 11:15 AM
> *To: *"gdd-gnso-ppsai-impl at icann.org" <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/
>
> 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
>
> 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
> 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/633b1d74/attachment-0001.html>