And then add an AS number (from guardian files) to network 1 and 2, and a different one to 3 and 4, and leave the rest as it is, will result in:

*in: 193.252.0.0 *na: FR-TELECOM-BLOCK-5 ...

*in: 193.252.1.0 - 193.252.2.0 *na: FR-TELECOM-BLOCK-5 *as: AS1104 ...

*in: 193.252.3.0 - 193.252.4.0 *na: FR-TELECOM-BLOCK-5 *as: AS786 ...

*in: 193.252.5.0 - 193.252.254.0 *na: FR-TELECOM-BLOCK-5 ...

And you end up with 3 separate *in: objects that share the same *na: I always thought this is illegal... But maybe I'm wrong.

This procedure works nicely but I still have some problems with this:

- its is VERY slow (and I do not know how to improve that) - I still do not like the idea of splitting up blocks that are managed by someone else

Well there are two sides to the game: -a you shouldn't mind changing someone else's data, if it is wellknown and it can be implemented in a very streightforward manner. I never regard my objects in the DB as my personal "hands off" property, but rather as shared info submitted to achieve a very well-defined and well-understood goal. -b when and if it is not easy to describe, understand and implement, and if the result would even possibly violate current rules, I'd propose to push the issue further down the tree to have it resolved.

- In oder to keep the database size under control, we should also implement generating blocks again from individual entries in the database, but then again I am fiddling with someone elses data, which I do not like at all ...

I'd appreciate getting a message proposing recombination of entries, or even a pre-fabricated message(s) to accomplish this. Then I would generate or just check/update these things and submit them as an update. Once again, for me it wouldn't be a privacy issue, but rather I like to know that things are going to change. It could point me even to a local problem. Wilfried.