[arin-ppml] Revised -- Policy Proposal 2009-4: IPv4 RecoveryFund

Kevin Kargel kkargel at polartel.com
Mon Apr 13 17:23:29 EDT 2009


> 
> In a message written on Mon, Apr 13, 2009 at 03:55:54PM -0500, Kevin
> Kargel wrote:
> > One issue I do have is that the proposal is heavily slanted toward the
> big
> > organizations with section 4.X.4 where it states "Recovered IPv4 number
> > resources should be broken into smaller blocks only if there are no
> > bidders for the larger sized blocks"
> > I understand the rationale for this, but it would guarantee the big
> ISP's
> > first crack at any blocks leaving only leftovers for small and middle
> sized
> > operations.  This is not a level playing field.
> 
> I saw this the opposite, that it helps the little guy.  However,
> that is based on an assumption, the smaller the block the more
> likely it will be available on the market.
> 
> If a big guy comes along and gets qualified for a /12, he has to
> wait for someone to return (voluntarily or for a recovery fee) a
> /12.  ARIN is prohibited from handing him a bunch of smaller blocks
> under this policy.  Relatively speaking there are very few /12's
> out there, so there's a good chance that big guy will be waiting
> for a long time.
> 
> Compare to someone who needs a /20.  There are a ton of /20's out
> there, so there is a much better chance someone will be able to
> free up one for someone else to use.
> 
> With transfer proposals like 2008-6 and 2009-1 there's nothing to
> prevent someone who needs a /12 from buying up hundreds or even
> thousands of /18-/22 sized blocks to meet their needs.  This proposal
> only allows you to bid on the exact size you were approved for, get
> approved for a /12 you can only bid on a /12.
> 
> --
>        Leo Bicknell - bicknell at ufp.org - CCIE 3440
> 	PGP keys at http://www.ufp.org/~bicknell/

I do think that if an organization is qualified for a /12, but thinks they
might have better success to meet a short term need by bidding for a /16
they should have the freedom to do so.  Perhaps placing a limit on the
number of concurrent active bids would solve that.

Kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090413/2641c54d/attachment.bin>


More information about the ARIN-PPML mailing list