[arin-ppml] Policy Proposal 122: Reserved Pool for Future Policy Development

[Owen DeLong]

On Nov 22, 2010, at 8:25 PM, Scott Leibrand wrote:

> It seems we have a couple of issues/questions around NRPM 4.10.  To
> help me (and hopefully others) think through the issue, let me see if
> I can identify several of them:
> 
> Q1: Should a reserved pool of addresses be reserved, and made
> available after free pool exhaustion, to support IPv6 transition?
> My answer would be yes, and I believe we have a strong consensus
> (expressed through the original adoption of 4.10, and in subsequent
> discussions) for this.
> 
Yes on both counts.


> Q2: Does NRPM 4.10 need to be updated at some point?
> Again, I think the answer is yes, and it seems we have quite a bit of
> community support for some kind of revisions.
> 
Yes, but, I think finding consensus on what kind of revisions will be quite
hard.

> Q3: Can we agree on how to update 4.10?
> Perhaps.  We seemed to have some points of general agreement, but the
> last proposal attempting a comprehensive rewrite of 4.10 failed.
> Perhaps smaller tweaks would do better, or new policy proposals (like
> 123).
> 
Agreed. In hindsight, I wish I had resisted the kitchen sink of ponies
approach that was advocated for that proposal by others, who
ended up opposing the proposal as a result.

> Q4: What should happen if we fail to reach consensus on any
> modifications to 4.10?  Should it expire at some point?

Probably not for a very long time, IMHO.

Certainly not within 5 years. And it shouldn't be unavailable to transitional
technologies during that time.

> This is where I think proposal 122 comes in:
> 
> IMO the solution proposed by 122, which is to revoke 4.10, reserve an
> equivalently sized block for one more policy cycle, and then return it
> to the free pool if nothing can be agreed upon, is a less desirable
> solution than the status quo.
> 
Agreed.

> I seem to recall some people doing the math on demand for space under
> 4.10, but I don't remember the results, so I'll give it another try.
> If we assume that every organization requesting space today will find
> a way to request space under 4.10, and somehow manages to qualify for
> the maximum number of space allowed under the policy, we can figure
> out how quickly the 4.10 reserved pool could be used up.  According to
> https://www.arin.net/knowledge/statistics/index.html, ARIN is
> currently processing <200 IPv4 address space requests per month.  So
> let's assume 2400 requests/year.  Since ISPs can get 1 year of space
> at a time today, let's assume that's ~2500 orgs actively requesting
> space, and let's assume that number doubles after exhaustion, to say
> 5000 orgs.  If each such org qualifies for a /24 every 6 months under
> 4.10, then it would take approximately 3 years to assign all of the
> space from the /10 reserved under 4.10.
> 
That's probably as good a guess as any and seems like about the right
target timeframe.

> So IMO our best course of action is to get together a number of minor
> tweaks that we think should be made to 4.10, and get them into the
> policy process ASAP.  If any of them get consensus, we should be able
> to adopt them before more than a small fraction of the 4.10 pool is
> used up.
> 
Works for me.

> I don't think it would be a good idea to put a near-term expiration
> date on the /10 reservation currently defined under 4.10.  I would be
> less opposed to simply suspending 4.10 for a few months while we
> discuss alternatives, but IMO that isn't really necessary given 4.10's
> /24 maximum allocation and one-allocation-every-6-months restriction.
> IMO it would actually be better to start using 4.10 upon exhaustion
> and use our implementation experience to inform future tweaks to the
> rules for using its reserved pool.
> 
Agreed.

Owen

> -Scott
> 
> On Mon, Nov 22, 2010 at 4:17 AM, Hannigan, Martin <marty at akamai.com> wrote:
>> 
>> 
>> 
>> On 11/20/10 1:27 AM, "William Herrin" <bill at herrin.us> wrote:
>> 
>>> On Fri, Nov 19, 2010 at 7:07 PM, Hannigan, Martin <marty at akamai.com> wrote:
>>>> I agree. My date was deliberate though. I don't want to drag this out to
>>>> Philly as we risk being exhausted by then.
>>> 
>>> Then don't. Close the window in August, well before Philly. Pick which
>>> meeting you want to be the last chance for community consensus and
>>> close the window just enough time later for a draft policy to have
>>> gone through last call and ratification. Don't drag the deadline out
>>> to the close of the following meeting.
>>> 
>> 
>> 
>> That makes sense. It coincides with AC and BoT elections too which I think
>> is a good thing with respect to this.
>> 
>> On a higher level, I've read two points that have little substance with
>> regards to why this proposal shouldn't move forward.
>> 
>> 1. 122 backdoors this to the freepool! Dangerous! Harmful! [handwave]
>> 
>> I had hoped that it would be clear that something has to be done to preserve
>> this in a manner that works for most if not all of us. The implication that
>> some would seem intent to actually battle this out to the point where we
>> would lose transition addresses is egregious. I think timing this to
>> coincide with AC elections is probably better. See below.
>> 
>> 2. What about the rationale in 2008-5?
>> 
>> What about it? That was over a year ago and several AC members have noted
>> that the policy is insufficient. Are we really going to let something this
>> important go forward in a half-baked manner?
>> 
>> Three people seem to be fixated on the expiration. I removed the CI argument
>> and I'm willing to remove that argument as well.
>> 
>> I could rewrite this to suspend 4.10 and upon expiry, re-implement. That
>> would seem to address all objections and allow for this to be fully
>> addressed at election time if need be.
>> 
>> 
>> Best,
>> 
>> -M<
>> 
>> 
>> 
>> 
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.