Re: [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 <h.raiche@xxxxxxxxxxxxxxxx>]

I agree with both Mikey and Kristine

It seems to me that the next step is to specifically ask compliance for their 
advice on
- any process that the registrant can use
- in what circumstances
- at what cost (if any)
- whether they have sufficient powers to enforce the remedy
- what kind of documentation they would need to ensure themselves that it is a 
bona fides complaint (taking up Mikey's point)

Once we have all of that information, we can settle whether or not we can 
remove registrant's from this process - but not until then.

I have talked with the Ombudsman, who told me that he can't handle 80% of the 
complaints he receives as out of jurisdiction.  I suspect, but don't know , 
that some of them may relate to this issue - and they are not being resolved.

So please, could we fully inform ourselves of what should be in place for a 
registrant to take a legitimate complaint to Compliance, what remedies are 
available, at what cost, and what documentation is needed by compliance.

Then we can progress this issue

Holly
On 04/12/2013, at 4:03 AM, Volker Greimann wrote:

> 
> Hi Kristine,
> 
> yes, there is. It is present on the ICANN pages, and linked from the Internic 
> site.
> 
> Here is the transfer-related page:
> 
> http://www.icann.org/en/resources/compliance/complaints/transfer
> 
> This opens up a form where the registrant can initiate a compliance action 
> against his registrar, and this is a regular process that sees much more use 
> than the TDRP. AFAIK, there already is a ticketing system behind this at 
> ICANN compliance that follows the 1-2-3 compliance process.
> 
> Regarding the recourse issue, I have recently learned that one reason that 
> INGOs and IGOs vehemently demanded a process to protect their rights seperate 
> from the UDRP was that they cannot accept the clause that would force them to 
> agree to any local jurisdiction. So I learned that having common jurisdiction 
> may not even be desirable for some registrants. 
> 
> With regard of determining your "Waht if..." question, I think we first need 
> to seperate out the possible scenarios to determin which course of action is 
> needed. maybe we will find that there already are current processes that fit 
> the bill perfectly. 
> 
> Volker
> 
> 
>> Is there a specific mechanism for Registrants to complain about their 
>> Registrar?  Because I get complaints and I say “go to Compliance” but I 
>> don’t think there is a process (or I’m unaware of it).    Perhaps, if 
>> Compliance is the right home for all Registrant-initiated disputes (which 
>> seems to me like a slippery slope because I am pretty sure ICANN’s 
>> compliance team is not staffed to handle that volume of complaints), then 
>> the work product of this committee is to make a recommendation that ICANN 
>> set up a position/ ticketing system/dispute process for Registrant disputes.
>>  
>> But I think we have to answer the question.  It may be that this stuff 
>> doesn’t go in the TDRP at all, but we can’t say Registrants who are the 
>> victim of wrongful transfers or failures to transfer have no recourse 
>> outside of the court systems because the same jurisdictional issues and 
>> timing issues and cost issues that predated the UDRP arise.  We need to have 
>> some sort of answer to the question “What about when a Registrant is 
>> aggrieved (by the Registrar or where the Registrar won’t initiate the TDRP 
>> process)”?
>>  
>> Kristine
>>  
>> From: owner-gnso-irtpd@xxxxxxxxx [mailto:owner-gnso-irtpd@xxxxxxxxx] On 
>> Behalf Of Volker Greimann
>> Sent: Tuesday, December 03, 2013 10:22 AM
>> To: Mike O'Connor
>> Cc: gnso-irtpd@xxxxxxxxx
>> Subject: Re: [gnso-irtpd] here's the little summary of that sequence of 
>> events i rattled off on the call just now -- registrant role in TDRP
>>  
>> Hi Mike,
>> 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.  this was recognized as an oversight in the policy back in the 
>> misty past when this series of IRTP PDPs was launched.
>> In the first case, the right venue for the registrant is ICANN compliance, 
>> where he can lodge a complaint against his registrar.  
>> In the second case, I still not see that denying a registrant access to a 
>> process not designed for him denies him due process. I do not see that this 
>> process is "due" to registrants.
>> 
>> i don't care how this happens.  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.  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.  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.
>> A registrant can always take recourse with ICANN compliance if his registrar 
>> violates its obligations under the RAA (which includes all consensus 
>> policies):
>> http://www.icann.org/en/resources/compliance/complaints/transfer
>> 
>> Remember, were are purely talking process here, and registrar process 
>> violations are a compliance matter. Compliance action will force the 
>> violating registrar to fix the breach, therefore resolving the registrants 
>> issue.
>> 
>> Best regards,
>> 
>> Volker 
>> 
>> 
>>  
>>  
>> On Dec 3, 2013, at 9:51 AM, Volker Greimann <vgreimann@xxxxxxxxxxxxxxx> 
>> wrote:
>> 
>> 
>> Hi Mike,
>> 
>> 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. 
>> 
>> 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).
>> 
>> Volker
>> 
>> 
>> 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@xxxxxxxxxxxxxxx> 
>> 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@xxxxxxxxxxxxxxx
>>  
>> 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@xxxxxxxxxxxxxxx
>>  
>> 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.)
>>  
>> 
>> 
>> 
>> -- 
>> 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@xxxxxxxxxxxxxxx
>>  
>> 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@xxxxxxxxxxxxxxx
>>  
>> 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.)
>>  
>> 
>> 
>> 
>> -- 
>> 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@xxxxxxxxxxxxxxx
>>  
>> 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@xxxxxxxxxxxxxxx
>>  
>> 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.
>>  
>>  
>>  
> 
> 
> -- 
> 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@xxxxxxxxxxxxxxx
> 
> 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@xxxxxxxxxxxxxxx
> 
> 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.
> 
> 
>