ICANN ICANN Email List Archives


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [gnso-lockpdp-wg] For your review and feedback - options to address settlement

  • To: Michele@xxxxxxxxxxxxxxxxxxxxxxx, "\"Neylon:\"@mail-01.key-systems.net":Blacknight <michele@xxxxxxxxxxxxxx>
  • Subject: Re: [gnso-lockpdp-wg] For your review and feedback - options to address settlement
  • From: Volker Greimann <vgreimann@xxxxxxxxxxxxxxx>
  • Date: Mon, 17 Jun 2013 15:52:43 +0200

I also agree. The role of the registrar in the UDRP is of an executing nature, not of a deciding or evaluating nature. In other words, the UDRP directs us to perform certain actions when certain situations are met. If the provider tells us to lock, we lock, if it tells us to unlock, we unlock and if it tells us to transfer ownership, we transfer ownership.

The suspension is no different from that. In case of a suspension, we will do exactly what we are told to do by either the provider or both parties.

I also note that the summary by Marika " that a transfer can only be carried out once the UDRP has been dismissed" does not accurately reflect the current situation. In most cases of a suspension today, the complainant will ask to reinstate the proceedings if the transfer has not already taken place. In various messages from UDRP providers, the procedure of transferring a domain name to the complainant during the suspension (not after) was confirmed, for example when a provider inquired in case of a suspended proceeding "if the domain name has been transferred to the complainant or the suspension should be extended; or the proceeding should be resumed" or writes that "During the suspension, the domain name may only be transferred to Complainant. Once the transfer of the domain names has been concluded, the proceedings will be terminated at the request of the Complainant.".

The only change we should be looking at is whether the provider should be responsible for determining if a settlement has been reached or if this is the responsibility of the registrar. Based on LUc's comment, I would argue the former would be more adequate.



Luc et al

Removing my chair hat ..

I fully support Luc's views on this.

We are a small registrar.

We do not have a team of lawyers, nor are we involved in many UDRPs. I'm sure 
there are quite a few other registrars in a similar position.

With that in mind we need simple, clear instructions on what we need to do. 
Call it simplistic, but the UDRP provider appears to be the only entity who can 
provide these instructions with respect to settlements etc., and I think Luc's 
suggested process below makes a lot of sense.

As a registrar the stakes are very high. If we do not enact the UDRP decision / 
settlement etc., correctly we risk losing our accreditation with ICANN.



On 17 Jun 2013, at 03:54, Luc SEUFER <lseufer@xxxxxxxxxxx>

Hi All,

Sorry for not being able to join last week.

I am one of those few (in the working group but majority I am sure in the 
registrar community) strong supporter of Option A.
As far as I know, option B is how a settlement during UDRP proceedings is 
currently operated by most of the providers, so it would be solely a vetting of 
current practices which in my opinion are full of grey areas. As evidenced by 
Marika’s to the point description, registrars are currently asked to:

unlock for the sole purpose of (whatever the settlement is),
As the registrars on this working group have been explaining since its start 
there are no uniform lock measures and those have several layers. Solely asking 
registrars to unlock the domain name for a purpose that is not yet agreed upon 
by the parties is just too vague. Furthermore, some in this group were 
apparently dead-scared of the cyberflight risk at the beginning of the process, 
but this broad unlock instruction  would bring back the same risk level.

Solely asking registrars to unlock is not precise enough, the purpose needs to 
be expressly stated i.e. change the owner details to XXXX, initiate a deletion 
procedure at the registry’s level... At the end of the day registrars are mere 
technical intermediaries and not law firms able to understand settlement 
agreements and to take all necessary measures to ensure their timely execution.

 From what I understand, UDRP providers seem to fathom option A as an added 
layer liability for them, which it is not if this process is clearly defined. I 
trust they are ways to do so.

For example, we could imagine that a simple standardised form be used by UDRP 
providers. Such form which would be executed by both parties (or their 
representatives) would state that the parties have settled and request that the 
domain name(s) subject to the proceedings remain with the respondent, be 
transferred to the complainant (details of the latter for each contact set 
would have to be specified) or be deleted.

UDRP providers would then only operate the so-called administrative review of 
the form and if such review is conclusive would instruct the registrar of the 
action to take.

By doing so we would leave all the issues attached to a settlement in the hand 
of the applicable parties and not grant new powers and responsibilities to UDRP 
providers, or ask of registrars to try and decipher settlements between while 
having their ICANN accreditation at stake in case of a misinterpretation of 
said settlement.

Let me have your thoughts,


On Jun 16, 2013, at 1:35 PM, Marika Konings 
<marika.konings@xxxxxxxxx<mailto:marika.konings@xxxxxxxxx>> wrote:

Dear All,

As discussed during our last meeting, please find below the two options in 
relation to settlement under consideration, as well as some of the notes 
reflecting our discussion. Although option A received the most support in 
response to the survey, following further discussion during the meeting, it 
seems that there are some strong views in support of option B, while the 
support for option A is perceived to be weaker. As a result, those on the call 
appear to be leaning towards favouring option B (as modified below) for 
inclusion in the Final Report. If there is disagreement with this approach, you 
are encouraged to share your views with the mailing list ahead of the next 

Note, in reviewing preliminary recommendation #10, which is linked to this 
issue, it looks like we may need to update the language to reflect that a 
transfer can only be carried out once the UDRP has been dismissed, so replacing 
'the registrar must remove any lock preventing a transfer or cancellation 
within 2 Business days of confirmation of the settlement by both Parties' with 
'the registrar must remove any lock preventing a transfer or cancellation 
within 2 Business days of confirmation of the settlement by both Parties and 
confirmation of the dismissal by the UDRP Provider (noting that such 
confirmation of automatic dismissal may be included in the original order 
issued by the Provider informing the Registrar of the suspension). If my 
assumption is incorrect or you have other suggestions on how to address this 
issue, please feel free to share your comments / suggestions with the mailing 

With best regards,


Settlement – Options under consideration
Option A: (1) parties ask for suspension, (2) parties settle, (3) parties 
inform provider, (4) provider issues order to registrar to change the holder 
details or delete the domain name, (5) that change or deletion happens, (6) 
complainant confirms change or deletion is complete, and (7) provider dismisses 
the case.
Note – UDRP Providers noted that no transfer is allowed until the case is 
dismissed which, should this option be supported, would mean that step 7 may 
need to be added to step 4.
Option B (as updated during the last meeting) – (1) parties ask for suspension 
(suspension request includes automatic dismissal when the suspension period is 
up), (2) provider issues order allowing registrar to unlock for the sole 
purpose of (whatever the settlement is), (3) parties settle), (4) parties 
request the registrar to implement the settlement agreement - in case of a 
settlement in favor of the complainant, by moving the domain name to the 
control of the complainant where it shall remain locked pending the receipt of 
a dismissal from the provider when the domain name will be unlocked, and (4) 
provider dismisses case automatically with no further action needed (if 
settlement discussions break down, either party can request that the case be 
reinstated before automatic dismissal).
Issues discussed during the last meeting:

·       Registrar does not have relationship with Complainant, but has received 
a copy of the complaint that contains the relevant information

·       UDRP Provider does not have relationship with Respondent, but 
information should have been verified by the registrar

·       If UDRP Provider is responsible for ‘confirming’ settlement, registrars 
need to be aware that this will not absolve them from any responsibility under 
the UDRP

·       Transfer is not allowed until UDRP case is dismissed

·       Settlement can also include agreement that domain name registration 
stays with respondent (i.e. does not always involve a transfer)

·       Provider is administrative body, does not have legal authority to 
‘order’ transfer

·       If option A would become the new process (part of UDRP rules or in the 
form of an advisory), wouldn’t it become enforceable on registrars (via ICANN 

Note, this recommendation is linked to Preliminary Recommendation #10: In the 
case of suspension of a proceeding (when the parties have agreed to a 
settlement), the UDRP Provider informs the Registrar of the Suspension, 
including the expected duration of the suspension. Should both parties come to 
a settlement, which would involve a transfer, cancellation or agreement that 
the registration will remain with the Respondent, the registrar must remove any 
lock preventing a transfer or cancellation within 2 Business days of 
confirmation of the settlement by both Parties.



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.

Think of the environment: don't print this e-mail unless you really need to.


Mr Michele Neylon
Blacknight Solutions
Hosting & Colocation, Brand Protection
Intl. +353 (0) 59  9183072
Locall: 1850 929 929
Direct Dial: +353 (0)59 9183090
Fax. +353 (0) 1 4811 763
Twitter: http://twitter.com/mneylon
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,Ireland  Company No.: 370845

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:

Geschäftsführer: Alexander Siffrin
Handelsregister Nr.: HR B 18835 - Saarbruecken
Umsatzsteuer ID.: DE211006534

Member of the KEYDRIVE GROUP

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:

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

Member of the KEYDRIVE GROUP

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.

<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy