On Jun 25, 2014, at 08:42 , <[email protected]> <[email protected]> wrote:
> On Tue, 24 Jun 2014 15:04:17 -0700 > Andrew Dul <[email protected]> wrote: >> The problem described below appears to be more related to the current >> 3-month window for additional allocations, not necessarily the >> utilization metric. The 3-month window has had a number of >> side-effects, some of which were not anticipated when that policy was >> put in place. With run-out in the region approaching rapidly we need to >> turn our attention to the longer term policies which will support the >> desires of the community (as best possible) through the transfer market >> or other mechanisms. Changing the utilization formula (for those >> requests which do require a formal needs assessment) may be part of the >> policy changes which are needed. > Some of the problem of the formula are long standing. If your last allocation > was a /22 and you have a larger customer come to you with a legitimate and > clear need for a /22 or /21 you have no way of getting it no matter what % > utilization > is in the policy. It has always seemed to me, that "need" should have a lot > more to > do with what you are going to do with the requested allocation, and what is > available > in your current allocations, than some arbitrary utilization percentage. The > problem is that ARIN would then have to get into network design arguments. Actually, I believe that this circumstance is the reason that the immediate needs clause exists. 4.2.1.6. Immediate need If an ISP has an immediate need for address space, and can provide justification to show that the address space will be utilized within 30 days of the request, ARIN may issue a block of address space, not larger than a /16 nor smaller than ARIN's customary minimum allocation, to that organization. These cases are exceptional. Perhaps, in practice, since it is located in principles (not sure how or why that occurred), and there isn't anything concrete stating that it should be treated as an exception to 4.2.4.1, it does not get implemented as I believe was intended. Staff would have to clarify that. If that is the case, it would be a relatively simple proposal to fix: Amend section 4.2.4 by adding: 4.2.4.5 Exceptional Cases of Immediate Need If a subscriber member has a customer who needs a larger block than remains in the subscriber member's free pool, then a request under section 4.2.1.6 shall apply as an exception to the requirements in 4.2.4.1. > The argument that just removing the needs test for smaller allocations > entirely > has some merit. The problem seems to be in defining what is small. A > compromise of /20 has > been suggested and I think it's reasonable. Even though I support needs > testing I can support removing it at a /20 and smaller. I really think that removing the needs test is unlikely to gain consensus, even at the smaller point. There is clear resistance in the community to this idea and I expect that opposition will remain strong. If people support the idea above, I'm happy to put it into a policy template and get it started in the process. If there is strong support, it can probably be moved through the process fairly quickly. Owen > > Larry Ash > >> Andrew >> On 6/24/2014 1:08 PM, Steven Ryerse wrote: >>> This is the problem I'm trying to solve and why I've been so vocal about >>> it. >>> Steven Ryerse >>> President >>> 100 Ashford Center North, Suite 110, Atlanta, GA 30338 >>> 770.656.1460 - Cell >>> 770.399.9099- Office >>> >>> ℠ Eclipse Networks, Inc. >>> Conquering Complex Networks℠ >>> >>> >>> -----Original Message----- >>> From: [email protected] [mailto:[email protected]] On >>> Behalf Of Tim Gimmel >>> Sent: Tuesday, June 24, 2014 4:04 PM >>> To: [email protected] List >>> Subject: Re: [arin-ppml] Policy discussion - Method of >>> calculatingutilization ARIN-2014-17 >>> >>> >>>> The problem is that the current process has disenfranchised smaller >>>> companies who are somewhat frequently requesting space under the 3 month >>>> need projection and are ending up with many /22's, /21's etc instead of >>>> the /20 or /19 that would have been possible prior to austerity measures. >>>> To make matters worse, it does not seem that such companies are >>>> substantially represented on PPML so it is creating an illusion that the >>>> policy is not necessary or would not be supported by the community at >>>> large (outside of PPML). >>>> >>> This is exactly what is happening, for example I have 4 /20's and a /19 >>> from earlier days, but now I have 7 /21's and that is the most I will ever >>> be able to request. We are using every possible way to keep IPv4 usage >>> down. >>> >>> --Tim >>> >> _______________________________________________ >> 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. > > Larry Ash > Network Administrator > Mountain West Telephone > 123 W 1st St. > Casper, WY 82601 > Office 307 233-8387 > _______________________________________________ > 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.
