That would be easier but my 2014-17 also addresses this issue. Thanks, Jeff On Jun 16, 2014 3:04 PM, "Andrew Dul" <[email protected]> wrote:
> On 6/16/2014 11:58 AM, [email protected] wrote: > > On Sat, 14 Jun 2014 06:59:39 -0700 > > Owen DeLong <[email protected]> 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 > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List ([email protected]). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact [email protected] if you experience any issues.
_______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
