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