<div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Dec 30, 2019 at 2:08 PM Martin Hannigan <<a href="mailto:hannigan@gmail.com" target="_blank">hannigan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="auto"></div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Dec 30, 2019 at 09:15 Joe Provo <<a href="mailto:ppml@rsuc.gweep.net" target="_blank">ppml@rsuc.gweep.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Dec 27, 2019 at 01:00:15PM -0600, David Farmer wrote:<br>
> On Fri, Dec 27, 2019 at 12:01 PM John Curran <<a href="mailto:jcurran@arin.net" target="_blank">jcurran@arin.net</a>> wrote:<br>
[snip]<br>
> > It is certainly the case that if you wanted ARIN to do something different<br>
> > than that, the alternative would need to be clearly spelt out in policy ???<br>
> > the highly obvious nature of returning blocks to their special pools<br>
> > doesn???t necessarily require any specification in policy, unless it is being<br>
> > done to avoid having such blocks inadvertently become subject to new policy<br>
> > language.<br>
> ><br>
> <br>
> If this policy doesn't gain consensus, I don't think it is necessary to put<br>
> the first sentence into policy separately, I agree it is a fairly obvious<br>
> thing to do. However, having it included in this policy makes it abundantly<br>
> clear that the second sentence doesn't somehow apply the resources<br>
> originally allocated from the 4.4 or 4.10 pools. Further, the second<br>
> sentence, as written, applies to "any other resource", and that phrasing<br>
> wouldn't make much sense without the first sentence.<br>
<br>
I support both in principle and the specific text, also notably <br>
to provide the insurance as indicated by the tail end of John's <br>
paragraph above.</blockquote><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">It would seem to make sense to clean up these pools all considered. </div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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</div><div><br></div><div>A little history; ARIN-2012-6 made an initial reservation of a /16 and ARIN-2014-21 increased the reservation to a /15.</div><div><a href="https://www.arin.net/vault/policy/proposals/2012_6.html" target="_blank">https://www.arin.net/vault/policy/proposals/2012_6.html</a></div><div><a href="https://www.arin.net/vault/policy/proposals/2014_21.html" target="_blank">https://www.arin.net/vault/policy/proposals/2014_21.html</a> </div><div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div>A little history; ARIN-2008-5 is what became NRPM Section 4.10.<br></div><div><a href="https://www.arin.net/vault/policy/proposals/2008_5.html" target="_blank">https://www.arin.net/vault/policy/proposals/2008_5.html</a><br></div><div><br></div><div>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.</div><div><br></div><div>Thanks.</div><div><br></div></div>-- <br><div dir="ltr">===============================================<br>David Farmer <a href="mailto:Email%3Afarmer@umn.edu" target="_blank">Email:farmer@umn.edu</a><br>Networking & Telecommunication Services<br>Office of Information Technology<br>University of Minnesota <br>2218 University Ave SE Phone: 612-626-0815<br>Minneapolis, MN 55414-3029 Cell: 612-812-9952<br>=============================================== </div></div>