Re: [sig-policy] IPv4 countdown policy proposal
Ito-san,
On Feb 15, 2007, at 6:19 PM, Kosuke Ito wrote:
We have two choices here. 1) keep as is till the end we define, or
2) gradually narrow down to the end we fine. We need to define the
goal (or the end) of IPv4 allocation timing, anyway.
Do we?
Approach 2 requires another decision of when to apply the gradual
reduced allocation policy.
The idea behind approach 2 is that anyone can still request IPv4
address space if they meet the (increasingly stringent as the free
pool is reduced) requirements. It's sort of like Zeno's Paradox
(http://www.mathacademy.com/pr/prime/articles/zeno_tort/index.asp).
There is no need to set an arbitrary deadline.
To define the gradual level of what extent we need to reduce
should be the next step of issue, if we found that our current
proposed approach does not provide enough time range
for communities to shift into IPv6.
Perhaps I'm too cynical, but I believe that since IPv6 provides
insufficient benefit over IPv4 for folks to voluntarily shift, people
will not shift to IPv6 until they are forced to. By setting an
arbitrary deadline, particularly with setting aside blocks as
reserved, I suspect we'd be creating a very fertile ground for
"unpleasantness" and demands for changes in policy at the last second.
Humm, Increasing requirements means changing the policy, doesn't it?
Not if the increasing requirements are built into the policy (e.g.,
when 50% of the remaining address free pool as of date X is reached,
do Y. When 50% of that remaining free pool (or 75% of the original
free pool) is reached, do Z. Etc.)
One day, I apply a /16, Next day David apply a /16.
I got a full /16, but David got a 95% of /16.
I was thinking more of making the requirements more harsh, not what
is allocated, but I guess the end result is the same.
Is this under the same policy?
That's the idea.
Is this acceptable?
The alternative is on day X, I could get address space and on day X
+1, I couldn't. (I suspect I'd try really, really hard to get my
request approved by day X and since there would be a lot of people
like me, the registration services folks at APNIC are going to be
_really_ _really_ busy on days X-N to X).
Rgds,
-drc