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

[Owen DeLong]

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