ICANN ICANN Email List Archives


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

Re: [gnso-lockpdp-wg] Domain lock committee - question lists

  • To: Luc SEUFER <lseufer@xxxxxxxxxxx>
  • Subject: Re: [gnso-lockpdp-wg] Domain lock committee - question lists
  • From: "John Berryhill, Ph.d., Esq." <john@xxxxxxxxxxxxxxxxx>
  • Date: Thu, 10 May 2012 12:32:55 -0400

By way of more color and background...

On 5/10/2012 10:43 AM, Luc SEUFER wrote:
Hi John,

I had the same feeling for some of the questions regarding the Lock measures 
taken by each registrar.

The "lock measures" are not as much of an issue, as neither the UDRP nor the RAA require a "lock" of any sort during a UDRP (at least as far as changes within the registrar are concerned; the UDRP and the IRTP both refer to inter-registrar transfer interaction with the UDRP).

There is an assumption, or implicit consequence, of a "lock" requirement, but that is something of an administrative convenience which developed over time in connection with UDRP Paragraph 8:

"*a. Transfers of a Domain Name to a New Holder.* You may not transfer your domain name registration to another holder (i) during a pending administrative proceeding brought pursuant to Paragraph 4 <http://www.icann.org/en/help/dndr/udrp/policy#4> or for a period of fifteen (15) business days (as observed in the location of our principal place of business) after such proceeding is concluded; or (ii) during a pending court proceeding or arbitration commenced regarding your domain name unless the party to whom the domain name registration is being transferred agrees, in writing, to be bound by the decision of the court or arbitrator. We reserve the right to cancel any transfer of a domain name registration to another holder that is made in violation of this subparagraph."

Now, in this paragraph, we have a "15 day" period, but this one is different from the "10 day" period in the event of a UDRP ordered transfer. This is one of the several nuanced messages in the UDRP that complainants are better than respondents. In the event the complainant wins, transfer is to occur after 10 business days. But in the event the respondent wins, we wait 15 business days before the respondent - who had the name all along - obtains full control back. To put it simply - the UDRP cares more about the convenience of a winning Complainant, than a winning Respondent, by giving those parties different time scales at which they obtain full control of the name after a proceeding is concluded. In practice, virtually no registrar follows the 15 day period at all, and most unlock the name upon receipt of a UDRP decision denying the complaint.

HOWEVER, the "you" in the UDRP is the domain registrant. What paragraph 8a literally says is that they can make transfers to another holder during a UDRP if certain conditions are met, but that the registrar may reverse or cancel that transfer. The registrar's intervention is stated as remedial, and not proscriptive.

As a practical matter, no registrar has any system implemented to actually confirm that transfers under 8a satisfy the stated conditions, so the "UDRP lock" historically developed as an administrative convenience or "best practice" among registrars to prevent shenanigans in violation of 8a. At the current date, I would be willing to bet that most registrars believe that transfers are not permitted under any circumstances during a UDRP. This leads to interesting results if you time your UDRP complaint to coincide with corporate re-organizations or acquisitions. But that's a story for another time. It also causes issues with pre-decision settlements.

The important thing to remember in the discussion of "locks", we are not discussing anything that is literally required by the UDRP as written, but a practice which has grown up around it.

And this is where the previous staff-initiated discussion of a "best practices" document ran aground. ICANN legal counsel took the position that imposing a requirement on registrars in the implementation of the UDRP, but which was not required by the UDRP, was fraught with difficulties in terms of whether non-compliance would, or would not, give rise to a situation in which a compliance action was authorized under the RAA, since such a "best practice" document is not enforceable as an ICANN Consensus Policy.

The other bugaboo written into the UDRP, when it comes to looking at, say, any of the timescales or the apparent restrictions of Paragraph 8, is in of Paragraph 3 of the UDRP which states:

"3. Cancellations, Transfers, and Changes. We will cancel, transfer or otherwise make changes to domain name registrations under the following circumstances:

a. subject to the provisions of Paragraph 8, our receipt of written or appropriate electronic instructions from you or your authorized agent to take such action;

b. our receipt of an order from a court or arbitral tribunal, in each case of competent jurisdiction, requiring such action; and/or

c. our receipt of a decision of an Administrative Panel requiring such action in any administrative proceeding to which you were a party and which was conducted under this Policy or a later version of this Policy adopted by ICANN. (See Paragraph 4(i) and (k) below.)

We may also cancel, transfer or otherwise make changes to a domain name registration in accordance with the terms of your Registration Agreement or other legal requirements."

Pay close attention to that last sentence. It is the "Monster that ate the UDRP", when you consider that every registrar writes their own Registration Agreement. Yes, the Registration Agreement requires compliance with the UDRP, but the last sentence of Paragraph 3 creates something of a circular logical loop. Hypothetically, I can run a registrar and impose a term in the Registration Agreement which says, "In the event of a UDRP, the name will be transferred to John Berryhill in all instances." Then, whenever anyone wins a UDRP, I get the name and the Complainant does not, because Paragraph 3 says that the registrar ("we") may ALSO do whatever is in the Registration Agreement.

That's an extreme example, but it is intended to point out the drafting trainwreck which is the critically operative section of the UDRP which states, in part c that "We will transfer the domain name if someone wins a UDRP" and then snatches that back by saying "but we may also do other things if our Registration Agreement says so".

The UDRP lock "best practice" document thus foundered on the realization that Paragraph 3 of the UDRP itself permits a registrar to do whatever it wants, by writing such terms into their own Registration Agreement - including disemboweling the UDRP itself.

Now, to be clear, the registrars who worked on the previous draft fully desire to have a clear set of procedures to follow for locking names subject to a UDRP, because it reduces headaches, guesswork and compliance threats down the road. However, the previous effort ran aground on the basis of what is probably a too clever by half reading of the Policy itself.

The upshot - "locks" of any kind are not required by the UDRP. They are an administrative convenience, and the registrars themselves would appreciate clear direction on the subject capable of interpretation by someone who is not a lawyer.

Considerations of "locks" in general need to take into account:

1. Simultaneous requirements of other ICANN consensus policies, such as WHOIS accuracy and RAA (the dreaded "is that proxy/privacy registration" clause). These policies do not somehow cease to be operative because a UDRP was filed;

2. Who is considered to be on notice of what and when, and how is notice to be effected (e.g. GoDaddy is an organization of hundreds of employees, sending an email to any one of them is not a guarantee that the employee in question knows or can interpret what they have received);

3. Convenience of the UDRP parties (e.g. quite often the parties themselves resolve a dispute long before it reaches a decision. As it is an alternative dispute resolution procedure, the joint agreement of the parties, such as transferring the name between them, should be readily accommodated).

Point 1 is particularly critical. Registrars must at all times comply with all consensus policies and the RAA. These requirements define their business. The UDRP is only ONE of the several policies registrars must implement. Casual observers frequently make suggestions to one area of policy, without awareness of situations that give rise to conflicting mandates imposed by separate policies.

The problem of policy collisions is compounded by what amounts to "folklore" around the policies. The UDRP "lock" itself is an example of such folklore. Most people believe there is a lock requirement, but are surprised to find that it is not in the UDRP, but is considered by some to be an implicit consequence of enforcing Paragraph 8a. That is an assumption with which virtually all registrars are comfortable, fortunately.

However, there can be competing folklore. The WHOIS Data Problem Report System (WDPRS) and the underlying policy apparatus, are taken by some to mean "If there is reported inaccurate WHOIS data, then the registrar must have the registrant fix it, or delete the registration after 15 days of trying". So, consider, 20% of the US population for example, will change their address this year. Businesses re-organize, re-name, merge, etc. regularly. The chore of "updating WHOIS data" is hardly ever at the top of anyone's to-do list when these events occur. If the name works, and is paid for, all is well.

So, let's say a UDRP is filed on day 1 by complainant A. Let's also say a WDPRS report is lodged on day 2 by complainant B. On day 3 or 4, the Registrar receives two conflicting directives - (1) Lock the name pursuant to the UDRP, and (2) Update the contact data or delete the name in 15 days pursuant to the WDPRS.

There is nothing, in the constellation of individual policies, to tell the registrar "which policy wins". You might think those are rare events. However, when you are a registrar managing some 20 million plus domain names, "rare events" occur daily. Compounding the "which policy wins" problem is that the people who have to run these things are not consulting the policies, but are generally going on the type of folkloric understanding of them because, again, they are not lawyers.

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

Privacy Policy | Terms of Service | Cookies Policy