ICANN ICANN Email List Archives

[gnso-lockpdp-wg]


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

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

  • To: "Gnso-lockpdp-wg@xxxxxxxxx" <Gnso-lockpdp-wg@xxxxxxxxx>
  • Subject: Re: [gnso-lockpdp-wg] For your review and feedback - options to address settlement
  • From: Luc SEUFER <lseufer@xxxxxxxxxxx>
  • Date: Mon, 17 Jun 2013 08:54:39 +0000

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,

Luc


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 
meeting.

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 
list.

With best regards,

Marika

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 
Compliance)?

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.

--------------------------------------------------------




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

Privacy Policy | Terms of Service | Cookies Policy