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:
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
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
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 188.8.131.52 (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
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,
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.