[Gdd-gnso-ppsai-impl] Materials and questions for 24 January PP IRT Call

Tue Jan 24 12:37:14 UTC 2017

Hi Amy, et al.,

Below my comments on the AB's and some other additional comments.

Section 2
AB1 looks good.

AB2 looks good.

AB3 No comment

AB4 No comment

AB5 No comment

AB6 & AB7. I would shorten this and make sure WDRP is a requirement for 
those providers. I think how the WDRP policy is specified is clear 
enough for those providers compared to definitions of "customers."

AB8 Yes, include RDS

AB9 From that I gathered from the list there is no issue, as such, we do 
not need to include it.

AB10 Underlying data only, we already established earlier on that 
providers should have accurate and contactable data in the WHOIS.

AB11 I would freeze this one for now. See what happens when we discuss 
transfers.

AB12 Not sure what the question is. This is already something Registrars 
do, and it works fine?

AB13 discussion point for the legal folks among us?

Not an AB but should be an AB:
vii. Privacy and Proxy Service provider terms of service SHALL include 
pricing information.

TG: How do we imagine this when we offer our services through resellers 
or other parties. I suggest we Registrars take a good look at this one 
and discuss this one in either a sub-group or amongst ourselves.

AB14 Not sure, current language might clash with UDRP?

AB15 What language does the SPEC 11 Framework WG suggest here language 
wise? I think we have the same discussion there.

AB16 AB17 AB18 AB19
Not sure how we want to handle these, looks pretty complex at the moment.

AB20
Registrars should dive into this one and scope the technical issues and 
perhaps suggest workable language here that does justice to the intent 
of the recommendations.

G. Reveal (Publication and Disclosure)
i. In deciding whether or not to comply with a Disclosure or Publication 
request, Privacy and Proxy Service providers SHALL NOT mandate that a 
Requester first make a Relay request.

TG I am not sure what we are trying to solve here.

AB21 Hard to define in my opinion. These matters can be complex, consult 
lawyers, etc. Perhaps the provider should describe the process with the 
predicted time lines to the requestor? Can we come up with some language 
that captures this?

AB 22 Agreed

AB23 Yes at first glance. But this one is most likely more complex as 
privacy providers can only deal with a very limited set of abuse.

AB24 That is my recollection also from the WG sessions.

AB25 I do not recall that data retention was on the menu. Data Escrow was.

Section 5

AB1 Agreed with the latter, bring them in scope and see where they end up.

AB2 & AB3 Is this happening? I am not sure what we are trying to solve 
here. A Registrant has a contract with their Registrar or Reseller, this 
contract deals with the renewals and restores. That there is a separate 
service regarding privacy services does not diminish the contract 
between the Registrant and Registrar, right?

Transfers lets revisit this when we have transfers more in scope.

Section 6

AB1 agreed
AB2 agreed, let's discuss this.
AB3, I thought it was the GNSO, but I am not sure here.

Best,

Theo

On 23-1-2017 19:28, Amy Bivins wrote:
>
> Hi Steve,
>
> Thank you for your quick response and suggestion. This approach was 
> not considered—we started with the approach taken in the statement of 
> registrar accreditation policy, which includes Policy requirements 
> that are further developed in the RAA, 
> https://www.icann.org/resources/pages/policy-statement-2012-02-25-en#II.
>
> However, that is not to say that we can’t take this approach, and your 
> reasoning outlined below clearly explains the potential benefits.
>
> What do others on the list think? I will also raise this internally 
> today and hope to have some additional information to share with you 
> tomorrow on the call.
>
> If we end up taking this approach and decide to significantly reduce 
> this section of the Policy, there are still many questions in the 
> document that we can discuss tomorrow to aid in our drafting of the 
> first versions of the contractual provisions for the IRT’s review.
>
> Best,
>
> Amy
>
> *Amy E. Bivins*
>
> Registrar Policy Services 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
>
> www.icann.org
>
> *From:* gdd-gnso-ppsai-impl-bounces at icann.org 
> [mailto:gdd-gnso-ppsai-impl-bounces at icann.org] *On Behalf Of 
> *Metalitz, Steven
> *Sent:* Monday, January 23, 2017 1:06 PM
> *To:* gdd-gnso-ppsai-impl at icann.org
> *Subject:* Re: [Gdd-gnso-ppsai-impl] Materials and questions for 24 
> January PP IRT Call
>
> Hello Amy and colleagues,
>
> A threshold question regarding your draft of section II:
>
> I am not clear on your distinction between the level of specificity in 
> the document called “policy” and in the contract that accredited 
> services would be asked to sign.
>
> One approach would be for section II to read in its entirety:
>
> “Privacy and Proxy Service providers SHALL enter into and maintain in 
> effect Accreditation Agreements with ICANN that set out the terms and 
> conditions of accreditation.   The current standard Accreditation 
> Agreement is attached as Attachment A. “
>
> There could be at least two advantages to this approach. First, we 
> would save the time required to set varying levels of specificity 
> between the two documents.  (For instance, as noted in your MS Word 
> comment #9, deciding whether we agree or disagree with your belief 
> that the triggering requirements for verification and reverification 
> of customer information is “more appropriately included in the 
> contract” than in the policy.)  Second, this would avoid the situation 
> in which there might be perceived (or real) discrepancies between the 
> statement in this section of the Policy and the actual terms of the 
> Agreement to which providers would be subject.  In other words, more 
> efficiency for this IRT and less ambiguity and confusion once the 
> program is in place.
>
> Was this approach considered, and if so , why was it rejected?
>
> A variation on my suggestion would be for IRT to review a draft 
> accreditation agreement first, and then turn to whether any of its 
> provisions need to be summarized or specifically referenced in section 
> II of the policy document.
>
> Looking forward to your response.  Thanks.
>
> Steve Metalitz
>
> **
>
> *From:*gdd-gnso-ppsai-impl-bounces at icann.org 
> <mailto:gdd-gnso-ppsai-impl-bounces at icann.org> 
> [mailto:gdd-gnso-ppsai-impl-bounces at icann.org] *On Behalf Of *Amy Bivins
> *Sent:* Sunday, January 22, 2017 2:17 PM
> *To:* gdd-gnso-ppsai-impl at icann.org <mailto:gdd-gnso-ppsai-impl at icann.org>
> *Subject:* [Gdd-gnso-ppsai-impl] Materials and questions for 24 
> January PP IRT Call
>
> Dear Colleagues,
>
> Attached are documents for discussion on Tuesday’s (24 January, 15:00 
> UTC) Privacy and Proxy Service Provider Accreditation Program IRT 
> call: draft Policy sections 2, 5, and 6.
>
> We will review as much of these documents as we can Tuesday, and 
> continue with them next week, if needed. The poll results show a clear 
> preference for weekly meetings, so we will be moving to that 
> schedule—thank you for your participation in the poll! A meeting 
> reminder will be distributed on Monday.
>
> I want to flag some of the questions we have for you on Section 2, as 
> noted in more detail in the attached:
>
> 1.The Final Report in some cases uses the word “SHOULD.”  ICANN org 
> requests the IRT’s feedback on the PDP WG’s intent in using the word 
> (as SHOULD is defined here: http://www.ietf.org/rfc/rfc2119.txt), and 
> whether “SHALL” was intended in any of these instances.
>
> 2.With respect to data reminders, did the PDP WG intend for these 
> reminders to reference (a) any Customer information that appears in 
> WHOIS, (b) the underlying Customer data, or (c) both?
>
> 3.With respect to data validation and verification, did the PDP WG 
> intend for the requirement to apply to (a) any Customer data, as 
> relevant, in WHOIS; (b) underlying Customer data, as relevant, or (c) 
> both? (Additional questions in document)
>
> 4.Did the PDP WG intend for ICANN org to implement new requirements 
> for Privacy and Proxy Service providers to escrow and retain data, 
> distinct from the existing requirements in the RAA?
>
> 5.Did the PDP WG intend for this implementation to create minimum, 
> mandatory criteria for *all* requests to Privacy and Proxy Service 
> providers (See draft Section 2.J)?
>
> We will also seek your feedback on the level of detail that is being 
> proposed for the Policy versus the contract.
>
> If you have any questions or want to begin to discussing these issues 
> on-list before the call, please feel free to do so. I look forward to 
> speaking with you on Tuesday.
>
> Best,
>
> Amy
>
> *Amy E. Bivins*
>
> Registrar Policy Services 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/20170124/e9122691/attachment-0001.html>