Policy Statement on Address Space Allocations
Daniel.Karrenberg at ripe.net
Fri Jan 26 18:24:07 UTC 1996
> Sean Doran <smd at cesium.clock.org> writes:
> | Now can we try to make things work rather than point fingers!
> Yes, indeed; that is the ultimate goal we share.
Pooooh .... relief.
> We just have some differences of philosophy -- you think
> that RIPE really can persuade people into having only
> 1024 announements (preferably far fewer) in 195/8, and
> I don't. That's all.
OK. I call this a challenge but you won't let me try ;-).
> The compromise we could find would involve a practicable
> method by which we don't have to put a prefix-length-floor
> in place, but at the same time don't have to spend enormous
> amounts of (unavailable) CPU time filtering based on what's
> in the RIPE database.
All I am suggesting is to set it at /19 initially which should consume
roughly ;-) as many CPU time as setting it to /18.
Should we fail to meet the challenge later, I suggest to set it to /18
and allow some /19 exceptions caused by our allocation policy. This
will be a quite limited number, the information will be machine readable
in real time. We will provide the tools (3 lines perl) to generate
filters from it.
Frankly: If you cannot do this your motives become quite questionable.
> Avoiding large amounts of (largely unavailable) staff time
> at Sprint and RIPE to chase down offenders and try to figure
> out how to stop them from ignoring their contribution to
> melting routers is also something I'd like to avoid.
It is not as big a deal as you want to make it.
More information about the NANOG