[Gdd-gnso-ppsai-impl] [Ext] Re: Materials, action items from 17 Oct Privacy/Proxy IRT call
theo geurts
gtheo at xs4all.nl
Mon Dec 11 19:52:54 UTC 2017
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
>
> Mobile: +1 310 699 5326
>
> Email: caitlin.tubergen at icann.org
>
> *From: *Sara Bockey <sbockey at godaddy.com>
> *Date: *Friday, December 1, 2017 at 10:09 AM
> *To: *Caitlin Tubergen <caitlin.tubergen 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>, Sara Bockey
> <sbockey at godaddy.com>, 'Darcy Southwell' <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 | **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: *Caitlin Tubergen <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>,
> Sara Bockey <sbockey at godaddy.com>, 'Darcy Southwell'
> <darcy.southwell at endurance.com>
> *Cc: *"Roman, Peter (CRM)" <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
>
> Mobile: +1 310 699 5326
>
> Email: caitlin.tubergen at icann.org
>
> *From: *Gdd-gnso-ppsai-impl <gdd-gnso-ppsai-impl-bounces at icann.org> on
> behalf of "Metalitz, Steven" <met at msk.com>
> *Reply-To: *"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>, 'Darcy Southwell'
> <darcy.southwell at endurance.com>, "'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
>
>
>
>
> *001*
>
> *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*[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
>
> *001*
>
> *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*[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]
> *Sent:* Tuesday, November 07, 2017 11:07 AM
> *To:* Darcy Southwell; gdd-gnso-ppsai-impl at icann.org
> <mailto: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 | **Go**Daddy^™ *
>
> *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: *Darcy Southwell <darcy.southwell at endurance.com
> <mailto:darcy.southwell at endurance.com>>
> *Date: *Tuesday, November 7, 2017 at 8:47 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>>, "Metalitz, Steven"
> <met at msk.com <mailto:met at msk.com>>, Sara Bockey <sbockey at godaddy.com
> <mailto: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
> <mailto:gdd-gnso-ppsai-impl-bounces at icann.org>> on behalf of theo
> geurts <gtheo at xs4all.nl <mailto:gtheo at xs4all.nl>>
> *Reply-To: *<gdd-gnso-ppsai-impl at icann.org
> <mailto:gdd-gnso-ppsai-impl at icann.org>>
> *Date: *Monday, November 6, 2017 at 12:27 PM
> *To: *<gdd-gnso-ppsai-impl at icann.org
> <mailto:gdd-gnso-ppsai-impl at icann.org>>, "Metalitz, Steven"
> <met at msk.com <mailto:met at msk.com>>, Sara Bockey <sbockey at godaddy.com
> <mailto: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
>
> *1*
>
> *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*[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>[mailto: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
> <mailto: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.
>
> 2. 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.
>
> 3. 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
>
> 4. 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.
>
> 5. 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* <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-bounces at icann.org>
> <mailto:gdd-gnso-ppsai-impl-bounces at icann.org>on behalf of
> Caitlin Tubergen <caitlin.tubergen at icann.org>
> <mailto:caitlin.tubergen 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: *Wednesday, October 25, 2017 at 4:44 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] 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.
>
> **
>
> 2. Add back in the previously-deleted *Code of Conduct
> *language in *Section 3.5.1*.
>
> **
>
> **
>
> 3. 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
>
> Mobile: +1 310 699 5326
>
> Email: caitlin.tubergen at icann.org
> <mailto:caitlin.tubergen at 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
>
>
> _______________________________________________
> 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
>
>
>
>
>
>
> _______________________________________________
>
> 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
>
>
> _______________________________________________ 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
>
>
>
> _______________________________________________
> 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/20171211/9aad1152/attachment-0001.html>
More information about the Gdd-gnso-ppsai-impl
mailing list