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@icann.org

www.icann.org

 

 

 

From: gdd-gnso-ppsai-impl-bounces@icann.org [mailto:gdd-gnso-ppsai-impl-bounces@icann.org] On Behalf Of Metalitz, Steven
Sent: Monday, January 23, 2017 1:06 PM
To: gdd-gnso-ppsai-impl@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@icann.org [mailto:gdd-gnso-ppsai-impl-bounces@icann.org] On Behalf Of Amy Bivins
Sent: Sunday, January 22, 2017 2:17 PM
To: gdd-gnso-ppsai-impl@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@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