<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7654.12">
<TITLE>RE: [arin-ppml] Policy Proposal 122: Reserved Pool for FuturePolicy Development</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>
<P><FONT SIZE=2>+1 on these comments and crumbs suggestion.<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: arin-ppml-bounces@arin.net on behalf of Owen DeLong<BR>
Sent: Tue 11/23/2010 12:36 AM<BR>
To: Scott Leibrand<BR>
Cc: arin-ppml@arin.net<BR>
Subject: Re: [arin-ppml] Policy Proposal 122: Reserved Pool for FuturePolicy Development<BR>
<BR>
<BR>
On Nov 22, 2010, at 8:25 PM, Scott Leibrand wrote:<BR>
<BR>
> It seems we have a couple of issues/questions around NRPM 4.10. To<BR>
> help me (and hopefully others) think through the issue, let me see if<BR>
> I can identify several of them:<BR>
><BR>
> Q1: Should a reserved pool of addresses be reserved, and made<BR>
> available after free pool exhaustion, to support IPv6 transition?<BR>
> My answer would be yes, and I believe we have a strong consensus<BR>
> (expressed through the original adoption of 4.10, and in subsequent<BR>
> discussions) for this.<BR>
><BR>
Yes on both counts.<BR>
<BR>
<BR>
> Q2: Does NRPM 4.10 need to be updated at some point?<BR>
> Again, I think the answer is yes, and it seems we have quite a bit of<BR>
> community support for some kind of revisions.<BR>
><BR>
Yes, but, I think finding consensus on what kind of revisions will be quite<BR>
hard.<BR>
<BR>
> Q3: Can we agree on how to update 4.10?<BR>
> Perhaps. We seemed to have some points of general agreement, but the<BR>
> last proposal attempting a comprehensive rewrite of 4.10 failed.<BR>
> Perhaps smaller tweaks would do better, or new policy proposals (like<BR>
> 123).<BR>
><BR>
Agreed. In hindsight, I wish I had resisted the kitchen sink of ponies<BR>
approach that was advocated for that proposal by others, who<BR>
ended up opposing the proposal as a result.<BR>
<BR>
> Q4: What should happen if we fail to reach consensus on any<BR>
> modifications to 4.10? Should it expire at some point?<BR>
<BR>
Probably not for a very long time, IMHO.<BR>
<BR>
Certainly not within 5 years. And it shouldn't be unavailable to transitional<BR>
technologies during that time.<BR>
<BR>
> This is where I think proposal 122 comes in:<BR>
><BR>
> IMO the solution proposed by 122, which is to revoke 4.10, reserve an<BR>
> equivalently sized block for one more policy cycle, and then return it<BR>
> to the free pool if nothing can be agreed upon, is a less desirable<BR>
> solution than the status quo.<BR>
><BR>
Agreed.<BR>
<BR>
> I seem to recall some people doing the math on demand for space under<BR>
> 4.10, but I don't remember the results, so I'll give it another try.<BR>
> If we assume that every organization requesting space today will find<BR>
> a way to request space under 4.10, and somehow manages to qualify for<BR>
> the maximum number of space allowed under the policy, we can figure<BR>
> out how quickly the 4.10 reserved pool could be used up. According to<BR>
> <A HREF="https://www.arin.net/knowledge/statistics/index.html">https://www.arin.net/knowledge/statistics/index.html</A>, ARIN is<BR>
> currently processing <200 IPv4 address space requests per month. So<BR>
> let's assume 2400 requests/year. Since ISPs can get 1 year of space<BR>
> at a time today, let's assume that's ~2500 orgs actively requesting<BR>
> space, and let's assume that number doubles after exhaustion, to say<BR>
> 5000 orgs. If each such org qualifies for a /24 every 6 months under<BR>
> 4.10, then it would take approximately 3 years to assign all of the<BR>
> space from the /10 reserved under 4.10.<BR>
><BR>
That's probably as good a guess as any and seems like about the right<BR>
target timeframe.<BR>
<BR>
> So IMO our best course of action is to get together a number of minor<BR>
> tweaks that we think should be made to 4.10, and get them into the<BR>
> policy process ASAP. If any of them get consensus, we should be able<BR>
> to adopt them before more than a small fraction of the 4.10 pool is<BR>
> used up.<BR>
><BR>
Works for me.<BR>
<BR>
> I don't think it would be a good idea to put a near-term expiration<BR>
> date on the /10 reservation currently defined under 4.10. I would be<BR>
> less opposed to simply suspending 4.10 for a few months while we<BR>
> discuss alternatives, but IMO that isn't really necessary given 4.10's<BR>
> /24 maximum allocation and one-allocation-every-6-months restriction.<BR>
> IMO it would actually be better to start using 4.10 upon exhaustion<BR>
> and use our implementation experience to inform future tweaks to the<BR>
> rules for using its reserved pool.<BR>
><BR>
Agreed.<BR>
<BR>
Owen<BR>
<BR>
> -Scott<BR>
><BR>
> On Mon, Nov 22, 2010 at 4:17 AM, Hannigan, Martin <marty@akamai.com> wrote:<BR>
>><BR>
>><BR>
>><BR>
>> On 11/20/10 1:27 AM, "William Herrin" <bill@herrin.us> wrote:<BR>
>><BR>
>>> On Fri, Nov 19, 2010 at 7:07 PM, Hannigan, Martin <marty@akamai.com> wrote:<BR>
>>>> I agree. My date was deliberate though. I don't want to drag this out to<BR>
>>>> Philly as we risk being exhausted by then.<BR>
>>><BR>
>>> Then don't. Close the window in August, well before Philly. Pick which<BR>
>>> meeting you want to be the last chance for community consensus and<BR>
>>> close the window just enough time later for a draft policy to have<BR>
>>> gone through last call and ratification. Don't drag the deadline out<BR>
>>> to the close of the following meeting.<BR>
>>><BR>
>><BR>
>><BR>
>> That makes sense. It coincides with AC and BoT elections too which I think<BR>
>> is a good thing with respect to this.<BR>
>><BR>
>> On a higher level, I've read two points that have little substance with<BR>
>> regards to why this proposal shouldn't move forward.<BR>
>><BR>
>> 1. 122 backdoors this to the freepool! Dangerous! Harmful! [handwave]<BR>
>><BR>
>> I had hoped that it would be clear that something has to be done to preserve<BR>
>> this in a manner that works for most if not all of us. The implication that<BR>
>> some would seem intent to actually battle this out to the point where we<BR>
>> would lose transition addresses is egregious. I think timing this to<BR>
>> coincide with AC elections is probably better. See below.<BR>
>><BR>
>> 2. What about the rationale in 2008-5?<BR>
>><BR>
>> What about it? That was over a year ago and several AC members have noted<BR>
>> that the policy is insufficient. Are we really going to let something this<BR>
>> important go forward in a half-baked manner?<BR>
>><BR>
>> Three people seem to be fixated on the expiration. I removed the CI argument<BR>
>> and I'm willing to remove that argument as well.<BR>
>><BR>
>> I could rewrite this to suspend 4.10 and upon expiry, re-implement. That<BR>
>> would seem to address all objections and allow for this to be fully<BR>
>> addressed at election time if need be.<BR>
>><BR>
>><BR>
>> Best,<BR>
>><BR>
>> -M<<BR>
>><BR>
>><BR>
>><BR>
>><BR>
>> _______________________________________________<BR>
>> PPML<BR>
>> You are receiving this message because you are subscribed to<BR>
>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).<BR>
>> Unsubscribe or manage your mailing list subscription at:<BR>
>> <A HREF="http://lists.arin.net/mailman/listinfo/arin-ppml">http://lists.arin.net/mailman/listinfo/arin-ppml</A><BR>
>> Please contact info@arin.net if you experience any issues.<BR>
>><BR>
> _______________________________________________<BR>
> PPML<BR>
> You are receiving this message because you are subscribed to<BR>
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).<BR>
> Unsubscribe or manage your mailing list subscription at:<BR>
> <A HREF="http://lists.arin.net/mailman/listinfo/arin-ppml">http://lists.arin.net/mailman/listinfo/arin-ppml</A><BR>
> Please contact info@arin.net if you experience any issues.<BR>
<BR>
_______________________________________________<BR>
PPML<BR>
You are receiving this message because you are subscribed to<BR>
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).<BR>
Unsubscribe or manage your mailing list subscription at:<BR>
<A HREF="http://lists.arin.net/mailman/listinfo/arin-ppml">http://lists.arin.net/mailman/listinfo/arin-ppml</A><BR>
Please contact info@arin.net if you experience any issues.<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>