Policy Statement on Address Space Allocations

  > 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. 


Daniel