<html><body bgcolor="#FFFFFF"><div>Well, another approach would be to reconsider all of section 4 in light of the fact that very shortly the only way it will be applied is to transfers, or to a trickle of returned space going against the waiting list. When looked at from that point of view, I think most of section 4 starts to look somewhat dated.</div>
<div><br></div><div>For example, in a post-depletion world, does it make sense to require that an ISP use a /20 or /22 of PA space before getting their own space via transfer? What about when most ISPs are doing something like NAT64 or DS-Lite and only need a /23 to serve their entire customer base? Should they be blocked from transferring such a block because it's not big enough?</div>
<div><br></div><div>Again, I'm not arguing that we need to change (or "throw out") all of NRPM section 4 at this point. I'm just pointing out that a lot of our restrictions start making a lot less sense in a world of address scarcity that they did when they were first passed, so we need to start thinking about how to keep up with the necessary changes and avoid applying anachronistic rules if they're no longer needed. I think we're doing a good job of rewriting and simplifying IPv6 policy to reflect such realities, and anticipate that we'll need to start simplifying IPv4 policy for a post-depletion world as well.<br>
<br>Scott</div><div><br>On May 2, 2011, at 4:26 PM, Owen DeLong <<a href="mailto:owen@delong.com">owen@delong.com</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div>I disagree entirely.<div><br></div><div>
Transfers, if they are to be permitted, should be done with the recipient required to meet</div><div>exactly the same justifications as those under section 4.</div><div><br></div><div>I see the 3-month timeframe as a temporary abomination to section 4, necessary because</div>
<div>of special circumstances of runout.</div><div><br></div><div>Throwing out the rest of section 4 because of it is absurd.</div><div><br></div><div>Owen</div><div><br></div><div><div><div>On May 2, 2011, at 2:23 PM, Scott Leibrand wrote:</div>
<br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote">On Mon, May 2, 2011 at 2:04 PM, Matthew Kaufman <span dir="ltr"><<a href="mailto:matthew@matthew.at"><a href="mailto:matthew@matthew.at">matthew@matthew.at</a></a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>Agree. Yet again we have a problem where the needs justification for using the very last of ARIN's free pool should be totally different than the needs justification for being the recipient of an expensive resource transfer via specified transfer, and yet it isn't.</div>
<br>
Can't fix the one without breaking the other in this case... or agreeing that needs justification for transfers needs fixing. (One of my proposals today that hasn't received comment yet covers the issue that new recipients can only get 3 months via specified transfer, given the current text, for instance.)</blockquote>
<div><br></div><div>I have that one on my list to respond to. IMO we should be moving away from having 8.3 requirements depend on section 4 requirements, and instead move toward copying the necessary requirements to section 8, which whatever modifications (like 24 months) are more appropriate for transfers. But that is a bit of a project, which I don't have time for just yet. :-)</div>
<div><br></div><div>-Scott</div></div>
_______________________________________________<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"><a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a></a>).<br>
Unsubscribe or manage your mailing list subscription at:<br><a href="http://lists.arin.net/mailman/listinfo/arin-ppml"><a href="http://lists.arin.net/mailman/listinfo/arin-ppml">http://lists.arin.net/mailman/listinfo/arin-ppml</a></a><br>
Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.</blockquote></div><br></div></div></blockquote></body></html>