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

[Volker Greimann <vgreimann@xxxxxxxxxxxxxxx>]

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 
> complaint.
> 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.
Volker