[arin-ppml] Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations

[Ted Mittelstaedt]

William Herrin wrote:
> On Thu, Nov 5, 2009 at 1:46 PM, Member Services <info at arin.net> wrote:
>> Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations
> 
> Hi folks,
> 
> Some comments:
> 
> 1. The proposal neither reduces nor simplifies IPv4 allocations.
> Arguably it improves them but you should consider finding a better
> title.
> 

Many proposal titles don't adequately convey the intent of the
proposal.  Suggestions on a title change are welcome.

> 2. A replacement allocation is no longer an initial allocation.
> Initial means "first" not "only one still held."
> 

Interesting argument.  However, keep in mind that what this
proposal does is creates a brand new class of requesters -
ISP's who WOULD NOT qualify under the CURRENT rules, and puts
them into a special class that is what you would term an
"extended initial requestor"

In short, right now they don't qualify at all.

Under this proposal they qualify for what might be termed a
"temporary" allocation.  If they never grow, they never renumber.
If they grow, they renumber into a larger allocation that reduces
the burden of carrying their routes - same as the current requirements.

As long as they are requesting UNDER a /20 they are NOT getting
a true "Initial Allocation" they are getting a temporary allocation.
Thus they are not really "Initial requesters"   However, since
they are getting their first allocation, they ARE "Initial
requesters" - from a certain point of view.

> 
>> 4.2.2.1. Use of /24
>>
>> The efficient utilization of an entire previously allocated /24 from
>> their upstream ISP.
> 
> Do you intend the explicit use of a /24 or do you intend the use of
> address space which adds up to at least a /24?
> 

You should ask ARIN staff that since this line is lifted straight
from the existing text.  Are you looking at this proposal as an
opportunity to clarify existing policy?

> 
> 
>> 1) Makes moot whether the requesting ISP is multihomed or not, with
>> this policy change all initial ISPs request under the same minimums.
> 
> I disagree with offering small PI blocks to entities which are not
> multihomed.  While any registrants benefit from receiving a PI block,
> only multihomed entities do so without creating new overhead cost for
> everybody else.

Multihomed entities are already obtaining larger allocations
and subnetting them, as I stated in the Rationale.

Your making a claim here that the simple property of
being multihomed somehow acts as a deterrent to an org for
subnetting, and splitting their advertisements, thus
creating new overhead cost for everyone else.

The fact is that entities that are NOT multihomed have
far more incentive to advertise all their space as a
single block, with the lowest overhead to everyone else -
and entities that ARE multihomed have an incentive to
split their advertisements - and create more overhead cost
for everyone else.

In short, logic seems to indicate that it's completely opposite from 
what your suggesting.

> I OPPOSE the proposal as written because it fails to
> restrict itself to multihomed entities. I would support the proposal
> if it restricted itself to multihomed registrants.
> 

In other words, leave 4.2.2.1 intact, and add in the "return and
renumber with lower minimums" into 4.2.2.2?

Would you support a policy proposal that went down to a /24 for
4.2.2.2 as a minimum?

Ted

> 
> 
> On Thu, Nov 5, 2009 at 5:46 PM, Seth Mattinen <sethm at rollernet.us> wrote:
>>> 4.2.2.5. Replacement initial allocation
>> OPPOSE. A small org might expect to grow and can be punished multiple
>> times (until they get a /20) by forced renumbering. An end-site office
>> building, sure, force them to renumber, but not an ISP who is assigning
>> address blocks to downstream orgs and customers.
> 
> Hi Seth,
> 
> Would you clarify: do you mean that you oppose the proposal solely
> because it *doesn't go far enough* loosening the rules on IPv4
> allocation?
> 
> As I read the proposal, nothing there would act to restrict
> allocations that ARIN or others may presently make. Have I missed
> something?
> 
> I would respectfully suggest that the looming end of the IANA free
> pool makes this a particularly inopportune time to "hold out for
> something better."
> 
> Regards,
> Bill Herrin
> 
>