RE: The addition of guarded fields

["Wilfried Woeber, UniVie/ACOnet" <]

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