<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    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...<br>
    <br>
    Volker<br>
    <br>
    <div class="moz-cite-prefix">Am 04.03.2014 19:37, schrieb Carlton
      Samuels:<br>
    </div>
    <blockquote
cite="mid:CAOZQb9Rf8MwPUDzxPk-=mr+xmt=D6ykkHWXC1EL+iSnsif6LDQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_default" style="font-family:'comic sans
          ms',sans-serif;font-size:large">..the objective is 'verified'
          contact datum/data. &nbsp;Make the rule for the general case; we
          need not be prescriptive here.&nbsp;</div>
        <div class="gmail_default" style="font-family:'comic sans
          ms',sans-serif;font-size:large"><br>
        </div>
        <div class="gmail_default" style="font-family:'comic sans
          ms',sans-serif;font-size:large">We know the RAA 2013
          requirements.</div>
        <div class="gmail_default" style="font-family:'comic sans
          ms',sans-serif;font-size:large"><br>
        </div>
        <div class="gmail_default" style="font-family:'comic sans
          ms',sans-serif;font-size:large">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 - &nbsp;simply by making the requirement
          one for 'verified' contact data.&nbsp;</div>
        <div class="gmail_default" style="font-family:'comic sans
          ms',sans-serif;font-size:large"><br>
        </div>
        <div class="gmail_default" style="font-family:'comic sans
          ms',sans-serif;font-size:large">-Carlton</div>
      </div>
      <div class="gmail_extra"><br clear="all">
        <div><br>
          ==============================<br>
          Carlton A Samuels<br>
          Mobile: 876-818-1799<br>
          <i><font color="#33CC00">Strategy, Planning, Governance,
              Assessment &amp; Turnaround</font></i><br>
          =============================</div>
        <br>
        <br>
        <div class="gmail_quote">On Tue, Mar 4, 2014 at 3:18 AM, Luc
          SEUFER <span dir="ltr">&lt;<a moz-do-not-send="true"
              href="mailto:lseufer@dclgroup.eu" target="_blank">lseufer@dclgroup.eu</a>&gt;</span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            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?<br>
            <br>
            Whereas we don&#8217;t have a re-verification but two separate
            ones that can be merged to avoid redundancy.<br>
            <br>
            Any opposition to that?<br>
            <br>
            Luc<br>
            <div class=""><br>
              <br>
              <br>
              <br>
              On Mar 4, 2014, at 5:47, Holly Raiche &lt;<a
                moz-do-not-send="true"
                href="mailto:h.raiche@internode.on.net">h.raiche@internode.on.net</a>&lt;mailto:<a
                moz-do-not-send="true"
                href="mailto:h.raiche@internode.on.net">h.raiche@internode.on.net</a>&gt;&gt;
              wrote:<br>
              <br>
              I have to agree with Steve on this. &nbsp;People should not
              have access to a domain name without someone verifying
              their details - regardless of whether those details are
              made public or not.<br>
              <br>
              Holly<br>
              On 04/03/2014, at 5:51 AM, Metalitz, Steven wrote:<br>
              <br>
              Thanks Volker. &nbsp;It is precisely because &#8220;the registrars
              obligation only extends to the registrant of record, not
              to anyone who may use the domain name with permission of
              that registrant,&#8221; that there should be an independent
              obligation on the part of the p/p service provider to
              validate its customer&#8217;s contact information.<br>
              <br>
              Steve.<br>
              <br>
              <br>
              From: Volker Greimann [mailto:<a moz-do-not-send="true"
                href="mailto:vgreimann@key-systems.net">vgreimann@key-systems.net</a>]<br>
              Sent: Monday, March 03, 2014 5:32 AM<br>
            </div>
            To: Metalitz, Steven; <a moz-do-not-send="true"
              href="mailto:gnso-ppsai-pdp-wg@icann.org">gnso-ppsai-pdp-wg@icann.org</a>&lt;mailto:<a
              moz-do-not-send="true"
              href="mailto:gnso-ppsai-pdp-wg@icann.org">gnso-ppsai-pdp-wg@icann.org</a>&gt;<br>
            <div class="">Subject: Re: [Gnso-ppsai-pdp-wg] For review -
              updated templates Cat B, questions 1 and 2<br>
              <br>
              Hi Steven,<br>
              <br>
              Even when this assertion is relevant, it may not be
              persuasive, for a number of reasons. &nbsp;For example, the
              Whois data reminder obligation applies to the registrant
              of record. &nbsp;In the case of a proxy service, the registrant
              or record is the service, not its customer. &nbsp;If a Whois
              data reminder is sent to a non-proxy registrant and
              bounces back, then the RAA requires the registrar to
              re-verify. &nbsp;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. &nbsp; This is so even if the
              customer data provided to the service is inaccurate or
              outdated. &nbsp; 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.<br>
              <br>
              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.<br>
              <br>
              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.<br>
              <br>
              V.<br>
              _______________________________________________<br>
              Gnso-ppsai-pdp-wg mailing list<br>
            </div>
            <a moz-do-not-send="true"
              href="mailto:Gnso-ppsai-pdp-wg@icann.org">Gnso-ppsai-pdp-wg@icann.org</a>&lt;mailto:<a
              moz-do-not-send="true"
              href="mailto:Gnso-ppsai-pdp-wg@icann.org">Gnso-ppsai-pdp-wg@icann.org</a>&gt;<br>
            <a moz-do-not-send="true"
              href="https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg"
              target="_blank">https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg</a><br>
            <br>
            _______________________________________________<br>
            Gnso-ppsai-pdp-wg mailing list<br>
            <div class="im HOEnZb"><a moz-do-not-send="true"
                href="mailto:Gnso-ppsai-pdp-wg@icann.org">Gnso-ppsai-pdp-wg@icann.org</a>&lt;mailto:<a
                moz-do-not-send="true"
                href="mailto:Gnso-ppsai-pdp-wg@icann.org">Gnso-ppsai-pdp-wg@icann.org</a>&gt;<br>
              <a moz-do-not-send="true"
                href="https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg"
                target="_blank">https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg</a><br>
              <br>
              <br>
              ________________________________<br>
              <br>
              --------------------------------------------------------<br>
              <br>
              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.<br>
              <br>
              Think of the environment: don't print this e-mail unless
              you really need to.<br>
              <br>
              --------------------------------------------------------<br>
            </div>
            <div class="HOEnZb">
              <div class="h5">_______________________________________________<br>
                Gnso-ppsai-pdp-wg mailing list<br>
                <a moz-do-not-send="true"
                  href="mailto:Gnso-ppsai-pdp-wg@icann.org">Gnso-ppsai-pdp-wg@icann.org</a><br>
                <a moz-do-not-send="true"
                  href="https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg"
                  target="_blank">https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg</a><br>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Gnso-ppsai-pdp-wg mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Gnso-ppsai-pdp-wg@icann.org">Gnso-ppsai-pdp-wg@icann.org</a>
<a class="moz-txt-link-freetext" href="https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg">https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg</a></pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Bei weiteren Fragen stehen wir Ihnen gerne zur Verf&uuml;gung.

Mit freundlichen Gr&uuml;&szlig;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: <a class="moz-txt-link-abbreviated" href="mailto:vgreimann@key-systems.net">vgreimann@key-systems.net</a>

Web: <a class="moz-txt-link-abbreviated" href="http://www.key-systems.net">www.key-systems.net</a> / <a class="moz-txt-link-abbreviated" href="http://www.RRPproxy.net">www.RRPproxy.net</a>
<a class="moz-txt-link-abbreviated" href="http://www.domaindiscount24.com">www.domaindiscount24.com</a> / <a class="moz-txt-link-abbreviated" href="http://www.BrandShelter.com">www.BrandShelter.com</a>

Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
<a class="moz-txt-link-abbreviated" href="http://www.facebook.com/KeySystems">www.facebook.com/KeySystems</a>
<a class="moz-txt-link-abbreviated" href="http://www.twitter.com/key_systems">www.twitter.com/key_systems</a>

Gesch&auml;ftsf&uuml;hrer: Alexander Siffrin
Handelsregister Nr.: HR B 18835 - Saarbruecken 
Umsatzsteuer ID.: DE211006534

Member of the KEYDRIVE GROUP
<a class="moz-txt-link-abbreviated" href="http://www.keydrive.lu">www.keydrive.lu</a> 

Der Inhalt dieser Nachricht ist vertraulich und nur f&uuml;r den angegebenen Empf&auml;nger bestimmt. Jede Form der Kenntnisgabe, Ver&ouml;ffentlichung oder Weitergabe an Dritte durch den Empf&auml;nger ist unzul&auml;ssig. Sollte diese Nachricht nicht f&uuml;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: <a class="moz-txt-link-abbreviated" href="mailto:vgreimann@key-systems.net">vgreimann@key-systems.net</a>

Web: <a class="moz-txt-link-abbreviated" href="http://www.key-systems.net">www.key-systems.net</a> / <a class="moz-txt-link-abbreviated" href="http://www.RRPproxy.net">www.RRPproxy.net</a>
<a class="moz-txt-link-abbreviated" href="http://www.domaindiscount24.com">www.domaindiscount24.com</a> / <a class="moz-txt-link-abbreviated" href="http://www.BrandShelter.com">www.BrandShelter.com</a>

Follow us on Twitter or join our fan community on Facebook and stay updated:
<a class="moz-txt-link-abbreviated" href="http://www.facebook.com/KeySystems">www.facebook.com/KeySystems</a>
<a class="moz-txt-link-abbreviated" href="http://www.twitter.com/key_systems">www.twitter.com/key_systems</a>

CEO: Alexander Siffrin
Registration No.: HR B 18835 - Saarbruecken 
V.A.T. ID.: DE211006534

Member of the KEYDRIVE GROUP
<a class="moz-txt-link-abbreviated" href="http://www.keydrive.lu">www.keydrive.lu</a> 

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.



</pre>
  </body>
</html>