ICANN ICANN Email List Archives


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

Re: [gnso-lockpdp-wg] RE: Lock definition

  • To: "Dorrain, Kristine" <kdorrain@xxxxxxxxxxxx>
  • Subject: Re: [gnso-lockpdp-wg] RE: Lock definition
  • From: Volker Greimann <vgreimann@xxxxxxxxxxxxxxx>
  • Date: Fri, 18 Jan 2013 18:16:33 +0100

Hi Kristine,

I'm trying hard to not just say "this isn't quite right"(without proposing a 
solution) but I can't figure out how.  I'll start by addressing this portion:

A Registrar may not permit changes to the registrant name field or registrant 
address field in WHOIS... after receipt of a request for verification is 
received by the Registrar from the Provider, ... except...to change the 
registrant name field or registrant address field in WHOIS prior to 
commencement of administrative proceedings under the Policy...

Here is the timeline:

Day 1 UDRP Complaint Received
Day 1 Provider requests "verification" (which includes Respondent identity and 
confirmation of Lock)
[optimistically] Day 2 Provider receives from Registrar confirmation of 
Respondent identity and Lock)
Day 2 (or 3) Provider performs administrative compliance check (aka "deficiency 
check") relying on Registrar's response and current Whois data
Days 4-9 Complainant complies with Provider requests and sends Amended 
Day 10 Provider commences the case, serving the addresses listed in the Whois 
(as cultivated on Day 1, Day 2, and Day 10), listed in the Complaint, and as 
provided by the Registrar on Day 2.

At what point, does this group feel (I have my own thoughts on this), can the Provider 
stop the roulette wheel and say "I'm going to do my compliance check and the 
complainant will need to live with the identification of the Respondent."
Not only the complainant, but the respondent / his privacy service provider as well.
Because identification of "who is the Respondent" matters (even in spite of the 
fact that the Panel can 'name' the case however it wants when its appointed):
1. for mutual jurisdiction purposes
2. for service/notice
3. to ensure that each complaint goes against only one Respondent
4. for purposes of establishing patterns of abusive registrations
5. for non-qualification as applicant for new gTLDs

I think laying down that the identity of the respondent matters is indeed one of the more important matters in the UDRP today, precisely because the identity of the respondent in the decision has an overarching effect beyond the scope of the single UDRP case.
If it is permitted for details to be updated up until commencement, then the 
Provider can go to commence the case on Day 10, notice a change and now the 
Complaint is mis-captioned/Respondent is mis-identified and the Provider has to 
do its deficiency check all over again and go back to Complainant again (who at 
this time is well past livid).
Agreed. We therefore should look for a time-window in which such changes may be made. Frankly, I do not know why the time period granted to the complainant for amending the complaint should be longer than the time allotted for the initial verification. The mandated three day time for the deficiency check should in my view be expanded to four work days, which would allow a privacy service to be lifted within the first three days. All under the condition that no other changes be permitted during that time.

The Respondent can always email us correct information for themselves.
As the decision may however still be directed against the privacy provider and not the respondent, I do not think this is sufficient.
So maybe what I'm proposing is something more like:
A Registrar may not permit transfer to another registrant or registrar after 
receipt of a request for verification is received by the Registrar from the 
Provider, except in limited situations involving an arbitration not conducted 
under the Policy or involving litigation as provided by Policy Paragraphs 8(a) 
or 8(b).  For the purposes of UDRP, the Registrant listed in the Whois record 
at the time of the Lock will be recorded as the Respondent.  Any changes to 
WHOIS information during the pendency of the administrative proceeding under 
the Policy may be permitted or prohibited based on the Registrar's applicable 
policies and contracts, however, it is the responsibility of the Registrant 
(UDRP Rule 2(e) and UDRP Rule 5(b)(ii)) to inform the Provider of any relevant 
updates that may affect Provider notices and obligations to Respondent under 
the UDRP.

Privacy/Proxy services:  [I think we were going to get some data from Volker 
here, but I'll toss this out there for discussion:]
A registrar may opt to reveal underlying data in a privacy/proxy relationship to the 
Provider or in the Whois, or both, if it is aware of such.  This will not count as a 
"transfer" in violation of the above, if it occurs prior to the Lock (and the 
Registrar's reply to the
This makes sense and I would support this.
Provider).  If a privacy/proxy relationship is revealed or released after the 
Lock is applied and the Provider is notified, the Provider is under no 
obligation to require Complainant to amend its complaint accordingly, but may 
do so, in its discretion.  It is the responsibility
I have a problem with this being optional for the provider for the reason of the effects detailed above that a non-amendment may have. I would much rather see a two-day window after the domain was locked and the provider was notified but prior to commencement in which such a reveal and release can be performed with a binding effect. After commencement, the amendment would become optional.
of the Registrant (UDRP Rule 2(e) and UDRP Rule 5(b)(ii)) to inform the 
Provider of any relevant updates that may affect Provider notices and 
obligations to Respondent under the UDRP and the Provider shall, in accordance 
with the UDRP, provide Respondent with case information at the details it 
prefers once the Provider is aware of the update (UDRP 5(b)(iii) requires 
Provider to send communications to the preferred email address of Respondent, 
for instance).
This iteration basically codifies NAF's practice (David R-T, feel free to chime in as to if it supports 
WIPO's practice) with an addition to prevent chasing our tails.  We get the email from the Registrar saying 
"yep, domain is locked, carry on."  We pull the Whois, look at the email sent by the Registrar and 
tell the Complainant: "the party named in the complaint is ok or not...fix it if not".  Once we're 
good to go, we commence the case according the UDRP Rule 2(a)(i) and (ii).   If someone has pulled the rug 
out from under us by changing the Whois again (when we have a look on "day 10"), we have to start 
over.  However, once we send the commencement docs out, the Whois can change 100 times, but unless the 
Respondent tells us it wants to update contact information we're done looking.
I would suggest that after receiving the registrar notification and before the commencement/informing the registrant an amendment period should be inserted for accredited privacy service providers.

Now, to be completely honest, this is mainly an academic point on what makes sense to me on the principle of the matter bearing in mind the consequences of potentially being named the losing respondent in a number of UDRPs even though the actual registrant is someone else. While I know of a number of non-affiliated privacy services that are used by our customers, I have not yet received one request for an update in the time prior to the commencement, but then, we do not notify the registrants of the pending UDRP, so I would assume the lack of requests for updates also stems from the failure to know of the pending proceedings in the first place. Once the respondent is informed, the proceeding has already commenced. If requests come for updates, these are usually during suspension periods to allow the transfer of the domain name. OTOH, if the UDRP explicitly made reference to allowing such updates, and the privacy service provider be informed of the proceedings after the lock but before commencement, I would assume that such requests would be more common. For our own service, I am perfectly happy with the current practice of deactivating the service prior to locking the domain.

The option to update after the lock would only be applicable to accredited privacy service providers. Incidentally, the new RAA would preclude registrars from knowingly accepting registrations from unaccredited privacy service providers after a certain time after the accreditation scheme was implemented. Therefore, once that RAA goes live, the distinction between accredited and non-accredited providers will become moot.


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

Privacy Policy | Terms of Service | Cookies Policy