[Gdd-gnso-ppsai-impl] [Ext] Re: Materials, action items from 17 Oct Privacy/Proxy IRT call
Darcy Southwell
darcy.southwell at endurance.com
Tue Dec 12 16:53:41 UTC 2017
To follow up on Sara's comment, at a minimum, these are incorrect:
- "Labeling" is a registrar function.
- "Obligations of Providers Affiliated with Registrars" does not apply
to Unaffiliated Providers.
Thanks,
Darcy
__________
*Darcy Southwell *| Compliance Officer
M: +1 503-453-7305 │ Skype: darcy.enyeart
On Mon, Dec 11, 2017 at 12:31 PM, Sara Bockey <sbockey at godaddy.com> wrote:
> Thanks, Caitlin!
>
>
>
> In comparing the table to the comments submitted, I note that staff has
> checked some topics as applicable to Service Providers affiliated with a
> registrar which either should not be, as the actions are handled by the
> registrar, or are only applicable in part. I look forward to reviewing
> these closer as we work our way thru all of comments and topics.
>
>
>
> Best,
>
>
>
> Sara
>
>
>
> *sara bockey*
>
> *sr. policy manager | **Go**Daddy™*
>
> *sbockey at godaddy.com <sbockey at 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: *theo geurts <gtheo at xs4all.nl>
> *Date: *Monday, December 11, 2017 at 12:53 PM
> *To: *"gdd-gnso-ppsai-impl at icann.org" <gdd-gnso-ppsai-impl at icann.org>,
> Caitlin Tubergen <caitlin.tubergen at icann.org>, Sara Bockey <
> sbockey at godaddy.com>
> *Cc: *"Roman, Peter (CRM)" <Peter.Roman at usdoj.gov>
> *Subject: *Re: [Gdd-gnso-ppsai-impl] [Ext] Re: Materials, action items
> from 17 Oct Privacy/Proxy IRT call
>
>
>
> Thanks Caitlin,
>
> I scanned this briefly, and so far no comments yet, I do have a question
> for us.
>
> When there is a UDRP, and there is an unaffiliated provider in the mix,
> presumably the UDRP provider checks with the unaffiliated provider for the
> registrant details. The sponsoring registrar will have to carry out the
> rest of the operational stuff that comes with the UDRP, i.e., lock domain,
> etc. I guess the UDRP provider has to coordinate with the registrar and the
> unaffiliated privacy provider.
>
> Does this require a modification to the UDRP process? If yes, how does
> that procedure wise look like?
>
> I will have to skip tomorrow's meeting.
>
> Thanks,
>
> Theo
>
>
>
> On 11-12-2017 17:49, Caitlin Tubergen wrote:
>
> Dear Colleagues,
>
>
>
> Further to Sara’s suggestion in this message and the accompanying
> discussion on last Tuesday’s call, we have compiled a table which breaks
> down the sections of the draft PPAA, and divides the sections into
> affiliated and unaffiliated requirements. We can use this table for
> discussion purposes as we begin going through the updated issues list on
> tomorrow’s call.
>
>
>
> Thank you!
>
>
>
> Kind regards,
>
>
>
> *Caitlin Tubergen*
>
> Registrar Services and Engagement Senior Manager
>
> ICANN
>
> 12025 Waterfront Drive, Suite 300
>
> Los Angeles, CA 90094
>
> Office: +1 310 578 8666 <(310)%20578-8666>
>
> Mobile: +1 310 699 5326 <(310)%20699-5326>
>
> Email: caitlin.tubergen at icann.org
>
>
>
>
>
>
>
> *From: *Sara Bockey <sbockey at godaddy.com> <sbockey at godaddy.com>
> *Date: *Friday, December 1, 2017 at 10:09 AM
> *To: *Caitlin Tubergen <caitlin.tubergen at icann.org>
> <caitlin.tubergen at icann.org>, "gdd-gnso-ppsai-impl at icann.org"
> <gdd-gnso-ppsai-impl at icann.org> <gdd-gnso-ppsai-impl at icann.org>
> <gdd-gnso-ppsai-impl at icann.org>
> *Cc: *"Roman, Peter (CRM)" <Peter.Roman at usdoj.gov> <Peter.Roman at usdoj.gov>,
> Sara Bockey <sbockey at godaddy.com> <sbockey at godaddy.com>, 'Darcy
> Southwell' <darcy.southwell at endurance.com> <darcy.southwell at endurance.com>
> *Subject: *[Ext] Re: [Gdd-gnso-ppsai-impl] Materials, action items from
> 17 Oct Privacy/Proxy IRT call
>
>
>
> Hi all,
>
>
>
> In my last-minute reviewing of the PPAA, I’ve had a few additional
> thoughts:
>
>
>
> We need to revisit PPAA, Spec 2: Customer Data Accuracy. This entire Spec
> needs to be revisited and made clearer since the entire spec is dependent
> on whether or not the Service Provider is affiliated or non-affiliated.
> It’s very disjointed, it starts out Section 1, this is what you need to do,
> then in Section 3, it says you don’t need to do this if you are an
> affiliated Provider, and then in Section 4 it goes back to this is what you
> need to do and forgets about section 3. It seems to me that this entire
> section is dependent on if there is an Affiliated Registrar.
>
>
>
> This section got me thinking and IMHO, in addition to going thru every
> comment that has been submitted and sorting through those issues, I think
> we need to take a serious look at the approach of the PPAA. I think the
> document as it stands is not recognizing the Service Provider as an
> Affiliate of an ICANN accredited Registrar. I’m wondering if what we
> really need is 2 separate PPAAs – one for an Affiliated Service Provider
> and one for a Non-Affiliated Service Provider. For the Affiliated Service
> Provider, it should set out at the very beginning the affiliate
> relationship, and both parties would sign. The basic idea would be
> something like:
>
>
>
> Service Provider X, as an Affiliate of ICANN accredited Registrar A,
> enters into this PPAA to provide a privacy/proxy service. Registrar A, as
> a party to this agreement, agrees to uphold its obligations under the RAA
> and its related consensus policies. Should the relationship between
> Service Provider X and Registrar A cease, so shall this agreement, and
> Service Provider X will have ___ number of days to secure a new affiliate
> registrar and enter into a new Affiliated PPAA or complete the
> Non-Affiliated process and sign the Non-Affiliate PPAA.
>
>
>
> It needs work, I know, but just trying to illustrate the idea. I think
> this would allow the affiliated agreement to be considerably more light
> weight.
>
>
>
> The Non-Affiliate PPAA would be more in line with what we have now (and,
> granted, would need additional work).
>
>
>
> If the Affiliate Provider became unaffiliated, it would need to go thru an
> accreditation process to ensure it meet the requirements. So there would
> need to be 2 accreditation procedures, but again I’m thinking the
> Affiliated process would be relatively light weight based on the
> relationship of the provider to the accredited registrar.
>
>
>
> Also, we need to correct some of the language in the PPAA. Specifically,
> as I’ve stated numerous times before, I think staff’s use of “Customer” in
> place of RNH is problematic when the PPAA is an extension of/referenced in
> the RAA, particularly when considering the above line of thinking.
>
>
>
> The 2013 RAA defines “Registered Name” as a domain name within the domain
> of a gTLD, about which a gTLD Registry Operator (or an Affiliate or
> subcontractor thereof engaged in providing Registry Services) maintains
> data in a Registry Database, arranges for such maintenance, or derives
> revenue from such maintenance, and “Registered Name Holder” is defined as
> the holder of a Registered Name.
>
>
>
> This is a service for the RNH, provided via an Affiliate Registrar, the
> use of “customer” is problematic.
>
>
>
> I’ll admit I’ve not thought thru all the issues and this is kind of loose,
> but it’s an idea that came to mind and something we might ought to consider
> so I’m putting a marker down to discuss the above in case it offers a
> better path forward. Happy to hear what others think.
>
>
>
> Sara
>
>
>
> *sara bockey*
>
> *sr. policy manager | GoDaddy™*
>
> *sbockey at godaddy.com <sbockey at 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: *Caitlin Tubergen <caitlin.tubergen at icann.org>
> <caitlin.tubergen at icann.org>
> *Date: *Thursday, November 30, 2017 at 5:05 PM
> *To: *"gdd-gnso-ppsai-impl at icann.org" <gdd-gnso-ppsai-impl at icann.org>
> <gdd-gnso-ppsai-impl at icann.org> <gdd-gnso-ppsai-impl at icann.org>, Sara
> Bockey <sbockey at godaddy.com> <sbockey at godaddy.com>, 'Darcy Southwell'
> <darcy.southwell at endurance.com> <darcy.southwell at endurance.com>
> *Cc: *"Roman, Peter (CRM)" <Peter.Roman at usdoj.gov> <Peter.Roman at usdoj.gov>
> *Subject: *Re: [Gdd-gnso-ppsai-impl] Materials, action items from 17 Oct
> Privacy/Proxy IRT call
>
>
>
> Thank you, Steve, and thank you to the registrars who submitted comments.
>
>
>
> I will compile all of the comments, and we can begin going through the
> comments on Tuesday’s call.
>
>
>
> If any other IRT members have comments on the draft PPAA, please submit
> them by the deadline of *Friday, 1 December*.
>
>
>
> Kind regards,
>
>
>
> *Caitlin Tubergen*
>
> Registrar Services and Engagement Senior Manager
>
> ICANN
>
> 12025 Waterfront Drive, Suite 300
>
> Los Angeles, CA 90094
>
> Office: +1 310 578 8666 <(310)%20578-8666>
>
> Mobile: +1 310 699 5326 <(310)%20699-5326>
>
> Email: caitlin.tubergen at icann.org
>
>
>
>
>
>
>
> *From: *Gdd-gnso-ppsai-impl <gdd-gnso-ppsai-impl-bounces at icann.org>
> <gdd-gnso-ppsai-impl-bounces at icann.org> on behalf of "Metalitz, Steven"
> <met at msk.com> <met at msk.com>
> *Reply-To: *"gdd-gnso-ppsai-impl at icann.org"
> <gdd-gnso-ppsai-impl at icann.org> <gdd-gnso-ppsai-impl at icann.org>
> <gdd-gnso-ppsai-impl at icann.org>
> *Date: *Thursday, November 30, 2017 at 2:16 PM
> *To: *'Sara Bockey' <sbockey at godaddy.com> <sbockey at godaddy.com>, 'Darcy
> Southwell' <darcy.southwell at endurance.com> <darcy.southwell at endurance.com>,
> "'gdd-gnso-ppsai-impl at icann.org'" <'gdd-gnso-ppsai-impl at icann.org'>
> <gdd-gnso-ppsai-impl at icann.org> <gdd-gnso-ppsai-impl at icann.org>
> *Subject: *Re: [Gdd-gnso-ppsai-impl] Materials, action items from 17 Oct
> Privacy/Proxy IRT call
>
>
>
> PPSAI colleagues,
>
> I offer the following comments and suggested edits regarding the Oct. 20
> redline version of the PPAA. I may have a few other suggestions by
> tomorrow’s deadline, and will definitely have responses later to some of
> the other proposed edits that have been sent to the list. (And thanks to
> Theo and colleagues for their comprehensive review of the document!)
>
> First, I would reiterate the suggestions made in my Oct. 21 posting to the
> list, as follows:
>
> Subsection 3.5.3.15: strike “should” and insert “shall,” for consistency
> with parallel provisions throughout this section 3.5.
>
> Section 3.7, third line from the bottom: “employee” should be “employ.”
>
> Section 3.17.1: I suggest adding the words “as applicable” or “to the
> extent applicable” at the end of the section. Not every Disclosure or
> Publication request that Provider receives will fall under the IP or LEA
> disclosure frameworks.
>
> Section 5.7.3: the notice that the suspended Provider must send to
> customers should specify “that it is unable to offer or provide the
> Services *for any new registrations”* (adding the last 4 words). A
> suspended Provider can (and indeed must) provide the Services to its
> current customers. [Note that the phrasing “any additional registrations”
> might be more accurate here, and in the corresponding provision of 5.7.1
> --- otherwise it might be possible for a suspended provider to being
> providing services for the first time to an existing registration whose
> registrant decides to engage a service.]
>
> Here are some additional suggestions:
>
> Section 1.43: strike “comprising the Working Group,” insert
> “representatives of the Service Providers.” This issue is noted on page 2
> of the Discussion Items document.
>
> Section 3.5.3.3: since this has to do with p/p services and not with
> registration per se, the references to “initial registration and each
> renewal registration” should be changed to something like “each initial
> agreement to provide Services and each renewal or extension of such
> agreement.” I believe this is also responsive to Theo’s sticky note on the
> RrSG redline for this section.
>
> Section 3.8.1 (specifying what needs to be stated on request forms) should
> include a cross-reference to section 3.8.2 (requiring publication of links
> to request forms in some circumstances). Alternatively, perhaps the order
> of these two sections should be reversed.
>
> Section 3.8.5.5 needs some rephrasing. Reveal is not a defined term in
> the PPAA, and the provider does not itself Publish data in the RDS (the
> registrar or registry does that), but can cause it to be Published. This
> may a rare instance in which use of the passive voice may be preferable
> (“the circumstances under which the Customer’s identity or contact data
> will be published in the RDDS….”).
>
> Section 3.19: substitute “shall” for “should.” In fact the entire
> document should be reviewed to see where this change is needed.
>
> Section 5.3: this is another issue I raised in my Oct. 21 posting:
> “Section 5.3 does not give ICANN the right to substitute the new version of
> the agreement, it gives that right to the *provider. *Furthermore, 5.3
> addresses the scenario in which the new agreement is swapped in during
> the term of the current agreement. The point I was trying to raise on the
> call (and I am sorry if this was not clear) is ensuring that all renewals
> of the agreement *at the end of the term* reflect the most recent
> version. As currently drafted, section 5.2 seems to give the provider the
> option of renewing under the terms of the old agreement (“under the terms
> and conditions of this agreement”), even if it has been superseded by a new
> form of agreement that is materially different. This could be fixed by
> adding a subsection 5.2.5 along the following lines: ‘5.2.5: this
> Agreement has been superseded by a revised form accreditation agreement for
> the provision of the Services (“Updated PPAA”) that is materially different
> from this Agreement, in which case the right of renewal provided by this
> section shall be under the terms and conditions of the Updated PPAA.’”
>
> Section 5.7.4: consider inserting at the end of the first sentence “or
> its invocation of section 5.5.7,” which is another path ICANN could take to
> deal with the situation of an uncured “endangerment” scenario.
>
> Section 7.4.1: shouldn’t the Working Group be the party to receive the
> notice re revision of the Agreement? This would be consistent with the
> rest of section 7.4.
>
> Glad to try to answer any questions about these.
>
> Steve Metalitz
>
>
>
>
>
>
>
>
>
> *[image: 01]*
>
> *Steven J. Metalitz *| *Partner, through his professional corporation*
>
> T: 202.355.7902 <(202)%20355-7902> | met at msk.com
>
> *Mitchell Silberberg & Knupp* *LLP* | *www.msk.com*[msk.com]
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.msk.com_&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=8K75qGdDlOta4kh6k2F0jrT195M3tF3J_Fxcz6EvuG2kYKDeA67ZTEnthHXAPVXH&m=TjlmETQzu_l-1XrQJX8JzXMwXmo1RvgLFey6ZVbBgek&s=8MX5PFJVxEz3iLo0XKUPMHlLAtZUzvUD5Us9VmG5doY&e=>
>
> 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:* Metalitz, Steven
> *Sent:* Tuesday, November 07, 2017 11:42 AM
> *To:* 'Sara Bockey'; Darcy Southwell; gdd-gnso-ppsai-impl at icann.org
> *Subject:* RE: [Gdd-gnso-ppsai-impl] Materials, action items from 17 Oct
> Privacy/Proxy IRT call
>
>
>
> I agree with a lot of what Darcy says. Let me make sure my view is
> clearly stated.
>
>
>
> Most of the items Darcy identifies are completely appropriate for
> discussion in our team before the documents are finalized. These issues
> include: perceived discrepancies between the WG Final Report and the
> implementation documents; loose ends in the Law Enforcement disclosure
> framework; and clarifying the status of each of the four documents under
> review. I support addressing these points on our next call so that we can
> continue to make progress. And based on the postings made to our list over
> the last couple of weeks, I would certainly be comfortable with some
> relaxation of the deadline for proposing edits to the accreditation
> agreement – if necessary, to December 1.
>
>
>
> My concerns are focused primarily on the suggestion that we can’t move
> forward until we determine whether our recommendations are GDPR-compliant.
> To me that sounds like some on the IRT want to suspend work until ICANN’s
> separate work on GDPR is concluded. If that is not what is meant, then I
> would ask proponents of that view to clarify just how they think we should
> proceed at this point.
>
>
>
> I am also sad to see the IRTP-C issue brought up again. I thought we had
> reached agreement that the current suspension of ICANN enforcement of this
> aspect of that policy could be continued until an appropriate group is
> formed to address it; or put another way, that we could proceed to get our
> PPSAI implementation plan out for public comment without delaying it until
> the IRTP-C issue is resolved. That is my recollection, anyway, but if I am
> mistaken then please show me how.
>
>
>
> Finally I will repeat my question of whether our call time on 11/14
> remains at 1400 UTC or whether it will be moved an hour later to preserve
> the usual start time in most Northern Hemisphere time zones.
>
>
>
> Steve
>
>
>
>
>
>
>
> *[image: 01]*
>
> *Steven J. Metalitz *| *Partner, through his professional corporation*
>
> T: 202.355.7902 <(202)%20355-7902> | met at msk.com
>
> *Mitchell Silberberg & Knupp* *LLP* | *www.msk.com*[msk.com]
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.msk.com_&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=8K75qGdDlOta4kh6k2F0jrT195M3tF3J_Fxcz6EvuG2kYKDeA67ZTEnthHXAPVXH&m=TjlmETQzu_l-1XrQJX8JzXMwXmo1RvgLFey6ZVbBgek&s=8MX5PFJVxEz3iLo0XKUPMHlLAtZUzvUD5Us9VmG5doY&e=>
>
> 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:* Sara Bockey [mailto:sbockey at godaddy.com <sbockey at godaddy.com>]
> *Sent:* Tuesday, November 07, 2017 11:07 AM
> *To:* Darcy Southwell; gdd-gnso-ppsai-impl at icann.org; Metalitz, Steven
> *Cc:* Sara Bockey
> *Subject:* Re: [Gdd-gnso-ppsai-impl] Materials, action items from 17 Oct
> Privacy/Proxy IRT call
>
>
>
> Well said, Darcy. Agree 100%.
>
>
>
> *sara bockey*
>
> *sr. policy manager | GoDaddy™*
>
> *sbockey at godaddy.com* <sbockey at 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: *Darcy Southwell <darcy.southwell at endurance.com>
> *Date: *Tuesday, November 7, 2017 at 8:47 AM
> *To: *"gdd-gnso-ppsai-impl at icann.org" <gdd-gnso-ppsai-impl at icann.org>,
> "Metalitz, Steven" <met at msk.com>, Sara Bockey <sbockey at godaddy.com>
> *Subject: *Re: [Gdd-gnso-ppsai-impl] Materials, action items from 17 Oct
> Privacy/Proxy IRT call
>
>
>
> I agree with Theo. The scope has changed and implementation is impacted
> by GDPR. While I appreciate that Steve wants to move forward
> expeditiously, I don’t believe we can do so without jeopardizing the
> creation of an effective program. Further, in just the last week or so,
> issues have been raised about implementation language contradicting the
> policy. The role of an IRT is to implement the consensus policy produced
> in the PDP and we need to spend sufficient time reviewing and discussing
> the implementation to ensure we’re not changing policy. Similarly, I think
> there were questions raised about the proposed framework Public Safety
> Working Group. In addition to policy creep, I believe concerns were
> expressed that staff failed to modify the proposed framework based on the
> feedback from IRT participants. Rather than picking through the documents
> line by line, it seems like we should step back and have a discussion about
> the concepts to ensure we’re making progress toward an effective
> implementation that reflects the policy. There have also been repeated
> questions raised about the over-engineering of this implementation.
> Because many of the meetings have focused on reviewing language from a
> specific section (rather than reviewing issues as whole items), it seems
> like we haven’t gotten past this issue, and should probably take a fresh
> look at that to ensure we’re not making this implementation more
> complicated than it needs to be. We all know that doesn’t lead us to a
> better implementation. Right now, we have four draft documents for
> review/input: (1) accreditation agreement, (2) de-accreditation process,
> (3) applicant guide, and (4) data escrow specification. For many members,
> these require operational and legal review (at a minimum). Many registrars
> have commented that 1 December is the earliest they can provide full
> feedback given the complexity of these documents (although not all have
> committed to that date).
>
> Given these issues, as well as the fact that the privacy/proxy challenge
> stemming from IRTP-C needs to be added to this IRT for a solution, we need
> to take a step back and address these critical issues first. This isn’t
> about derailing the IRT; it’s about ensuring we don’t create an
> implementation that’s an operational nightmare for providers as well as
> registrants and end users – and that means addressing these critical issues
> first.
>
>
>
> Thanks,
>
> Darcy
>
>
>
> *From: *<gdd-gnso-ppsai-impl-bounces at icann.org> on behalf of theo geurts <
> gtheo at xs4all.nl>
> *Reply-To: *<gdd-gnso-ppsai-impl at icann.org>
> *Date: *Monday, November 6, 2017 at 12:27 PM
> *To: *<gdd-gnso-ppsai-impl at icann.org>, "Metalitz, Steven" <met at msk.com>,
> Sara Bockey <sbockey at godaddy.com>
> *Subject: *Re: [Gdd-gnso-ppsai-impl] Materials, action items from 17 Oct
> Privacy/Proxy IRT call
>
>
>
> Hi Steve, Vicky,
>
> Now your argument is logical and makes sense.
> Yes, as I mentioned before, CPH's will implement privacy services on many
> different levels to comply with the GDPR, we agree here.
>
> My biggest problem with the PPSAI IRT is the changing dynamics.
> The WG contemplated and discussed and made recommendations based on a very
> fixed situation.
>
> In my opinion, privacy services should not be used as bandaid for data
> protection problems.
> Complying with data protection laws was not the driving force during the
> WG days, and now it is.
>
> I think the scope of the IRT has changed and we should deal with this
> before we move on. We need to think a little smarter and deeper here before
> we unleash this to many contracted parties who have zero experience with
> these services and will be required to implement this to comply with data
> protection laws.
>
> So how do we do that? I think a fixed set of procedures and contractual
> agreements are essential, yet I do not want us to enter into a situation
> that causes more issues and forces providers into a situation that we need
> to ask compliance to defer.
> https://www.icann.org/resources/pages/contractual-
> compliance-statement-2017-11-02-en[icann.org]
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resources_pages_contractual-2Dcompliance-2Dstatement-2D2017-2D11-2D02-2Den&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=8K75qGdDlOta4kh6k2F0jrT195M3tF3J_Fxcz6EvuG2kYKDeA67ZTEnthHXAPVXH&m=TjlmETQzu_l-1XrQJX8JzXMwXmo1RvgLFey6ZVbBgek&s=q9q_ot-MiKykJohQuElKuWK5wQV5itNGjjmmqQCUsy0&e=>
>
> I think that scenario is unwanted for everyone on the IRT is it not?
>
> Thanks,
>
> Theo Geurts
>
>
>
> On 6-11-2017 19:40, Metalitz, Steven wrote:
>
> I strongly second Vicky’s comments. The ongoing ICANN work re GDPR is of
> course very important, but let’s not let it derail progress on the path we
> have moved so far along toward a P/P service accreditation framework to
> present to the community.
>
>
>
> In that regard, I have some sympathy (empathy?) for those requesting a
> relaxation of the comment deadline in light of so much other activity
> demanding our attention. May I suggest that we try to get as many proposed
> edits onto the list before our November 14 call (with much thanks to those
> who have already done so), with the goal of dealing with them then if
> possible, but leaving the door open for further edits over the next couple
> of weeks if necessary.
>
>
>
> Finally, some ICANN groups are adjusting the scheduling of their calls to
> reflect the return to standard time in North America and Europe. Is this
> group doing so as well? If our calls stay at 1400 UTC that is now 9 am EST
> and 6 am for those on Pacific time. Moving to 1500 UTC would retain the
> pre-existing local start times, I believe.
>
>
>
> Steve Metalitz
>
>
>
> *Steven J. Metalitz *| *Partner, through his professional corporation*
>
> T: 202.355.7902 <(202)%20355-7902> | met at msk.com
>
> *Mitchell Silberberg & Knupp* *LLP* | *www.msk.com*[msk.com]
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.msk.com_&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=8K75qGdDlOta4kh6k2F0jrT195M3tF3J_Fxcz6EvuG2kYKDeA67ZTEnthHXAPVXH&m=TjlmETQzu_l-1XrQJX8JzXMwXmo1RvgLFey6ZVbBgek&s=8MX5PFJVxEz3iLo0XKUPMHlLAtZUzvUD5Us9VmG5doY&e=>
>
> 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-bounces at icann.org [mailto:gdd-gnso-ppsai-impl-
> bounces at icann.org <gdd-gnso-ppsai-impl-bounces at icann.org>] *On Behalf Of *Victoria
> Sheckler
> *Sent:* Tuesday, October 31, 2017 5:55 PM
> *To:* gdd-gnso-ppsai-impl at icann.org; Sara Bockey
> *Subject:* Re: [Gdd-gnso-ppsai-impl] Materials, action items from 17 Oct
> Privacy/Proxy IRT call
>
>
>
> Please note that ICANN’s work on GDPR’s on a separate track and that one
> thing we know almost for sure is that the adoption of rational, predictable
> rules for privacy/proxy will be more important post-GDPR than it ever was.
> So please let’s get those rules in place as expeditiously as possible.
>
>
>
>
>
> On 30-10-2017 11:32, Sara Bockey wrote:
>
> Caitlin,
>
>
>
> Thanks for the revised docs. A few items at first glance that need to be
> revised, as I believe they have been discussion/raised before. I will take
> a closer look and follow up with additional edits, but in the meantime…
>
>
>
>
>
> 1. Edit the definitions of Proxy Service and Privacy Service to match
> the definitions provided in the Final Report/2013 RAA
>
>
> 1. The definitions of Privacy Service and Proxy Service reflect those
> in the 2013 RAA.
> 2. In this context, the 2013 RAA also defines “Registered Name” as
> a domain name within the domain of a gTLD, about which a gTLD Registry
> Operator (or an Affiliate or subcontractor thereof engaged in providing
> Registry Services) maintains data in a Registry Database, arranges for such
> maintenance, or derives revenue from such maintenance, and “Registered Name
> Holder” is defined as the holder of a Registered Name.
> 3. It’s noted that ICANN staff has replace “Registered Name Holder”
> with “Customer” in many instances, but I question the logic in that since
> it is inconsistent with the RAA.
>
>
>
> 1. Edit Sections 3.5.3.3. thru 3.5.3.6 to take into consideration GDPR
> requirements regarding consent.
>
>
> 1. Consent must be explicitly given for each purpose and can be
> withdrawn at any time and not a requirement for registration or use of the
> service. Therefore, 3.5.3.3. – 3.5.3.6 (at a minimum) are not compatible
> and must be revise.
>
>
>
> 1. Edit section 3.12.2, as it still contains new language that has
> been added since the IRT agreement on language in August. The first
> sentence in its entirety should be removed.
>
>
> 1. The section should start with “Well founded…”
>
>
>
> Additionally, the following sections need revision or at a minimum further
> discuss by the IRT
>
>
>
> 1. Edit Section 3.14 to remove the language re no automation. This is
> not feasible. This language must be removed:
>
>
> 1. Provider shall not use high-volume, automated electronic processes
> (for example, processes that do not utilize human review) for sending
> Requests or responses to Requests to Requesters or Customers in performing
> any of the steps in the processes outlined in the Intellectual Property
> Disclosure Framework Specification.
>
>
>
> 1. Edit Section 3.15 – Labeling – to remove excessive language.
>
>
> 1. Provider shall ensure that each Registered Name for which Provider
> is providing the Services is clearly labeled as such in the Registration
> Data Directory Service, as specified in the Labeling Specification attached
> hereto, and shall otherwise comply with the requirements of the
> Labeling Specification attached hereto. This language is
> duplicative and not necessary. Let’s not add unnecessary words to this
> already long document. If there are doing to be extra works, perhaps
> mention complying with applicable local laws in light of GDPR.
>
>
>
>
>
> *sara bockey*
>
> *sr. policy manager | GoDaddy™*
>
> *sbockey at godaddy.com* <sbockey at 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-bounces at icann.org>
> <gdd-gnso-ppsai-impl-bounces at icann.org> on behalf of Caitlin Tubergen
> <caitlin.tubergen at icann.org> <caitlin.tubergen at icann.org>
> *Reply-To: *"gdd-gnso-ppsai-impl at icann.org"
> <gdd-gnso-ppsai-impl at icann.org> <gdd-gnso-ppsai-impl at icann.org>
> <gdd-gnso-ppsai-impl at icann.org>
> *Date: *Wednesday, October 25, 2017 at 4:44 AM
> *To: *"gdd-gnso-ppsai-impl at icann.org" <gdd-gnso-ppsai-impl at icann.org>
> <gdd-gnso-ppsai-impl at icann.org> <gdd-gnso-ppsai-impl at icann.org>
> *Subject: *[Gdd-gnso-ppsai-impl] Materials, action items from 17 Oct
> Privacy/Proxy IRT call
>
>
>
> Dear Colleagues,
>
>
>
> Thanks so much for your participation on today’s Privacy/Proxy IRT call.
> For those who could not attend, I encourage you to review the recording and
> materials on the wiki, https://community.icann.org/display/IRT/24+October+
> 2017[community.icann.org]
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_display_IRT_24-2BOctober-2B2017&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=8K75qGdDlOta4kh6k2F0jrT195M3tF3J_Fxcz6EvuG2kYKDeA67ZTEnthHXAPVXH&m=TjlmETQzu_l-1XrQJX8JzXMwXmo1RvgLFey6ZVbBgek&s=gQxzEu54Fj0EpwmILgL-hEJwERb3J7gxwrD-3E0wDtY&e=>
> .
>
>
>
> During the call, we discussed an overview of the changes to the draft
> PPAA.
>
>
>
> Please note that ICANN proposed a deadline of *Tuesday,* *14 November*
> for all comments, concerns, and edits to the draft PPAA. The changes from
> the last iteration, provided to the IRT in July, have been highlighted in
> the attached issues list. Please respond to the list if you would like to
> request a longer review period.
>
>
>
> During ICANN60, we will be presenting an overview of the P/P program’s
> status to the community. Attached, please find the slide deck for the
> presentation.
>
>
>
> To highlight a few notes from the IRT’s discussion this morning, we
> received feedback to:
>
>
>
> 1. Edit the definition of *Working Group in Section 1.43*, to specify
> that the Provider Stakeholder Group, if formed, shall only appoint the
> *provider* representatives of the Working Group, and the GNSO may
> appoint other members of the community.
>
>
>
> 1. Add back in the previously-deleted *Code of Conduct *language in *Section
> 3.5.1*.
>
>
>
>
>
> 1. Add back in the previously-deleted *review provision *in *Section 7
> of the Customer Data Accuracy Program Specification*.
>
>
>
> If you believe the above items do not reflect the intent of the Working
> Group’s recommendations, please reply to the list by *14 November 2017*.
>
>
>
> Thank you, and safe travels to those of you attending ICANN 60!
>
>
>
> Kind regards,
>
>
>
> *Caitlin Tubergen*
>
> Registrar Services and Engagement Senior Manager
>
> ICANN
>
> 12025 Waterfront Drive, Suite 300
>
> Los Angeles, CA 90094
>
> Office: +1 310 578 8666 <(310)%20578-8666>
>
> Mobile: +1 310 699 5326 <(310)%20699-5326>
>
> Email: caitlin.tubergen at 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
>
>
> _______________________________________________ Gdd-gnso-ppsai-impl
> mailing list Gdd-gnso-ppsai-impl at icann.org https://mm.icann.org/mailman/
> listinfo/gdd-gnso-ppsai-impl
>
>
>
>
>
>
>
> _______________________________________________
>
> Gdd-gnso-ppsai-impl mailing list
>
> Gdd-gnso-ppsai-impl at icann.org
>
> https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl
>
>
> _______________________________________________ Gdd-gnso-ppsai-impl
> mailing list Gdd-gnso-ppsai-impl at icann.org https://mm.icann.org/mailman/
> listinfo/gdd-gnso-ppsai-impl
>
>
>
>
> _______________________________________________
>
> Gdd-gnso-ppsai-impl mailing list
>
> Gdd-gnso-ppsai-impl at icann.org
>
> https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl
>
>
>
>
> _______________________________________________
> 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/20171212/b2f142c4/attachment-0001.html>
More information about the Gdd-gnso-ppsai-impl
mailing list