[arin-ppml] About needs basis in 8.3 transfers

[Andrew Dul]

On 6/16/2014 11:58 AM, lar at mwtcorp.net wrote:
> On Sat, 14 Jun 2014 06:59:39 -0700
>  Owen DeLong <owen at delong.com> wrote:
>> Nobody is denying resources to organizations that can document need.
>> I don’t know what your persistent failure is in this regard or why
>> you are finding it difficult. However, I have yet to see a case where
>> any reasonable need was turned away by ARIN unless one or more of the
>> following circumstances existed:
>>
>>     1.    The requestor refused to submit sufficient documentation.
>>     2.    The requestor refused to sign the RSA
>>     3.    The requestor refused to comply with community developed
>> policy.
>>     4.    The requestor’s need was so small that they could not
>> qualify under policy.
>>         Note: This last one has been so completely reduced in recent
>> policy cycles that it is hard to imagine a scenario where it would
>> apply to any
>>         but the most deliberate and stubborn of corner cases.
>>
>> As such, I’m sorry, but absent your willingness to disclose specific
>> examples in detail, I find your argument suspect at best.
>>
> Owen,
> I'm sorry but this isn't quite true. I've had an issue myself. My
> allocation is a /20.
> 80% used leaves 819 usable addresses. But as you know they get
> scattered around.
> In the case that occurred I had a customer that needed a /22 and
> another that needed a /23.
> At the time I had a single open /24 and one /26, the rest was
> non-contingous /27's, 28's
> and 29's along with individual addresses that were part of static
> pools. Since 1996 I have
> totally renumbered my network 5 times. I'm not allergic to moving
> things but it takes months
> to coordinate with customers and irritates the h**l out of them. You
> can't do it every time
> to have a larger customer need some IP.
>
> They were both deployed and working networks. Not pie in the sky. At
> the time I was only
> swiping /29 and larger networks. The request was denied because I was
> not at the 80%
> usage for the /20 I had. Actually the swipe didn't show any of my
> pools or infrastructure
> while I had other documentation the swipe needed to be close before
> resources were going
> to be used going through the rest.
>
> The staff suggested that I swipe all assignments down to /32's to help
> and then assign
> multiple /27's and /28's to the customers get over the 80% hurdle. The
> customers were
> unwilling (probably unable) to configure multiple small networks and
> then loose them
> when the larger assignment came through and I was unwilling to "dry
> lab" it just for
> show. It is ironic that I could show how over 80% of what I was
> requesting was to
> be immediately used I couldn't do it on the previous allocation.
> One customer moved on and the other has been able to take over an
> allocation to another
> customer of a single /24. It still has caused problems but it allowed
> them to get by.
>
> It's unfair to blame "ARIN" for this. The staff are applying policy as
> best they
> can and when we leave them wiggle room to do what makes sense they
> seem willing to do it.
>
> I feel that the policy has been broken for a long time. I am not in
> favor of
> eliminating a needs test but I do feel showing how addresses
> are needed and how current assignments are not sufficient to meet
> those needs should be all that is necessary. Even more so with the
> transfer market. Obviously the challenge is how to write that up as
> a policy. I would argue that giving the staff more latitude to use
> some sense is part of the answer.
>

Perhaps, we should just lower the utilization threshold to at least 50%
in every allocation.

Andrew