[Gnso-ppsai-pdp-wg] For review - updated templates Cat B, questions 1 and 2

Tue Mar 4 20:16:37 UTC 2014

...when I say 'verified' I mean the result, not process. But then again my
argument has always been 'avoid going into the weeds here'.

Could not agree more with using definitions already established, like, for
example, in the RAA 2013.  That's all good for the guy who's already party
to the RAA....except in the case of p/p service provisioning we would be
remiss in making that assumption. The caution must be to write rules that
are standalone, even if referent on RAA 2013.

-Carlton

==============================
Carlton A Samuels
Mobile: 876-818-1799
*Strategy, Planning, Governance, Assessment & Turnaround*
=============================

On Tue, Mar 4, 2014 at 3:00 PM, Volker Greimann
<vgreimann at key-systems.net>wrote:

>  Actually, the objective is validate some data points and verify one of
> two others. These terms have been defined in the RAA and to avoid confusion
> we should adopt those here. It makes no sense to re-define either term
> here, resulting in different definition across policies and agreements.
> Consistency should be an aim here as well...
>
> Volker
>
> Am 04.03.2014 19:37, schrieb Carlton Samuels:
>
>  ..the objective is 'verified' contact datum/data.  Make the rule for the
> general case; we need not be prescriptive here.
>
>  We know the RAA 2013 requirements.
>
>  So in instant case, I'd define 'verified'. Then I'd avoid all of that
> predetermination - that 'messiness' for determining whether the p/p
> provider is registrar or not you'd import into this interface and, what
> should apply in each case -  simply by making the requirement one for
> 'verified' contact data.
>
>  -Carlton
>
>
> ==============================
> Carlton A Samuels
> Mobile: 876-818-1799
> *Strategy, Planning, Governance, Assessment & Turnaround*
> =============================
>
>
> On Tue, Mar 4, 2014 at 3:18 AM, Luc SEUFER <lseufer at dclgroup.eu> wrote:
>
>> So the reasonable option would be to only compel the p/p provider to
>> verify those details in cases this party has not already verified them in
>> its capacity as registrar?
>>
>> Whereas we don't have a re-verification but two separate ones that can be
>> merged to avoid redundancy.
>>
>> Any opposition to that?
>>
>> Luc
>>
>>
>>
>>
>> On Mar 4, 2014, at 5:47, Holly Raiche <h.raiche at internode.on.net<mailto:
>> h.raiche at internode.on.net>> wrote:
>>
>> I have to agree with Steve on this.  People should not have access to a
>> domain name without someone verifying their details - regardless of whether
>> those details are made public or not.
>>
>> Holly
>> On 04/03/2014, at 5:51 AM, Metalitz, Steven wrote:
>>
>> Thanks Volker.  It is precisely because "the registrars obligation only
>> extends to the registrant of record, not to anyone who may use the domain
>> name with permission of that registrant," that there should be an
>> independent obligation on the part of the p/p service provider to validate
>> its customer's contact information.
>>
>> Steve.
>>
>>
>> From: Volker Greimann [mailto:vgreimann at key-systems.net]
>> Sent: Monday, March 03, 2014 5:32 AM
>>  To: Metalitz, Steven; gnso-ppsai-pdp-wg at icann.org<mailto:
>> gnso-ppsai-pdp-wg at icann.org>
>> Subject: Re: [Gnso-ppsai-pdp-wg] For review - updated templates Cat B,
>> questions 1 and 2
>>
>> Hi Steven,
>>
>> Even when this assertion is relevant, it may not be persuasive, for a
>> number of reasons.  For example, the Whois data reminder obligation applies
>> to the registrant of record.  In the case of a proxy service, the
>> registrant or record is the service, not its customer.  If a Whois data
>> reminder is sent to a non-proxy registrant and bounces back, then the RAA
>> requires the registrar to re-verify.  But a data reminder sent to a proxy
>> service will almost never bounce back, and therefore there may be no RAA
>> obligation to re-verify.   This is so even if the customer data provided to
>> the service is inaccurate or outdated.   In this circumstance it is up to
>> the p/p service accreditation standards to specify the conditions under
>> which customer data must be re-verified.
>>
>> This depends on how the service is set up. One could suggest that if such
>> required messages from the registrar do not reach the registrant, it could
>> become the providers' obligation to perform the information requirements on
>> its own. The registrar could then rely on the provider to perform its
>> duties under the accreditation agreement with ICANN just at it performs its
>> own obligations under the RAA.
>>
>> Please also remember that the registrars obligation only extends to the
>> registrant of record, not to anyone who may use the domain name with
>> permission of that registrant.
>>
>> V.
>> _______________________________________________
>> 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 listGnso-ppsai-pdp-wg at icann.orghttps://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg
>
>
> --
> Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
>
> Mit freundlichen Grüßen,
>
> Volker A. Greimann
> - Rechtsabteilung -
>
> Key-Systems GmbH
> Im Oberen Werk 1
> 66386 St. Ingbert
> Tel.: +49 (0) 6894 - 9396 901
> Fax.: +49 (0) 6894 - 9396 851
> Email: vgreimann at key-systems.net
>
> Web: www.key-systems.net / www.RRPproxy.netwww.domaindiscount24.com / www.BrandShelter.com
>
> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:www.facebook.com/KeySystemswww.twitter.com/key_systems
>
> Geschäftsführer: Alexander Siffrin
> Handelsregister Nr.: HR B 18835 - Saarbruecken
> Umsatzsteuer ID.: DE211006534
>
> Member of the KEYDRIVE GROUPwww.keydrive.lu
>
> Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
>
> --------------------------------------------
>
> Should you have any further questions, please do not hesitate to contact us.
>
> Best regards,
>
> Volker A. Greimann
> - legal department -
>
> Key-Systems GmbH
> Im Oberen Werk 1
> 66386 St. Ingbert
> Tel.: +49 (0) 6894 - 9396 901
> Fax.: +49 (0) 6894 - 9396 851
> Email: vgreimann at key-systems.net
>
> Web: www.key-systems.net / www.RRPproxy.netwww.domaindiscount24.com / www.BrandShelter.com
>
> Follow us on Twitter or join our fan community on Facebook and stay updated:www.facebook.com/KeySystemswww.twitter.com/key_systems
>
> CEO: Alexander Siffrin
> Registration No.: HR B 18835 - Saarbruecken
> V.A.T. ID.: DE211006534
>
> Member of the KEYDRIVE GROUPwww.keydrive.lu
>
> This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
>
>
>
>
>
> _______________________________________________
> 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/20140304/a6bbbe9a/attachment.html>