[arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3

It would be even more preferable that the /20 not be broken into /24's, but
kept whole.  I don't think we need to modify policy to do that -- I'm hoping
that the market will price that consideration into the transaction.  Someone
who needs a /20 will likely prefer a whole /20 than a collection of smaller
pieces, not only for their own documentation, but it's less deals for the
buyer to transact and less risk that the address pace would be filtered from
route announcements.   So while it may seem from a volume perspective that a
/20 would be cheaper per address, it may end up being more expensive.


-----Original Message-----
From: Owen DeLong [mailto:owen at] 
Sent: Tuesday, May 31, 2011 4:11 PM
To: matthew at
Cc: frnkblk at; arin-ppml at
Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3

On May 31, 2011, at 10:30 AM, Matthew Kaufman wrote:

> Back to my original point, the right answer is somewhere between "all
blocks may be broken up into /24-sized pieces" and "all blocks must not be
broken up any further than the original ARIN allocation size"... and that's
the *only* way to prevent table growth, as *who* gets the blocks is
completely irrelevant for that point.

Yes and no. The right answer is to allow transfers that disaggregate only to
extent absolutely necessary to meet a given recipient's need. If they need
a /20, then, transferring a /20 is vastly preferable to
transferring 16 disjoint /24s. On the other hand, 16 organizations, each of
whom need a /24 have no better solution than to transfer 16 /24s, whether
they come from the same source or not.