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.
