<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Mar 11, 2014 at 11:09 AM, Andrew Dul <span dir="ltr"><<a href="mailto:andrew.dul@quark.net" target="_blank">andrew.dul@quark.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">For those who are concerned about making sure these types of blocks are<br>
available in the future, there are two other avenues which could be<br>
explored beyond what is proposed in this policy.<br>
<br>
1. Increase the size of reserved block which ARIN is holding for<br>
micro-allocations.<br></blockquote><div><br></div><div>We put "new GTLD" operators back in the general pool, so I don't think we need to reserve more space.  If we're still needing IPv4 for IXPs when the current reserved block runs out, we could probably replenish it from returns, or just let them get on the waiting list or get space via transfer like everyone else.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2. Remove the /24 minimum for IXP allocations.  Since there is no<br>
technical reason to have an IXP block be a /24 and the operational best<br>
practice is to not route these blocks we could look at "right sizing"<br>
IXP blocks rather giving a very small IXPs a rather large block for what<br>
they need.  Yes, this brings up the possible renumbering issue in the<br>
future, but a /25 or /26 still allows quite a number of IXP participants.<br></blockquote><div><br></div><div>I'd be fine with removing the /24 minimum for IXP allocations, particularly since they're not globally routed.</div>
<div><br></div><div>-Scott</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Do operators have any thoughts on these ideas?<br>
<br>
Thanks,<br>
Andrew<br>
<div class="im HOEnZb"><br>
On 3/10/2014 12:56 PM, Steven Ryerse wrote:<br>
> I agree there is no downside keeping it as it is.  We ought to be making it easier not harder wherever we can.  I'm against changing it as well.<br>
><br>
> Steven Ryerse<br>
> President<br>
> 100 Ashford Center North, Suite 110, Atlanta, GA  30338<br>
> <a href="tel:770.656.1460" value="+17706561460">770.656.1460</a> - Cell<br>
> <a href="tel:770.399.9099" value="+17703999099">770.399.9099</a>- Office<br>
><br>
> ℠ Eclipse Networks, Inc.<br>
>                      Conquering Complex Networks℠<br>
><br>
><br>
> -----Original Message-----<br>
> From: <a href="mailto:arin-ppml-bounces@arin.net">arin-ppml-bounces@arin.net</a> [mailto:<a href="mailto:arin-ppml-bounces@arin.net">arin-ppml-bounces@arin.net</a>] On Behalf Of Brandon Ross<br>
> Sent: Monday, March 10, 2014 3:51 PM<br>
> To: Scott Leibrand<br>
> Cc: <a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a><br>
> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 MicroAllocation Conservation Update - Revised<br>
><br>
> On Mon, 10 Mar 2014, Scott Leibrand wrote:<br>
><br>
>> Any reason two small rural players shouldn't start with a PA /30 and<br>
>> renumber into a larger block if/when they get a third participant?<br>
> Yes, renumbering is hard.  Renumbering is even harder for rural entities that don't have tons of high end network engineers around.  It's hard enough for rural service providers to pool enough funds to buy a switch and stand up an IX, discouraging them from building additional interconnectivity by making it difficult to get IP addresses is disappointing.<br>

><br>
> On the other hand, there is absolutely no downside to keeping the requirement the way it is.  Changing it does nothing for conservation of<br>
> IPv4 addresses at all, as any dishonest players won't have a harder time at all faking 3 entities as compared to 2.<br>
><br>
<br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.</div></div></blockquote></div><br></div></div>