<div dir="ltr"><div><br></div>Renamed to be more specific. <div><br></div><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 21, 2015 at 3:01 AM, David Farmer <span dir="ltr"><<a href="mailto:farmer@umn.edu" target="_blank">farmer@umn.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I think Section 4.10 (2008-5) is working as planed.<br>
<br>
<a href="https://www.arin.net/policy/proposals/2008_5.html" rel="noreferrer" target="_blank">https://www.arin.net/policy/proposals/2008_5.html</a><br>
<br>
The IPv4 free pool is now out and we still have a /10 for those that need some IPv4 for IPv6 deployments.  At least that much is a success. We would be far worse off without the /10. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Our community couldn't agree on reserving the whole last /8 like some of other RIRs did.  A /10 isn't enough for the same kind of last /8 policy that the other RIRs have, that is everyone gets a /22 or something like that.  It's really too late to change that now.<br></blockquote><div><br></div><div>It's not, but the prefix size could be (unfortunately) reduce to accomplish much of the same except not at the same scale in terms of utility.  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
However, we need to think hard about the current policy and if the details are correct now that the IPv4 free pool is gone and we actually need to make use of it.  I would love to hear experiences using and/or suggestions to improve section 4.10.  But, with only a /10 I'm going to be very leery of suggestions for use of the 4.10 reservation that are not directly tied to IPv6 deployment requirements.<br>
<br></blockquote><div><br></div><div>Well, there's at least 2 x use. :)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
If you want IPv4 for IPv4 sake there are transfers and the waiting list, and the waiting list isn't a reliable source of addresses, so that really only leaves transfers.<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><a href="mailto:hannigan@gmail.com" target="_blank"></a></span></blockquote></blockquote><div><br></div><div> </div><div>I'm well aware of how to get v4 addresses, but thanks. Watching the debate over the RIPE last /8 policy, it simple convinced me we were _wrong_.  And having networks go to RIPE for their last v4 allocation seems to be at odds with "out of region" use, which in itself is of questionable utility. The RIPE region could adjust their policies accordingly, but they seemed to have gotten it mostly right. Making new entry into the market easy-peasy without technical restrictions other than you need to use it seems more reasonable that what we have. The impact to v6 deployment overall is probably zero. And finally, it at least addresses the inequity that new entrants will have with those of us who are policy expects and know how to use the secret decoder ring e.g. "assigned" "provisioned" "get a new ORG ID" etc.</div><div><br></div><div>Best,</div><div><br></div><div>-M<</div><div><br></div><div><br></div></div></div></div></div>