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

Wed Mar 19 00:00:17 UTC 2014

>
>  Just look at the whois of some of the domains you have reported in the
> past, I am sure that you will notice that in most cases, the registrant
> details are 100% accurate, just not those of the actual registrant.

Actually, I wouldn't agree with that based on the data in our database.
That might be true (I don't know) for domain names we've reported to a
particular registrar, and it certainly may happen, but I wouldn't agree
with that across all registrars. It's certainly the case with some
registrations, but definitely not all, and I actually don't think most, in
fact. Offhand, I'd say that we see way more completely falsified Whois
registrations (the Whois data isn't stolen; it's just falsified -- no such
address, etc.) than stolen Whois information.

John Horton
President, LegitScript

*Follow LegitScript*:
LinkedIn<http://www.linkedin.com/company/legitscript-com>
|  Facebook <https://www.facebook.com/LegitScript>  |
Twitter<https://twitter.com/legitscript>
|  YouTube <https://www.youtube.com/user/LegitScript>  |  *Blog
<http://blog.legitscript.com>*  |
Google+<https://plus.google.com/112436813474708014933/posts>

On Tue, Mar 18, 2014 at 3:01 AM, Volker Greimann
<vgreimann at key-systems.net>wrote:

>  As you know, accurate whois for abusive domain names equals stolen whois
> data. Just look at the whois of some of the domains you have reported in
> the past, I am sure that you will notice that in most cases, the registrant
> details are 100% accurate, just not those of the actual registrant.
>
> If you want to promote identity theft further, this is the ticket...
>
> Volker
>
>
> Am 17.03.2014 22:19, schrieb John Horton:
>
>  We also concur with those points.
>
>  John Horton
> President, LegitScript
>
>
>
>  *Follow LegitScript*: LinkedIn<http://www.linkedin.com/company/legitscript-com>
> |  Facebook <https://www.facebook.com/LegitScript>  |  Twitter<https://twitter.com/legitscript>
> |  YouTube <https://www.youtube.com/user/LegitScript>  |  *Blog
> <http://blog.legitscript.com>*  |  Google+<https://plus.google.com/112436813474708014933/posts>
>
>
> On Mon, Mar 17, 2014 at 1:17 PM, GBarnett at sgbdc.com <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 <%28202%29%20944-3307>
>>
>> gbarnett at sgbdc.com
>>
>>
>>
>>
>>
>>
>>
>> *From:* 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
>>
>> *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 <vsherman at law.gwu.edu>
>>     ------------------------------
>>
>> *From:* gnso-ppsai-pdp-wg-bounces at icann.org [
>> gnso-ppsai-pdp-wg-bounces at icann.org] on behalf of Metalitz, Steven [
>> met at msk.com]
>> *Sent:* Monday, March 17, 2014 6:13 AM
>> *To:* 'Williams, Todd'; Marika Konings; 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<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
>> *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<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
>> *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
>> https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg
>>
>
>
>
> _______________________________________________
> Gnso-ppsai-pdp-wg mailing listGnso-ppsai-pdp-wg at icann.orghttps://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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-ppsai-pdp-wg/attachments/20140318/68a78675/attachment-0001.html>