[arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3

[Matthew Kaufman]

On 5/28/2011 12:13 PM, Owen DeLong wrote:
> On May 28, 2011, at 7:47 AM, John Curran wrote:
>
>> To answer your question we would first need to know how to handle the
>> transfer of a smaller block than the party actually qualifies for, and
>> whether it is as a circumvention of policy.  For example: a party (X),
>> needing a /15 for 12 months growth, will get told by ARIN that they
>> will actually only receive a /17 (because we're only providing space
>> to meet 3 months of need).  If X instead opts to get space from party
>> (Y), who is is willing to transfer their /16 to X, does ARIN approve
>> the transfer fully knowing that it is not an exact match but is actually
>> less then X's documented need?  Or do we tell X that they need to find
>> a willing party Z who has two contiguous /16's available in order to
>> meet X's *exact* need?
>>
> The intent of the policy would be that ARIN would decline the particular
> transfer due to mismatch and could reiterate the need to find a /15
> or blocks which can be assembled into a /15 (contiguous bit-aligned
> /16s would qualify, disjoint or non-bit-aligned /16s would not, but
> 8 contiguous bit-aligned /18s would also qualify, for example).
>

Ok, now I absolutely, positively, oppose this policy as being as huge 
distorting force on any possible transfer market *and* forcing either 
unregistered transfers or legal action or more.

Consider the following case:

Organization A is in immediate need of a /19 of space in order to 
continue their operations through the IPv6 transition. They've gone 
ahead and had ARIN sign off on this need, because they don't want any 
delays if and when a /19 comes up in the market. But if they can't get 
at least one or two /24s in the next few weeks, they're going to start 
losing customers.

But the market has been really tight the last few weeks or months, and 
only some /24s have been up recently... certainly no /19s. They find a 
seller with a /24, and decide they must act now.

Do they:
A) Go back to ARIN and explain how the /19 of need magically evaporated, 
send in paperwork to justify the /24, transfer it, knowing they'll be 
locked out of getting the additional space they need for some time.

B) Wait for a /19 to become available

C) Transfer the /24 but don't tell ARIN, so their /19 of need is still 
in the system

A few weeks later, a /19 does become available and they can afford it.

If they chose (A) above, do they:

1) Purchase the /19 but delay filing the transfer with ARIN

2) Purchase the /19 but never file the transfer with ARIN

3) Engage in a lease of the /19 and never tell ARIN

4) Sue ARIN to force recognition of both transfers

5) Simply pass up the opportunity to get the space they need

If they chose (B) above, do they:

6) purchase the /19 and register the transfer with ARIN

7) not act, because not having the /24 in the meantime has cost them 
their business

If they chose (C) above, do they:

8) Purchase the /19 and register the transfer with ARIN

9) Purchase the /19 and not register the transfer, in case they need 
more space in the allotted time interval?


>> If we do approve the /16 transfer to X, then a subsequent request for
>> a transfer to meet their residual need is both quite likely and would
>> not be circumvention of policy.  If we reject the transfer due to being
>> smaller than the documented need, then the "end-run" described above
>> cannot occur.
>>
>> Which interpretation best matches your policy intent?
>>
> Rejecting the transfer and, as I expected, said end-run would be blocked
> by ARIN.


Unacceptable answer to the point of being ridiculous. Clearly the 
"residual need" might be much much larger than the initial transfer (see 
the case above)

Matthew Kaufman