<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">hi Volker,<div><br></div><div>i'm trying to remedy the situation where a registrar is either in violation of the IRTP themselves (refusing to allow the registrant to transfer out) or is presumptively denying the registrant due process in a dispute between registrars. &nbsp;this was recognized as an oversight in the policy back in the misty past when this series of IRTP PDPs was launched.</div><div><br></div><div>i don't care how this happens. &nbsp;registrars are probably in the best position to figure out the best way to get this done and i'm happy to leave that discussion up to them. &nbsp;i like James' "put pressure on Registrars to comply" approach since that seems like a lighter/simpler one but i can live with anything that fixes that problem. &nbsp;what i'm not keen on the idea of leaving registrants in their current situation where these decisions get made "for them" by registrars with no recourse for trapped registrants except worldwide courts.</div><div><br></div><div><br><div><div>On Dec 3, 2013, at 9:51 AM, Volker Greimann &lt;<a href="mailto:vgreimann@key-systems.net">vgreimann@key-systems.net</a>&gt; wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">

    <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">

  <div text="#000000" bgcolor="#FFFFFF">

    <div class="moz-cite-prefix">Hi Mike,<br>

      <br>

      you are assuming that registrants should be beneficiaries of the

      TDRP. They are not. Therefore a registrar not initiating a TDRP is

      not blocking the registrants access as they do not have such an

      access in the first place. <br>

      <br>

      If you want to give the registrant a way to force a registrar to

      initiate a proceeding against another registrar, that is another

      story, but that way needs to include an obligation of the

      registrant to pay the costs and a right of a registrar to charge

      for this service (to cover the work needed to handle the process).<br>

      <br>

      Volker<br>

      <br>

      <br>

    </div>

    <blockquote cite="mid:45A99A3C-7282-4C55-9FE6-55CD27BB5F0E@haven2.com" type="cite">

      <meta http-equiv="Content-Type" content="text/html;

        charset=ISO-8859-1">

      i think the key distinction i want to draw is with your sentence

      "give registrants access to" the TDRP. &nbsp;that's not the intent.

      &nbsp;the intent is to ensure that registrants are not blocked from

      that process by their registrar. &nbsp;the hope here is to provide an

      appeal mechanism in those cases where registrar and registrant

      disagree on whether a TDRP is warranted. &nbsp;but i'm fine setting the

      bar for that appeal pretty high.

      <div><br>

      </div>

      <div><br>

        <div>

          <div>On Dec 2, 2013, at 11:47 AM, Volker Greimann &lt;<a moz-do-not-send="true" href="mailto:vgreimann@key-systems.net">vgreimann@key-systems.net</a>&gt;

            wrote:</div>

          <br class="Apple-interchange-newline">

          <blockquote type="cite">

            <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">

            <div text="#000000" bgcolor="#FFFFFF">

              <div class="moz-cite-prefix">I still feel that giving

                registrants access to the TDRP process dilutes its

                purpose as an inter-registrar dispute process designed

                to deal with process violations and will turn it into a

                transfer dispute process between registrants, dragging

                registrars and registries into a civil conflict between

                two parties. This will result in increased costs and

                work for contracted parties.<br>

                <br>

                If a registrar is violating transfer processes, there

                will be sufficient incentive for affected registrars to

                call them out and if necessary invoke the current

                process.<br>

                <br>

                What we need to look at instead is if creating an

                alternate process between registrant and former

                registrant regarding the ownership of a domain name

                makes sense. <br>

                <br>

                I am also a big fan of the line "He who wants to hear

                the music should pay for the band!", i.e. if a

                registrant wants a process to be invoked, he should be

                prepared to pony up the fees, just as with the UDRP.

                Adding a "loser pays" clause makes sense to me, but in

                that case it will remain the risk of the complainant

                that the respondent cannot pay/is unreachable/etc...<br>

                <br>

                Volker<br>

              </div>

              <blockquote cite="mid:60AF9317-EEBB-4BE5-A4BB-2B8040A754E5@haven2.com" type="cite">

                <meta http-equiv="Content-Type" content="text/html;

                  charset=ISO-8859-1">

                <br>

                <div apple-content-edited="true">

                  <!-- ^ Position is not set to relative / absolute here because of Mozilla --><p>Provide the ability for the registrant to trigger

                    the TDRP process in cases when they disagree with

                    their registrar over an IRTP issue </p>

                  <ul>

                    <li><p>In general, registrars initiate TDRP when they

                        can't resolve matters between themselves </p><p>In the case of disagreement between registrar

                        and registrant as to whether to initiate a TDRP,

                        provide a path for the registrant to take the

                        issue to Compliance </p><p>Build minimum documentation requirements for

                        registrants into the policy as a filter to

                        prevent frivolous filings </p><p>If Compliance agrees with registrant, TDRP

                        proceeds as normal, with fees paid by

                        registrars, as normal </p><p>If Compliance disagrees with registrant, that's

                        it -- it's off to court if the registrant wants

                        to proceed.</p><p><br>

                      </p>

                      <div>&nbsp;<br class="webkit-block-placeholder">

                      </div>

                    </li>

                  </ul>

                  <span style="font-family: Helvetica; font-size: 12px;

                    font-style: normal; font-variant: normal;

                    font-weight: normal; letter-spacing: normal;

                    line-height: normal; orphans: 2; text-align:

                    -webkit-auto; text-indent: 0px; text-transform:

                    none; white-space: normal; widows: 2; word-spacing:

                    0px; -webkit-text-size-adjust: auto;

                    -webkit-text-stroke-width: 0px; display: inline

                    !important; float: none; ">PHONE: 651-647-6109, FAX:

                    866-280-2356, WEB: <a moz-do-not-send="true" href="http://www.haven2.com/">www.haven2.com</a>,

                    HANDLE: OConnorStP (ID for Twitter, Facebook,

                    LinkedIn, etc.)</span> </div>

                <br>

              </blockquote>

              <br>

              <br>

              <pre class="moz-signature" cols="72">-- 

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: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:vgreimann@key-systems.net">vgreimann@key-systems.net</a>

Web: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.key-systems.net/">www.key-systems.net</a> / <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.rrpproxy.net/">www.RRPproxy.net</a>

<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.domaindiscount24.com/">www.domaindiscount24.com</a> / <a moz-do-not-send="true" 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 moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.facebook.com/KeySystems">www.facebook.com/KeySystems</a>

<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.twitter.com/key_systems">www.twitter.com/key_systems</a>

Gesch�ftsf�hrer: Alexander Siffrin

Handelsregister Nr.: HR B 18835 - Saarbruecken 

Umsatzsteuer ID.: DE211006534

Member of the KEYDRIVE GROUP

<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.keydrive.lu/">www.keydrive.lu</a> 

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: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:vgreimann@key-systems.net">vgreimann@key-systems.net</a>

Web: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.key-systems.net/">www.key-systems.net</a> / <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.rrpproxy.net/">www.RRPproxy.net</a>

<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.domaindiscount24.com/">www.domaindiscount24.com</a> / <a moz-do-not-send="true" 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 moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.facebook.com/KeySystems">www.facebook.com/KeySystems</a>

<a moz-do-not-send="true" 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 moz-do-not-send="true" 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>

            </div>

          </blockquote>

        </div>

        <br>

        <div apple-content-edited="true">

          <br class="Apple-interchange-newline">

          <span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; display: inline !important; float: none; ">PHONE: 651-647-6109, FAX: 866-280-2356, WEB:

            <a moz-do-not-send="true" href="http://www.haven2.com/">www.haven2.com</a>,

            HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn,

            etc.)</span>

        </div>

        <br>

      </div>

    </blockquote>

    <br>

    <br>

    <pre class="moz-signature" cols="72">-- 