ICANN ICANN Email List Archives


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

[gnso-impl-irtpc-rt] RE: A possible fix?

  • To: "James M. Bladel" <jbladel@xxxxxxxxxxx>, Michele Neylon - Blacknight <michele@xxxxxxxxxxxxxx>, "gnso-impl-irtpc-rt@xxxxxxxxx" <gnso-impl-irtpc-rt@xxxxxxxxx>
  • Subject: [gnso-impl-irtpc-rt] RE: A possible fix?
  • From: "Batteiger, Simonetta" <simonetta@xxxxxxxx>
  • Date: Wed, 12 Feb 2014 23:22:00 +0000

Hm... In the case of an aftermarket sale, the FOA is originally "pre-approved" 
by the seller (with the Losing registrar).
I don't know how a Gaining Registrar would have any ability to "verify" that. 
They would likely not even know what the previous WhoIs record was at the time 
the seller gave the Losing Registrar their FOA.

When the name moves over, the Gaining Registrars would usually not find 
something they can verify/compare and only know what the "new WhoIs data" of 
the buyer should be. That buyer should not be the entity giving the FOA.

One other way to look at this could be to use FOAs in combination with the auth 
info codes. In essence we came out at the end of IRTP-C anyway, that we should 
look at whether auth-info codes are fulfilling the same function as an FOA. So 
maybe a suggestion could be to say that Losing Registrars should only provide 
auth info code to users who have given a valid FOA and if somebody can present 
a valid auth info code for the transfer, a registry can assume the FOA is valid?

From: James M. Bladel [mailto:jbladel@xxxxxxxxxxx]
Sent: Wednesday, February 12, 2014 6:03 PM
To: Batteiger, Simonetta; Michele Neylon - Blacknight; 
Subject: Re: A possible fix?

Hi Simonetta.  The new policy lays out several situations under which an FOA 
would no longer be valid. T he problem discussed during today's call was:  How 
will the (would be) Gaining Registrar know that the FOA they are holding is 


From: <Batteiger>, Simonetta <simonetta@xxxxxxxx<mailto:simonetta@xxxxxxxx>>
Date: Wednesday, February 12, 2014 at 16:59
To: Michele Neylon - Blacknight 
<michele@xxxxxxxxxxxxxx<mailto:michele@xxxxxxxxxxxxxx>>, James Bladel 
Subject: RE: A possible fix?

Also sorry for having missed today's call.
I'm not entirely sure which problem you're trying to solve with the ideas below.
Is this about verifying if an FOA is still valid?

[mailto:owner-gnso-impl-irtpc-rt@xxxxxxxxx] On Behalf Of Michele Neylon - 
Sent: Wednesday, February 12, 2014 5:53 PM
To: James M. Bladel; 
Subject: [gnso-impl-irtpc-rt] RE: A possible fix?

Sorry I missed the call


1 - which registrar? Gaining? Losing? Both?
2 - um .. hangon, unless I'm missing something that would also prevent a 
nameserver update, wouldn't it? (Bear in mind I'm quite tired this evening, so 
I could be wrong)



Mr Michele Neylon
Blacknight Solutions
Hosting & Colocation, Domains
Intl. +353 (0) 59  9183072
Locall: 1850 929 929
Direct Dial: +353 (0)59 9183090
Fax. +353 (0) 1 4811 763
Twitter: http://twitter.com/mneylon
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,Ireland  Company No.: 370845

 [mailto:owner-gnso-impl-irtpc-rt@xxxxxxxxx] On Behalf Of James M. Bladel
Sent: Wednesday, February 12, 2014 10:44 PM
To: gnso-impl-irtpc-rt@xxxxxxxxx<mailto:gnso-impl-irtpc-rt@xxxxxxxxx>
Subject: [gnso-impl-irtpc-rt] A possible fix?

Hi folks.  Hope no one was discouraged following todays call.  These things are 
very difficult (if they weren't anyone could do them)...but not impossible!

So thinking a bit more, I believe we can address some of these issues by 
requiring two practices:

(1) Registrars must take two WHOIS "snapshots":  One to obtain the FOA, and one 
at Transfer execution.
(2) Registries must "lock" (ServerUpdateProhibited, 
ServerTransferProhibited,ServerDeleteProhibited) on all names known to be 
subject to a UDRP or TDRP.

Reasoning:  By comparing the WHOIS record at both occasions, the Gaining 
Registrar can spot any differences in Registrant data or Domain Status. This 
will provide the necessary visibility to invalidate the FOA and re-authorize 
the transfer.



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

Privacy Policy | Terms of Service | Cookies Policy