The addition of guarded fields
People, I need your help on an implementation issue. I am working on the addition of guarded fields, and especially on the splitting of blocks in case some nets inside a block get different guarded fields than others. What I have implemented currently is that a block will be split into biggest possible parts containing the same guarded information, so for instance: inetnum: 193.252.0.0 - 193.252.254.0 netname: FRANCE-TELECOM-BLOCK-5 ... 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 ... 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 - 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 ... Could we get some opinions ? -Marten
---Marten writes:
People,
I need your help on an implementation issue. I am working on the addition of guarded fields, and especially on the splitting of blocks in case some nets inside a block get different guarded fields than others. What I have implemented currently is that a block will be split into biggest possible parts containing the same guarded information, so for instance:
inetnum: 193.252.0.0 - 193.252.254.0 netname: FRANCE-TELECOM-BLOCK-5 ...
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 ...
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 - 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 ...
Could we get some opinions ?
-Marten
I do not agree about someone else data modification. I think the NCC should do the following: 1-inform anyone who asks for a block of networks that if different guarded fields are needed in the future then splitted blocks have to be registered. 2-only the same people who has registered the block can request the splitting. 3-inforce the above rules in database registration software. ---------- ---------- Antonio_Blasco Bonito E-Mail: bonito@nis.garr.it GARR - Network Information Service c=it;a=garr;p=garr;o=nis;s=bonito c/o CNUCE - Istituto del CNR Tel: +39 (50) 593246 Via S. Maria, 36 Telex: 500371 CNUCE I 56126 PISA Italy Fax: +39 (50) 904052 ---------- ----------
bonito@nis.garr.it (Antonio_Blasco Bonito) writes * * I do not agree about someone else data modification. I think the NCC should * do the following: * 1-inform anyone who asks for a block of networks that if different guarded * fields are needed in the future then splitted blocks have to be registered * . * 2-only the same people who has registered the block can request the splittin * g. * 3-inforce the above rules in database registration software. If I read this correctly you agree with me that the software should NOT automatically split network blocks. The only problem here is that someone else (ie the guardian of a guarded field) defined the guarded fields, and he/she is not necessarily the maintainer of the data. Therefore we have a conflict where parts of the data in an object are maintained by different persons. I like the idea of NOT automatically splitting objects (and not only from an implementers point of view ;-) but reporting back to the guardian and the last "changer" of an object, that in order to add the guarded fields, the object must be split, and have them solve the matter among themselves. The NCC would then simply deny that addition of guarded fields. -Marten
participants (2)
-
bonito＠nis.garr.it -
Marten Terpstra