[arin-ppml] Updated text for ARIN 2014-16: Section 4.10 Austerity Policy Update

[Owen DeLong]

On Sep 18, 2014, at 8:05 PM, Andrew Dul <andrew.dul at quark.net> wrote:

> On 9/18/2014 3:21 PM, Owen DeLong wrote:
>> On Sep 18, 2014, at 2:22 PM, Andrew Dul <andrew.dul at quark.net> wrote:
>> 
>>> On 2014-09-18 13:37, Owen DeLong wrote:
>>>> I object to section 4.10.1.4.
>>>> An organization should not be locked out of available space simply
>>>> because they happened to be unlucky in where they got shoehorned
>>>> compared to other organizations. If an organization has a /24 and
>>>> needs another /24, but the adjacent /24 is not available, they should
>>>> be able to obtain any available /24 in the block. (This holds true for
>>>> any prefix size from /23 to /28).
>>>> I would not have a problem with applying 4.10.2.5 or a similar
>>>> provision to 4.10.1 in place of 4.10.1.4.
>>> I don't support this suggestion. I believe we need to move on from policies that require renumbering and then returning of blocks.  I don't think those really work after the free pool has been depleted, especially since ARIN isn't likely to actually reclaim the smaller blocks that we issued first.
>>> 
>> We can agree to disagree. I have no problem with not requiring a return, and if you want to do that, then I would argue you need to get rid of 4.10.2.5 as well. However, if you’re going to have 4.10.2.5, then I wouldn’t oppose applying the same criteria to 4.10.1 as well.
> This draft policy was a result of discussions in Chicago because the
> community believed that the current 4.10 policy has issues that needed
> to be fixed.  The current draft doesn't change the existing transition
> policy with the exception of the pool sizes.  If we want to update the
> transition policy too, then we can, but the focus here was to create a
> different avenue for organizations after runout based upon the feedback
> we heard at the last meeting.

4.10 may well have issues that are worthy of addressing. 4.10.1 doesn’t do that, it creates yet another avenue for pretending that IPv4 is somewhat sustainable if we just live with a few more tradeoffs.

> 
>>>>> 4. the organization may apply to ARIN for an increase in their allocation
>>>>> up to a /22, if the previous allocation under this section shows a
>>>>> utilization of at least 80%, increases will only be granted if adjacent
>>>>> bit-boundary aligned space is available at the time of request.
>>>> Does 'utilization' in this sense mean 'active v4 addresses', or
>>>> 'active v4 addresses being used in accordance with the documentation
>>>> provided to justify the original allocation'? Bullet 2 in the existing
>>>> 4.10/new 4.10.2 seems to cover this but only for that section.
>>> My intention is that if/when the organization comes back to ARIN to grow their prefix that they are actively using 80% of the block which was allocated under 4.10.1.  So if you have a /24 from 4.10.1 and you are using ~205 IP addresses you can expand to the next bit boundary.
>> I support doing this where possible, but if you happen to be unable to do so due to adjacent allocations, but a /24 is still available elsewhere, you should still be able to receive an additional /24 IMHO.
>> 
> Owen, you are the only one I recall so far to objecting to the sparse
> allocation /22 method I've proposed.  The thought behind this section
> was it would reduce fragmentation within this block.  If everyone is OK
> with the fragmentation that would result then we can change the draft. 
> I would certainly like to hear from others on this aspect (4.10.1.4) of
> the policy on the mailing-list or at the meeting.

I’m not objecting to the sparse allocation method. I’m objecting to the absolutism about what happens to someone if they need more space, but happen to be one of the blocks which is no longer sparse.

>>>> I would also prefer to leave 4.10.2 at /10 rather than shrinking it to
>>>> /11. I realize this means only the IANA returned space becomes
>>>> available for 4.10.1. I think that is appropriate.
>>> My reasoning for splitting the /10 was to ensure that the 4.10.1 austerity pool was large enough to serve the ARIN community.  Since the block sizes in the austerity pool are larger than the transition pool, the austerity pool needs to be larger to serve more organizations.
>> The ARIN community needs to realize that IPv4 is essentially over. Continuing to identify new ways to hand out ever smaller crumbs of pseudo-free-pool allocations/assignments is not, IMHO, particularly positive.
>> 
>> Hence my suggestion that only the IANA returned space be managed under 4.10.1
>> 
>> Taking half of what was reserved for transition and handing it back to business as usual is detrimental to the original intent of 4.10 and serves a much smaller fraction of the community.
> 
> I wouldn't call the austerity section business as usual.  It is a
> boot-strap for new organizations or organizations who don't have
> allocations/assignments directly from ARIN.  This section of the policy
> is intended only for organizations with no or small allocations from
> ARIN.  Other draft policies such as 2014-20 are also working to deal
> with the "slow start" issues that will exist after runout with the
> current v4 policies.  This austerity section of this draft was intended
> to address the boot-strap issue in the current v4 policies allowing
> organizations to get a block which would then allow them to later get
> into the transfer market. 

And I’m fine with 4.10.1 for IANA returned space. I’m not cool with depleting transition space to fill 4.10.1. If it’s not in the free pool, not IANA returned, then these allocations for general continuity of IPv4 practices should come from the transfer market.

It is, in fact, very close to business as usual. Yes, there are some new limitations on who/how that business as usual is conducted, but IPv4 has been ratcheting up such limitations slowly over the last 20 years, so, even the new limitations are, in fact, a form of business as usual.

Owen