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

["John Berryhill, Ph.d., Esq." <john@xxxxxxxxxxxxxxxxx>]

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 3.7.7.3 (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.