[Gnso-ppsai-pdp-wg] For your review - updated template Cat B- question 2

Tue Mar 18 12:39:38 UTC 2014

+1

Osvaldo

> El 18/03/2014, a las 07:54, "Theo Geurts" <theo.geurts at firstfind.nl> escribió:
>
> Agreed, good solution/answer.
>
> Theo Geurts
>
> Realtime Register B.V.
>
> Ceintuurbaan 32A
> 8024 AA - ZWOLLE - The Netherlands
>
> T: +31.384530759
> F: +31.384524734
> U: www.realtimeregister.com
> E: support at realtimeregister.com
>
> ----- Oorspronkelijk bericht -----
> Van: "Luc SEUFER" <lseufer at dclgroup.eu>
> Aan: "Volker Greimann" <vgreimann at key-systems.net>
> Cc: gnso-ppsai-pdp-wg at icann.org
> Verzonden: Dinsdag 18 maart 2014 12:25:13
> Onderwerp: Re: [Gnso-ppsai-pdp-wg] For your review -    updated template        Cat     B-      question 2
>
> This is a sound solution which I and all members of EuroDNS legal department agree with.
>
> Luc
>
>
> On Mar 18, 2014, at 11:33, Volker Greimann <vgreimann at key-systems.net<mailto:vgreimann at key-systems.net>> wrote:
>
> Draft Preliminary Recommendation – Category B – question 2 (Should ICANN-accredited privacy/proxy service providers be required to conduct periodic checks to ensure accuracy of customer contact information; and if so, how?)
>
> Answer:
> ICANN-accredited privacy/proxy service providers should be required to conduct checks and provide data reminder notices that correspond exactly to those periodic checks and notices required of ICANN accredited registrars under the RRA governing the registration. This obligation does not apply for registrations where the privacy/proxy service is set up in such a manner that the periodic checks performed by and data reminder notices provided by the ICANN accredited registrar reach the beneficial owner and contain the underlying data.
>
> This would be in my view the most balanced and sensible approach.
>
> VG
>
> Am 17.03.2014 22:23, schrieb Tim Ruiz:
> I agree with the draft recommendation as written by Marika. Going beyond what the 2013 RAA requires makes no sense since even that has no track record as of yet to know if it can be correctly done and actually accomplishes its goal. As the RAA requirements change/increase it would make sense for that to flow through to the p/p services as well.
>
> So, given the split on this issue, we may need to take a head count so we can note both views and the amount of agreement each one carries, and by which stakeholders.
>
> Tim
>
>
> On Mar 17, 2014, at 4:18 PM, "GBarnett at sgbdc.com<mailto:GBarnett at sgbdc.com>" <GBarnett at sgbdc.com<mailto:GBarnett at sgbdc.com>> wrote:
>
> As Val mentioned, I agree with Todd’s and Steve’s points, and those noted in Val’s email.
>
> Griffin
>
> Griffin M. Barnett
> Silverberg, Goldman & Bikoff, LLP
> 1101 30th Street NW
> Suite 120
> Washington, DC 20007
> (202) 944-3307
> gbarnett at sgbdc.com
>
>
>
> From: gnso-ppsai-pdp-wg-bounces at icann.org<mailto:gnso-ppsai-pdp-wg-bounces at icann.org> [mailto:gnso-ppsai-pdp-wg-bounces at icann.org] On Behalf Of Valeriya Sherman
> Sent: Monday, March 17, 2014 4:09 PM
> To: Metalitz, Steven; 'Williams, Todd'; Marika Konings; gnso-ppsai-pdp-wg at icann.org<mailto:gnso-ppsai-pdp-wg at icann.org>
> Subject: Re: [Gnso-ppsai-pdp-wg] For your review - updated template Cat B - question 2
>
> I, Jim Bikoff, David Heasley, and Griffin Barnett agree with Todd's assessment:
>
> Contact information that is ultimately revealed is valuable only if it is accurate.
>
> The validation/verification requirements should be consistent with the 2013 RAA requirements, but should go above and beyond those requirements to ensure the accuracy of contact information.
>
> Registrars already send an annual Whois Data Reminder Policy notification to registrants, reminding them to provide accurate and up-to-date information.
>
> Similarly, the privacy/proxy customer's contact information should be verified upon initial registration of the domain name (either by the registrar or the Privacy/Proxy Service Provider) and periodically thereafter by automated annual email re-verification notifications that require an affirmative response by the P/P customer.  Absence of a response would trigger a follow-up, reminding the privacy/proxy customer to provide accurate and up-to-date information.
>
> Regards,
>
> Valeriya Sherman
> Silverberg, Goldman & Bikoff, L.L.P.
> 1101 30th Street, N.W.
> Suite 120
> Washington, D.C. 20007
> Tel 202.944.2330
> Cell 303.589.7477
> vsherman at sgbdc.com<mailto:vsherman at law.gwu.edu>
> ________________________________
> From: gnso-ppsai-pdp-wg-bounces at icann.org<mailto:gnso-ppsai-pdp-wg-bounces at icann.org> [gnso-ppsai-pdp-wg-bounces at icann.org<mailto:gnso-ppsai-pdp-wg-bounces at icann.org>] on behalf of Metalitz, Steven [met at msk.com<mailto:met at msk.com>]
> Sent: Monday, March 17, 2014 6:13 AM
> To: 'Williams, Todd'; Marika Konings; gnso-ppsai-pdp-wg at icann.org<mailto:gnso-ppsai-pdp-wg at icann.org>
> Subject: Re: [Gnso-ppsai-pdp-wg] For your review - updated template Cat B - question 2
> I agree with Todd’s characterization of the status of this discussion, and that the questions he highlights are still open.
>
> Another aspect of the second question below is how the p/p service provider should handle situations in which the contact information supplied by the customer cannot be verified. In the parallel situation involving non-proxy registrations, the RAA specification calls either for suspension of the registration, or “manual verification,” which is not defined. How should this apply in the p/p service scenario?
>
> Steve Metalitz
>
> From: gnso-ppsai-pdp-wg-bounces at icann.org<mailto:gnso-ppsai-pdp-wg-bounces at icann.org> [mailto:gnso-ppsai-pdp-wg-bounces at icann.org] On Behalf Of Williams, Todd
> Sent: Friday, March 14, 2014 4:53 PM
> To: Marika Konings; gnso-ppsai-pdp-wg at icann.org<mailto:gnso-ppsai-pdp-wg at icann.org>
> Subject: Re: [Gnso-ppsai-pdp-wg] For your review - updated template Cat B - question 2
>
> Thanks Marika.  I missed part of the call on Tuesday where this may have been discussed, but I don’t see how the draft preliminary recommendation follows from the attached Word document, insofar as it concludes that p/p customer data should be validated and verified in a manner consistent with the requirements outlined in the 2013 RAA.  I thought the current posture was that the WG has basically agreed to the 2013 RAA requirements as a floor, but that there was not yet agreement on: 1) whether validation/verification requirements should go beyond the 2013 RAA; and 2) if so, how.
>
> On the first question (2013 RAA vs. “more”), it appears that more of the responses in the attached argue for “more” than not.  That also seems to have been an open topic in our email threads (see attached).  Just to reiterate from that thread, the basic argument on the “more” side (which I agree with) is that in order to partially offset the delay that will inevitably occur when accessing p/p data, the “more” should consist of whatever reasonable validation/verification steps can be taken to increase the likelihood  that the information ultimately obtained will be accurate enough to facilitate contact.  I suppose that if we ultimately settle on a “reveal” procedure that is essentially instantaneous in certain cases (once we get to discussing “reveal” procedures), that may mitigate this concern.  But absent assurances on that point, I would think we need to address it.
>
> On the second question: the attached appears to include multiple proposals as to what may or may not ultimately comprise the “more” (e.g., email and phone vs. or; periodic/annual re-verification vs. re-verification with information suggesting the contact information is incorrect; etc.).  Have we debated the relative merits of those?  Are some more likely to be effective than others?  I have my thoughts, but I’m curious to hear what everybody else thinks.
>
> Thanks all.
>
> Todd.
>
> From: gnso-ppsai-pdp-wg-bounces at icann.org<mailto:gnso-ppsai-pdp-wg-bounces at icann.org> [mailto:gnso-ppsai-pdp-wg-bounces at icann.org] On Behalf Of Marika Konings
> Sent: Thursday, March 13, 2014 7:04 AM
> To: gnso-ppsai-pdp-wg at icann.org<mailto:gnso-ppsai-pdp-wg at icann.org>
> Subject: [Gnso-ppsai-pdp-wg] For your review - updated template Cat B - question 2
>
> Dear All,
>
> Following our call earlier this week, please find attached the updated template for Category B – question 2. To facilitate your review, I've posted below the draft preliminary recommendation in which we've aimed to capture the conversation to date taking into account the language of the Whois Accuracy Specification Program of the 2013 RAA. If you are of the view that this does not accurately capture the WG's view to date and/or have specific suggestions for changes / edits, please share those with the mailing list. Also, if there are any other issues that need to be addressed in relation to this question and/or the preliminary recommendation, please share those as well.
>
> Best regards,
>
> Marika
>
> Draft Preliminary Recommendation – Category B – question 2 (Should ICANN-accredited privacy/proxy service providers be required to conduct periodic checks to ensure accuracy of customer contact information; and if so, how?)
>
> The WG recommends that proxy and privacy customer data be validated and verified in a manner consistent with the requirements outlined in Whois Accuracy Specification Program of the 2013 RAA. The WG furthermore agrees that in the cases where validation and verification of the P/P customer data was carried out by the registrar, reverification by the P/P service of the same, identical, information should not be required.
>
> Similar to ICANN’s Whois Data Reminder Policy (http://www.icann.org/en/resources/registrars/consensus-policies/wdrp), the P/P provider should be required to inform the P/P customer annually of his/her requirement to provide accurate and up to date contact information to the P/P provider. If the P/P provider has any information suggesting that the P/P customer information is incorrect (such as P/P service receiving a bounced email notification or non-delivery notification message in connection with compliance with data reminder notices or otherwise) for any P/P customer, the P/P provider must verify or re-verify, as applicable, the email address(es). If, within fifteen (15) calendar days after receiving any such information, P/P service does not receive an affirmative response from the P/P customer providing the required verification, the P/P service shall verify the applicable contact information manually.
> _______________________________________________
> Gnso-ppsai-pdp-wg mailing list
> Gnso-ppsai-pdp-wg at icann.org<mailto:Gnso-ppsai-pdp-wg at icann.org>
> https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg
>
>
>
> _______________________________________________
> Gnso-ppsai-pdp-wg mailing list
> Gnso-ppsai-pdp-wg at icann.org<mailto:Gnso-ppsai-pdp-wg at icann.org>
> https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg
>
> _______________________________________________
> Gnso-ppsai-pdp-wg mailing list
> Gnso-ppsai-pdp-wg at icann.org<mailto:Gnso-ppsai-pdp-wg at icann.org>
> https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg
>
>
> ________________________________
>
> --------------------------------------------------------
>
> This e-mail and any attached files are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail by mistake, please notify the sender immediately and delete it from your system. You must not copy the message or disclose its contents to anyone.
>
> Think of the environment: don't print this e-mail unless you really need to.
>
> --------------------------------------------------------
> _______________________________________________
> Gnso-ppsai-pdp-wg mailing list
> Gnso-ppsai-pdp-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg
> _______________________________________________
> Gnso-ppsai-pdp-wg mailing list
> Gnso-ppsai-pdp-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg

El presente correo y cualquier posible archivo adjunto está dirigido únicamente al destinatario del mensaje y contiene información que puede ser confidencial. Si Ud. no es el destinatario correcto por favor notifique al remitente respondiendo anexando este mensaje y elimine inmediatamente el e-mail y los posibles archivos adjuntos al mismo de su sistema. Está prohibida cualquier utilización, difusión o copia de este e-mail por cualquier persona o entidad que no sean las específicas destinatarias del mensaje. ANTEL no acepta ninguna responsabilidad con respecto a cualquier comunicación que haya sido emitida incumpliendo nuestra Política de Seguridad de la Información

This e-mail and any attachment is confidential and is intended solely for the addressee(s). If you are not intended recipient please inform the sender immediately, answering this e-mail and delete it as well as the attached files. Any use, circulation or copy of this e-mail by any person or entity that is not the specific addressee(s) is prohibited. ANTEL is not responsible for any communication emitted without respecting our Information Security Policy.