Brandon and Bill, I think you are on the right track. I've said recently that allocations of IPv4 should be limited to some combination of organization size and/or current IP allocations. Of course translating that into a policy that works is tricky but doable I think. Why not take the needs test completely off the "Minimum Allocation Size" which I think is currently a /22. Add a standard waiting period between allocations of say 6 months. Provide some way an organization with a hardship can apply sooner than 6 months if they have a truly demonstrable need. Then match the allocation request size with the organizations current allocation's - and/or their current network size or financial size.
On the low end some more /22 allocations really aren't going to cause exhaustion that much faster and on the large size all the way to a /8, only organizations who are big enough would get a big allocation similar to the way T-Mobile got 3/4 of a /8 a while back. If a big guy like an AT&T or Verizon were to apply for a /8, even though ARIN only has one full /8 left, I'm guessing they could justify it under almost any needs criteria or they wouldn't be requesting it. I'm sure this community has the knowhow to come up with policies that accomplish this. Under this scenario the needs part of the allocation request is removed and what remains is a rightsizing policy in its place to reduce hoarding as best as we can. My gut tells me that changing to this kind of allocation process would not cause ARIN to run out of addresses much sooner than current policies. -----Original Message----- From: arin-ppml-boun...@arin.net [mailto:arin-ppml-boun...@arin.net] On Behalf Of Brandon Ross Sent: Wednesday, June 12, 2013 12:07 AM To: William Herrin Cc: Mike Burns; ARIN PPML Subject: Re: [arin-ppml] A Redefinition of IPv4 Need post ARIN run-out (was:Re:Against 2013-4) On Tue, 11 Jun 2013, William Herrin wrote: > On Tue, Jun 11, 2013 at 9:22 PM, Mike Burns <m...@nationwideinc.com> wrote: >> What about a needs-free transfer cap? > > It'd have to be per-timeframe (per year). A per-transfer cap would be > meaningless. I support the idea, in general, of needs-free transfer cap, however, I'd suggest that cap be based on the total amount of address space that an entity controls rather than a per period or per transfer based cap. In other words, if you are big enough to justify, in total, a /12 of address space, then you are big enough to handle the burden of justification. If you have less space than that, in aggregate, then the needs requirement can be waived. If shell corporations are a concern, then the cap can be made small enough such that any attempt to corner the market would be easy to detect because of the sheer number of shells necessary to do so. Perhaps it's possible to hide the ownership of a dozen, but certainly not 100 or 1000. It is worthwhile, however, to point out that if I wanted to hoard IPv4 address space, there's nothing stopping me from doing that using shell corporations now, so I don't see how removing the cap for small allocations really makes much of a difference. -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://doodle.com/bross Skype: brandonross _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.
