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

[Bill Darte]

Or one could simply require a periodic review of the utility being
served by 4.10 and redirect use of those addresses as befits the current
'on the ground' reality.

bd 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong
> Sent: Monday, November 22, 2010 9:40 AM
> To: Hannigan, Martin
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal 122: Reserved Pool 
> for FuturePolicy Development
> 
> 
> On Nov 22, 2010, at 4:17 AM, Hannigan, Martin 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.
> > 
> Really? Ad hominum already?
> 
> > 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.
> > 
> 
> The problem is that you are changing the default. The current 
> default if we don't come to consensus on something else is to 
> keep the addresses in a transition pool used for certain 
> high-user-ratio transitional technologies.
> 
> If we enact proposal 122, the default becomes to toss these 
> addresses back into the free pool unless we somehow pass a 
> policy which is likely to be very contentious in nature. 
> Since a policy won't pass unless it has relatively broad 
> consensus, it virtually guarantees that something this 
> contentious will fall back to the non-consensus default 
> behavior, especially on such a tight deadline.
> 
> For example, I expect this to be no less contentious than the 
> idea of making end user assignments as small as /24 
> available. Look at the number of different proposals that 
> were submitted and the number of years that it took to 
> finally arrive at a policy which reached consensus.
> 
> I'm sorry, but, I do not think it is without substance to say 
> that consensus on a new policy in the timeframe you have 
> specified is unlikely and changing the default to try and 
> force the community to accept whatever is the least 
> objectionable option available in that short window or toss 
> things back to the free pool is, IMHO, dangerous and far from 
> good stewardship.
> 
> Timing it to coincide with the AC and BoT election cycle is 
> even more cynically manipulative of the process IMHO.
> 
> > 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?
> > 
> If you have a better concrete proposal to improve 4.10, 
> please present it and let's discuss it. However, tossing 4.10 
> out for something non-baked in order to try and drive a new 
> process is a giant leap in the wrong direction.
> 
> > 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.
> > 
> What about people who need transitional space for that 
> intended purpose in the meantime?
> 
> If you want to do this, how about setting aside an additional 
> /10 for that TBD purpose and returning it to the free pool 
> upon expiry instead?
> 
> Owen
> 
> _______________________________________________
> 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.
>