<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div><br></div><div>Hi Karl, </div><div><br></div><div>Just throwing it out there. My personal opinion is that the v6 deployment /10 is a failure and an economic limiter for new entrants and could be rethought. </div><div><br></div><div>Best, </div><div><br></div><div>-M<</div><div><br>On Oct 20, 2015, at 20:12, Karl Brumund <<a href="mailto:kbrumund@dyn.com">kbrumund@dyn.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">Martin,<div>I'm unsure what the problem is that you're trying to solve. I'm guessing it's `let anybody new get a /24` so they have a chance for some v4 space. Or maybe its have ARIN be the same as other regions (though I'd say the transfer process is a bigger fish for that).</div><div>You mentioned 'reasonable and fair'. Could you elaborate a bit, as I think I'm not caffinated enough to follow.</div><div><br></div><div>Thanks!</div><div>...karl</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 20, 2015 at 2:03 PM, Martin Hannigan <span dir="ltr"><<a href="mailto:hannigan@gmail.com" target="_blank">hannigan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div>That was 2014. It is now near 2016. Then, we were not exhausted. Now, we are. </div><div><br></div><div>Here's the RIPE policy bits</div><div><br></div><div>    <a href="https://www.ripe.net/publications/docs/ripe-649" target="_blank">https://www.ripe.net/publications/docs/ripe-649</a><br></div><div><br></div><div>Here's the ARIN policy:</div><div><br></div><div>    <a href="https://www.arin.net/policy/nrpm.html" target="_blank">https://www.arin.net/policy/nrpm.html</a> (Section 4.10)</div><div><br></div><div>A brief summary. </div><div><br></div><div>The RIPE policy is liberal in that every LIR (new or old) gets a /22. The ARIN policy is restrictive and digs into the same old noise around needs and transfer. </div><div><br></div><div>We _could_ narrow this to new entrants (which does pose an antitrust question).</div><div><br></div><div>We _could_ also direct that incoming IANA bits be redirected to new entrants as well up to the equivalent of a /8 to be parallel to other regions, but I'm not sure we need a limit although.</div><div><br></div><div>We _could_ limit the size of the allocation to no longer shorter than a /24.</div><div><br></div><div><br></div><div>Best,</div><div><br></div><div>-M<</div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 20, 2015 at 5:38 PM, 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"><div dir="auto"><div>The ARIN community previously considered these ideas under 2014-16, but changing the /10 to something other than transition never had sufficient support for the AC to move it forward.</div><div><br></div><div><a href="https://www.arin.net/policy/proposals/2014_16.html" target="_blank">https://www.arin.net/policy/proposals/2014_16.html</a><span><font color="#888888"><br><br>.Andrew</font></span></div><div><div><div><br>On Oct 20, 2015, at 5:35 PM, Morizot Timothy S <<a href="mailto:Timothy.S.Morizot@irs.gov" target="_blank">Timothy.S.Morizot@irs.gov</a>> wrote:<br><br></div><blockquote type="cite"><div><span>Thanks for the clarifications. In that context, assuming a new entrant is deploying IPv6, wouldn't the current policy allow them to request allocations to support that deployment. It specifically mentions needs like dual-stacked nameservers and various IPv4 life extension solutions. If a new entrant *isn't* deploying IPv6 from the start, do we really want to support them with a free pool allocation? For any needs beyond those described in the policy, there's the transfer market. I don't know that I have particularly strong feelings either way, but if we're going to reserve any general use pool at all rather than simply handing it all out to meet current need, I think it's better to tie it to demonstrated IPv6 deployment.</span><br><span></span><br><span>Scott</span><br><span></span><br><span>-----Original Message-----</span><br><span>From: <a href="mailto:arin-ppml-bounces@arin.net" target="_blank">arin-ppml-bounces@arin.net</a> [<a href="mailto:arin-ppml-bounces@arin.net" target="_blank">mailto:arin-ppml-bounces@arin.net</a>] On Behalf Of Spears, Christopher M.</span><br><span>Sent: Tuesday, October 20, 2015 10:21 AM</span><br><span>To: Hadenfeldt, Andrew C</span><br><span>Cc: <a href="mailto:arin-ppml@arin.net" target="_blank">arin-ppml@arin.net</a></span><br><span>Subject: Re: [arin-ppml] Transition /10</span><br><span></span><br><span>NRPM 4.10 [1] dedicated /10 for IPv6 "transition"..</span><br><span></span><br><span>I tossed a similar idea around with some folks at ARIN36.   Use this /10 to allocate a /24 per **new** Org, and steer subsequent transactions to transfers.   That would ensure IPv4 for ~16K **new** entrants in the coming years..   </span><br><span></span><br><span>[1] <a href="https://www.arin.net/policy/nrpm.html#four10" target="_blank">https://www.arin.net/policy/nrpm.html#four10</a></span><br><span></span><br><span>_______________________________________________</span><br><span>PPML</span><br><span>You are receiving this message because you are subscribed to</span><br><span>the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).</span><br><span>Unsubscribe or manage your mailing list subscription at:</span><br><span><a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a></span><br><span>Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.</span><br></div></blockquote></div></div></div><br>_______________________________________________<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" target="_blank">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" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<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" rel="noreferrer" 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.<br></blockquote></div><br></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>PPML</span><br><span>You are receiving this message because you are subscribed to</span><br><span>the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).</span><br><span>Unsubscribe or manage your mailing list subscription at:</span><br><span><a href="http://lists.arin.net/mailman/listinfo/arin-ppml">http://lists.arin.net/mailman/listinfo/arin-ppml</a></span><br><span>Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.</span></div></blockquote></body></html>