<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Griffin,<br>
      Quick question - if there is a bounceback indicating non-receipt
      where in fact it is really delayed receipt, how could and would
      that be processed by the sender?<br>
      Best,<br>
      Kathy<br>
      :<br>
    </div>
    <blockquote
      cite="mid:4D8B2E10F0AD47418B4E95663595C440182728E8@EXBE-10.hs.local"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <style type="text/css" id="owaParaStyle"></style>
      <div style="direction: ltr;font-family: Times New Roman;color:
        #000000;font-size: 12pt;">
        <div style="direction: ltr; font-family: 'Times New Roman';
          font-size: 12pt;">
          <div>
            <div>
              <div>Volker and all,</div>
              <div><br>
              </div>
              <div>Just a few thoughts on this subject--</div>
              <div><br>
              </div>
              The re-verification process is supposed to take place
              within 15 days under the 2013 RAA&nbsp;(3.7.7.2), but assuming
              for whatever reason the P/P provider is not also the
              registrar for the domain name, it may take longer than
              that to notify the registrar and then re-verify the
              customer/registrant contact info (I suppose it might also
              take less time, depending on the process and the
              responsiveness of the customer). &nbsp;But potentially, it
              could take a fairly long time to re-verif<font>y.&nbsp;</font>&nbsp;<font>During
                this time,</font>&nbsp;the original complainant who has
              submitted a communication to be relayed to the P/P
              customer would simply not&nbsp;<font>know&nbsp;</font>whether its
              communication was (a) received by the P/P provider itself
              (although that part would probably be presumed) or (b)
              forwarded successfully (i.e. without an "undeliverable"
              notice) to the P/P customer. &nbsp;</div>
            <div><br>
            </div>
            <div>Informing&nbsp;the complainant&nbsp;of&nbsp;a bounce-back&nbsp;would&nbsp;be a
              simple mechanism for preventing redundant follow-up
              submissions by the same complainant trying to reach the
              same customer. &nbsp;In other words, if the P/P provider
              informed the complainant&nbsp;of abounce-back (perhaps in
              conjunction with initiating its own next step in the
              required re-verification process), this would&nbsp;preventthe
              complainant from sending, and the P/P provider from
              receiving, unnecessary/futile follow-ups in the
              intervening re-verification period. &nbsp;</div>
            <div><br>
            </div>
            <div>Then, once re-verified, the P/P provider could just
              relay the single original communication.
              &nbsp;Overall,&nbsp;it&nbsp;would seem to me&nbsp;thatone&nbsp;simple&nbsp;notice&nbsp;back
              to the complainant (and again, only in the event where the
              relay is unsuccessful and the P/P provider receives a
              bounce-back email associated with that attempt), would
              save time and headache for&nbsp;both complainants and
              P/Pproviders.&nbsp;</div>
            <div><br>
            </div>
            <div>In the non-proxy context, a complainant would directly
              receive the bounce-back notification; I see no reason why
              a complainant should not be equally informed when there is
              a proxy intermediary.
              <div><br>
              </div>
              <div>Just my two cents on this issue, and look forward to
                further discussion on the subject. &nbsp;Enjoy the weekend!</div>
              <div style="color: rgb(0, 0, 0);"><br>
              </div>
              <div style="color: rgb(0, 0, 0);">-Griffin</div>
            </div>
          </div>
          <div style="color: rgb(0, 0, 0);"><br>
          </div>
          <div style="color: rgb(0, 0, 0);"><br>
          </div>
        </div>
        <div>
          <div style="font-family:Tahoma; font-size:13px">Griffin M.
            Barnett
            <div>Silverberg, Goldman &amp; Bikoff, LLP</div>
            <div>1101 30th Street NW</div>
            <div>Suite 120</div>
            <div>Washington, DC 20007</div>
            <div>(202) 944-3307</div>
            <div><a moz-do-not-send="true" href="gbarnett@sgbdc.com">gbarnett@sgbdc.com</a>&nbsp;</div>
          </div>
        </div>
      </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>
  </body>
</html>