[Gdd-gnso-ppsai-impl] Action items, request for additional IRT input after 8 August IRT call

Tue Aug 15 13:09:14 UTC 2017

Hi Steve,

Thanks for flagging this. I'll explain my understanding of how this would work as written now, based on the pending changes that have been recommended by the IRT. However, I'll need to check with Legal to verify that the language we decide upon achieves the desired result.

Looking at the requirements for registrars, in the 2013 RAA's WHOIS Accuracy Specification<https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en#whois-accuracy>, Section 2, registrars are required, within 15 days of receiving any changes to contact information in WHOIS or the corresponding customer account info, to validate and verify the changed fields. So, at least in the case of a Proxy Service Provider-who is the Registered Name Holder-notifying the registrar that the PP service has been suspended and that the account information should be updated to the customer's information would seem to fall within this. And if the information cannot be validated or verified, then the registrar shall suspend the registration. So while this is not automatic-the customer could remedy its willful provision of inaccurate info by correcting it with the registrar-if the customer didn't correct the information, then suspension would be the next step. I think this may address the issue raised by Theo, as registrars are required to act when they receive changes. What do others think? Do you think some added step of verification is needed, as Theo asked?

In addition, the RAA's WHOIS accuracy program specification, at Section 4, requires the registrar to validate and verify if it has any information suggesting that the WHOIS information is incorrect. It would seem that a PP Provider's notice to the registrar in this instance would qualify as "any information suggesting that the contact information specified...is incorrect."

So, while the provider's notice to the registrar as outlined in the specification of the PPAA would not result in automatic suspension of the name, this could be the ultimate result if the issue is not addressed after it is escalated to the registrar.

You're right that the PPAA specification doesn't mention suspension/termination of the PP service itself-and we could certainly add that.

What do others think about this issue? Any additional input would be very helpful-I'll compile it and discuss with the Legal team and then tee this up for an upcoming call.

Thanks!
Amy

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, August 14, 2017 5:37 PM
To: gdd-gnso-ppsai-impl at icann.org
Subject: Re: [Gdd-gnso-ppsai-impl] Action items, request for additional IRT input after 8 August IRT call

IRT,

May I flag one issue that may not have been resolved with regard to the customer data accuracy specification discussed on last week's call:  how the spec lines up with section 3.5.4.1 of the draft agreement.

Section 3.5.4.1 of the accreditation agreement basically provides (or will provide, once it is updated to adjust time limits and catch the issue Vicky flagged a couple of weeks ago) that if a customer willfully provides false info or fails to respond to an accuracy query from the provider, then customer's p/p service is suspended or cancelled AND the registration is suspended or cancelled.

However, Spec 2  (Customer Data Accuracy Program), discussed last week, seems to set forth somewhat different consequences in similar scenarios.  Paragraphs 1, 2 and 4 state that if customer fails to verify contact information in various scenarios,  then "Provider shall either verify the applicable contact information manually" or ask the Registrar to suspend the registration. In para. 5, in basically the same situation described in section 3.5.4.1,  it states that provider should ask registrar either to "terminate" (is this the same as cancel?), suspend, or make the registration non-resolvable (clientHold and client Transfer Prohibited).  Neither provision in the Spec says anything about suspending or canceling the p/p service (i.e., kicking customer out of the program), although surely the provider should have the ability to do that as a violation of its terms of service.

I get it that for a third party provider (not affiliated with a registrar), asking the registrar to suspend/"terminate"/cancel etc. is all that can be done with regard to the registration (as contrasted with the p/p service).  But other than that I am puzzled by the somewhat differing obligations that apply in basically the same circumstances.  (Section 3.5.5 of the Agreement says providers must  comply with the Spec, but the Spec and 3.5.4.1 seem to require slightly different responses.)

Should this discrepancy be addressed?  I note that we are pending some revision of 3.5.4.1 anyway so perhaps it could be addressed there.

Apologies if this has already been resolved; if so could someone point me to the resolution?

Thanks!

[image001]
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<http://www.msk.com/>
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 Amy Bivins
Sent: Tuesday, August 08, 2017 12:39 PM
To: gdd-gnso-ppsai-impl at icann.org<mailto:gdd-gnso-ppsai-impl at icann.org>
Subject: [Gdd-gnso-ppsai-impl] Action items, request for additional IRT input after 8 August IRT call

Dear Colleagues,

Thanks so much for your active participation on today's IRT call. If you were unable to attend, I encourage you to listen to the recording, which is available on the wiki, https://community.icann.org/display/IRT/08+August+2017

Attached, you will find an updated "issues list" that includes a detailed summary of all the PPAA-related topics discussed to date, including those raised on the call today. A very short summary of the input received today and the significant outstanding questions is also available below. Please review the topics discussed today and submit any additional feedback you have no later than next Monday, 14 August. Your feedback is especially needed on the LEA Framework and Data Retention topics.

Proposed upcoming IRT discussion schedule:
15 August: PPAA definitions, PPAA amendment/negotiation process (updated per IRT feedback), RAA synchronization, request suggestions for future discussion topics
22 August: LEA framework, data retention, IP Framework, business dealings
29 August: Data escrow, labeling (new draft specification modeled on RAA requirements to be provided, per IRT feedback)

Summary of Discussion on Today's Call

  *   PPAA Issues 18-19: LEA Framework:
     *   Updates to definitions to conform with rest of PPAA: no further edits suggested by IRT
     *   Proposed edit to Section 3.2.1 from PSWG, editing the section as follows: [cid:image004.png at 01D315A6.29A01DB0]
        *   Summary of proposed edit: This would reduce the period required for a provider to initiate a review of a law enforcement request from 2 business days to 24 hours. However, this would also eliminate any requirement for the provider to respond to the LEA requester within 24 hours.
        *   PSWG rationale: This edit was made to align more closely with RAA requirement (See Section 3.18.2<https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en> RAA-"Well-founded reports of Illegal Activity submitted to these contacts must be reviewed within 24 hours by an individual who is empowered by Registrar to take necessary and appropriate actions in response to the report."
        *   Summary of IRT feedback thus far: Some IRT members said 24 hours is too short a period; possibly 1 business day would be preferable; Other IRT members supported edit and alignment with RAA. See issues list for detailed feedback.

  *   PPAA Issues 4, 23: Data Retention Requirements
     *   Summary of IRT Feedback: Proposed required data elements appear generally OK; retention period appears to create issues under global data protection laws notwithstanding proposed reduction from RAA's 2-year requirement to 1-year requirement proposed for PPAA
     *   Proposed solution raised by IRT member: Edit to require retention based on maximum period allowed under applicable law.
  *   PPAA Issue 12: Accreditation Agreement Term
     *   Summary of IRT Feedback: IRT members who commented supported the inclusion of a 5-year term for the contract, as is done for the RAA.
  *   Customer Data Accuracy Specification:
     *   Summary of IRT Feedback: Questions raised regarding how third-party providers would comply with these requirements.
     *   IRT is requested to comment further on this specification, specifically, if a third-party provider cannot comply with these requirements, how should this be handled in the contract?
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>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gdd-gnso-ppsai-impl/attachments/20170815/9491c4c5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 8273 bytes
Desc: image002.png
URL: <http://mm.icann.org/pipermail/gdd-gnso-ppsai-impl/attachments/20170815/9491c4c5/image002-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 115095 bytes
Desc: image004.png
URL: <http://mm.icann.org/pipermail/gdd-gnso-ppsai-impl/attachments/20170815/9491c4c5/image004-0001.png>