[arin-ppml] Draft Policy ARIN-2019-21: Reserved Pool Replenishment

[David Farmer]

On Mon, Dec 30, 2019 at 2:08 PM Martin Hannigan <hannigan at gmail.com> wrote:

>
> On Mon, Dec 30, 2019 at 09:15 Joe Provo <ppml at rsuc.gweep.net> wrote:
>
>> On Fri, Dec 27, 2019 at 01:00:15PM -0600, David Farmer wrote:
>> > On Fri, Dec 27, 2019 at 12:01 PM John Curran <jcurran at arin.net> wrote:
>> [snip]
>> > > It is certainly the case that if you wanted ARIN to do something
>> different
>> > > than that, the alternative would need to be clearly spelt out in
>> policy ???
>> > > the highly obvious nature of returning blocks to their special pools
>> > > doesn???t necessarily require any specification in policy, unless it
>> is being
>> > > done to avoid having such blocks inadvertently become subject to new
>> policy
>> > > language.
>> > >
>> >
>> > If this policy doesn't gain consensus, I don't think it is necessary to
>> put
>> > the first sentence into policy separately, I agree it is a fairly
>> obvious
>> > thing to do. However, having it included in this policy makes it
>> abundantly
>> > clear that the second sentence doesn't somehow apply the resources
>> > originally allocated from the 4.4 or 4.10 pools.  Further, the second
>> > sentence, as written, applies to "any other resource", and that phrasing
>> > wouldn't make much sense without the first sentence.
>>
>> I support both in principle and the specific text, also notably
>> to provide the insurance as indicated by the tail end of John's
>> paragraph above.
>
>
> Well, meh.  I don’t think its totally necessary. Although I am neutral as
> to its disposition. However, if this is going to be considered seriously,
> it would be much better if the pools were rightsized and bracketed at three
> years ( as proposal suggests) from the start. There are some technical
> difficulties to be thought out there {filters, well known addresses, etc.}
> but should be doable.
>
> The initial infra policies weren’t intended to be permanent. They were
> intended to be a crutch for growth occurring at a higher rate at that time.
> IXP and TLD growth in the US has slowed compared to when the policy was
> enacted. Everyone that needed benefit should have already gotten it.
>
> It would seem to make sense to clean up these pools all considered.
>

I'll agree that the intended longevity of the 4.4 pool was discussed at the
time of its creation or at least when it was expanded and it was intended
as a relatively short-term crutch for the IXP, TLDs and other critical
infrastructure IPv4 micro allocation growth.  Personally, I wouldn't be
opposed to right-sizing the 4.4 pool, with priority on other returned
resources over the waiting list for replenishing this pool.

Maybe right-size it down to a 5 or 6 year supply, based on the last 5 or 6
years of allocations, with the excess going to the waiting list

A little history; ARIN-2012-6 made an initial reservation of a /16 and
ARIN-2014-21 increased the reservation to a /15.
https://www.arin.net/vault/policy/proposals/2012_6.html
https://www.arin.net/vault/policy/proposals/2014_21.html

ARIN staff, could we get a history of the number of IPv4 micro allocations
for each year, by type, going back to the implementation of ARIN-2012-6?

However, I don't recall any such discussion regarding the 4.10 pool. Quite
the contrary it was my impression the 4.10 pool was intended to be around
for at least an extended period of time, if not indefinitely. In short, it
was intended to ensure the availability of small amounts of IPv4 needed for
IPv6 deployment for a very long time. Therefore, I would be opposed to any
kind of reduction to the 4.10 pool, other than by allocations as the policy
intends, and if or when the pool starts to run low I would like to see it
replenished.

A little history; ARIN-2008-5 is what became NRPM Section 4.10.
https://www.arin.net/vault/policy/proposals/2008_5.html

While I think the waiting list is an important tool to ensure resources are
not stuck at ARIN, I think continued micro allocations (4.4) and
allocations of IPv4 needed to Facilitate IPv6 Deployment (4.10) should have
priority for returned resources over the waiting list.

Thanks.

-- 
===============================================
David Farmer               Email:farmer at umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20191230/63faa0af/attachment.htm>