<<< Chronological >>> Author Index    Subject Index <<< Threads >>>

Re: PI Policy Task Force: dead?

As nothing has been discussed so far, can I read this as "the current
PI policy isn't that bad after all, at least not bad enough to actually
change it"?
...or we are all overworked. The policy is in my opinion broken.
I agree that something is broken here.

My opinion is more that the underlying concept of PI space is broken,
I agree with you, but to fix that will take a long time and much effort.

I am mostly concerned that the current policy actually request the RIR
to hand out useless addresses. This will lead to a growth of the
routingtable of prefixes that most likely can not be used. The current
policy is simply not meaningful.

My suggestion is that we change the policy into something that will at
least produce useable prefixes.
I still fail to see an example of something that is:

- smaller than a /24
- not a root name server
- but needs PI space

You claim that the TLD name server "must have" its own PI block. I don't
understand why this is so. Other servers and clients all over the world
know the address of the TLD server by the glue record in the root, and
nothing is ever hardwired.
Ok, TLD servers are a bad example, not because I think they do not need portable space, but because the problem with changing glue-records are ore administrivia than anything else. As I am currently working for a IXP, getting address space is a problem. And no, IXPs don't always have a clear upstream provider. And I would not like to have to get one just to sort this out.

If you ("all of you") feel like there is need for a changed policy, please
formulate a specific proposal how the new policy should be. Maybe explain
the specific scenario behind it, and judge whether this is something which
is useful for the common good. Convenience for single operators is not a
good argument.

The TLD server issue a side, my main problem is that we have a policy that says we should hand out useless addresses.

- kurtis -

<<< Chronological >>> Author    Subject <<< Threads >>>