[gnso-irtpd] here's the little summary of that sequence of events i rattled off on the call just now -- registrant role in TDRP

[Holly Raiche]

I really agree with Mikey here.  The issue we are facing is when a registrar does not take action over an improper transfer of a domain name - to the detriment of the registrant.  What is being suggested here is to ensure that, when the registrant can establish an improper transfer that the relevant registrar must commence the TDRP action.  And as Mikey suggests, the filter (to be sure of the bona fides of the registrant's case) is a requirement for documentation that ICANN can rule on.  If there is a genuine case for the registrant, then the relevant registrar must initiate the TDRP.  It doesn't stop being anything other than an inter-registrar process.  It just ensures that the registrar cannot refuse to take action when a registrant's domain name has been wrongly transferred.

Holly
On 03/12/2013, at 6:33 AM, Mike O'Connor wrote:

> i think the key distinction i want to draw is with your sentence "give registrants access to" the TDRP.  that's not the intent.  the intent is to ensure that registrants are not blocked from that process by their registrar.  the hope here is to provide an appeal mechanism in those cases where registrar and registrant disagree on whether a TDRP is warranted.  but i'm fine setting the bar for that appeal pretty high.
> 
> 
> On Dec 2, 2013, at 11:47 AM, Volker Greimann <vgreimann at key-systems.net> wrote:
> 
>> 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.
>> 
>> 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.
>> 
>> 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. 
>> 
>> 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...
>> 
>> Volker
>>> 
>>> Provide the ability for the registrant to trigger the TDRP process in cases when they disagree with their registrar over an IRTP issue
>>> 
>>> In general, registrars initiate TDRP when they can't resolve matters between themselves
>>> 
>>> 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
>>> 
>>> Build minimum documentation requirements for registrants into the policy as a filter to prevent frivolous filings
>>> 
>>> If Compliance agrees with registrant, TDRP proceeds as normal, with fees paid by registrars, as normal
>>> 
>>> If Compliance disagrees with registrant, that's it -- it's off to court if the registrant wants to proceed.
>>> 
>>> 
>>>  
>>> PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)
>>> 
>> 
>> 
>> -- 
>> 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.net
>> www.domaindiscount24.com / www.BrandShelter.com
>> 
>> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
>> www.facebook.com/KeySystems
>> www.twitter.com/key_systems
>> 
>> Geschäftsführer: Alexander Siffrin
>> Handelsregister Nr.: HR B 18835 - Saarbruecken 
>> Umsatzsteuer ID.: DE211006534
>> 
>> Member of the KEYDRIVE GROUP
>> www.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.net
>> www.domaindiscount24.com / www.BrandShelter.com
>> 
>> Follow us on Twitter or join our fan community on Facebook and stay updated:
>> www.facebook.com/KeySystems
>> www.twitter.com/key_systems
>> 
>> CEO: Alexander Siffrin
>> Registration No.: HR B 18835 - Saarbruecken 
>> V.A.T. ID.: DE211006534
>> 
>> Member of the KEYDRIVE GROUP
>> www.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.
>> 
>> 
>> 
> 
> 
> PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-irtpd/attachments/20131203/9ead260e/attachment.html>