[arin-ppml] Nanog IPV4 Panel Discussion and 8.3 transfers

Andrew Dul andrew.dul at quark.net
Fri Feb 10 12:36:52 EST 2012


On 2/10/2012 3:11 AM, John Curran wrote:
> On Feb 10, 2012, at 11:33 AM, Matthew Kaufman wrote:
>
>
>> If that fails (which it probably won't), they renegotiate the deal so that they actually control the whole /16 but only transfer the /20 for now, and transfer the rest later... in the meantime they either advertise only the /20 or they just advertise and use the /16 with Vendor A's permission. Then anyone investigating what's going on has no idea what the actual usage of the "rest" of the /16 is, and thus begins the inevitable decline in the data quality of the IPv4 whois service.
>
> To be clear, the rest of the /16 remains registered with Vendor A, 
> who might decide months later to use it for some other purpose, or 
> transfer some to Party C.  
>
> The Whois reflects the actual registrant, not when Vendor B has 
> an agreement to transfer in the future under some condition, or 
> a right of first refusal to match or beat future transfer price,
> or an option to exercise to obtain in the future at a certain
> price, or any number of other esoteric structures that parties 
> might postulate.
>
> The point is that the actual number resources transfer when the
> policy is met, and don't until that time.
>
>

This illustrates the point I was trying to make.  The current policy is
ambiguous with regard to contracts that may exist which contradict what
may or may not be recorded in whois.  If Vendor A sells some to Party C
some of what it sold to Vendor B the first time but wasn't transferred,
we now have a sales contract conflict which likely can only be resolved
in court.

I am not sure what the exact policy answer is to this scenario, but
something seems like it needs to deal with this issue.  Its possible
this is a corner case which will never occur, but what exists today
seems like it needs changes to reflect business and contract realities.

Andrew







More information about the ARIN-PPML mailing list