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

[Jeffrey Lyon]

On Sun, May 29, 2011 at 4:03 PM, Matthew Kaufman <matthew at matthew.at> wrote:
> 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
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>

Good points all around. With that said, I oppose ARIN-prop-153.

-- 
Jeffrey Lyon, Leadership Team
jeffrey.lyon at blacklotus.net | http://www.blacklotus.net
Black Lotus Communications - AS32421
First and Leading in DDoS Protection Solutions