This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
The addition of guarded fields
- Previous message (by thread): The addition of guarded fields
- Next message (by thread): The addition of guarded fields
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Wilfried Woeber, UniVie/ACOnet
woeber at cc.univie.ac.at
Tue Jul 27 13:27:44 CEST 1993
>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.
- Previous message (by thread): The addition of guarded fields
- Next message (by thread): The addition of guarded fields
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]