[arin-ppml] Updated text for ARIN 2014-16: Section 4.10 Austerity Policy Update
andrew.dul at quark.net
Thu Sep 18 23:05:50 EDT 2014
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 22.214.171.124.
>>> 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 126.96.36.199 or a similar
>>> provision to 4.10.1 in place of 188.8.131.52.
>> 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 184.108.40.206 as well. However, if you’re going to have 220.127.116.11, 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. 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 (18.104.22.168) of
the policy on the mailing-list or at the meeting.
>>> 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.
More information about the ARIN-PPML