[arin-ppml] Policy Proposal 122: Reserved Pool for FuturePolicy Development
BillD at cait.wustl.edu
Mon Nov 22 10:59:58 EST 2010
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.
> -----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
> >> 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!
> > 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?
> 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:
> Please contact info at arin.net if you experience any issues.
More information about the ARIN-PPML