July 1993 - db-wg - mailman.ripe.net

Re: The addition of guarded fields
by farrache＠ccpnxt5.in2p3.fr 27 Jul '93

27 Jul '93

Marten, I think that the RIPE NCC have to split blocks. RIPE NCC is a neutral organisation that can do it without problems. If we do not agree on that, that means a very long procedure to update the guarded fields, and I believe that no service provider will want to rely on the efficiency of a NIC for its routing policy. So that mean that nobody will use those fields for routing, so the information may be completly out of date. But I agree with Blasco on one point, the maintainer of the block must be inform that the block has been splitted Gilles

3 2

Re: Unique NIC/RIPE/xxx-Handles
by scottw＠internic.net 27 Jul '93

27 Jul '93

If a centalized number is important we have completed and are testing software that will allow other NICs to get InterNIC handles for their users. Access to the InterNIC handle generator will be controled by the source address of the host requesting the handle. I strongly beleive that handle generation below the regional registry would be dangerous. To resurve a handle we only require the name and email address. Scott

1 0

The addition of guarded fields
by Marten Terpstra 27 Jul '93

27 Jul '93

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

2 1

RE: The addition of guarded fields
by Wilfried Woeber, UniVie/ACOnet 27 Jul '93

27 Jul '93

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

2 1

Re: The addition of guarded fields
by Marten Terpstra 27 Jul '93

27 Jul '93

Dave Morton <Dave.Morton(a)ecrc.de> writes * Marten, * No big help I know - this looks messy and a real nasty can of * worms. Mabye the db needs a whole new type of object for these * damm blocks, other than that I don't see any real way out ! ? * Dave Maybe you are right, but right now I would not have any idea how to do so. If have even been thinking of putting all the guarded fields in some other object, which has just the network number and the guarded fields, and no other information. by querying the database one would get the normal output and an extra object with the network number and all its guarded values. In this extra object, no blocks would be allowed ... -Marten PS CCed to routing and db-wg, because this may be a solution.

1 0

Re: Unique NIC/RIPE/xxx-Handles
by Duncan Rogerson 27 Jul '93

27 Jul '93

> handle: XXXXYYY(a)ncc.ripe.net .. > etc.? Or, if that might confuse NIC handles with email addresses, > replacing the @ with another character? I think having something that looks like an e-mail address is a bad idea, it's too confusing. Given that one of the aims of handles is (I think !) a more compact, shorthand form of referring to someone, the RIPE-DR222 idea sounds better to me - DR222(a)rs.internic.net is longer than my real name ! Dunc

1 0

Re: Unique NIC/RIPE/xxx-Handles
by Wilfried Woeber, UniVie/ACOnet 27 Jul '93

27 Jul '93

| * Given that one of the aims of handles is (I think !) a more | * compact, shorthand form of referring to someone, the RIPE-DR222 | * idea sounds better to me - DR222(a)rs.internic.net is longer than | * my real name ! | |I have to agree here. I think a nice syntax would be: | |<NIC>-XXXYYY | |where it is probably is too much hastle to ask InterNIC to redo all their |nic-hdls to have INTERNIC-XXXYYY, so they probably keep the handles without |the NIC. The others could be: | |RIPE-MT2 |APNIC-MT2 |... My original reasoning was something like: Keep the InterNIC-Handles as they are, ie. when there is no NIC-ID, then let's assume it is InterNIC. For the others, tag them. For the DataBase, store everything without a (external) tag with an (internal) InterNIC tag. Also, I think it is really not necessary - maybe not even useful? - for people to obtain more than one handle. However if someone is hit by that, or even wants it :-), we could probably live (DataBase-wise) with a definition of (REQUIRED, MULTIPLE, UNIQUE). (Marten: could the DB-SW digest this?) |Question is, to what level do we go down for the NIC ? Should we go down to | |DENIC-MT2 |JANET-MT2 | |I don;t think so. My sense of NIC for the handles should be the highest level |IP number authorities in the area .... (ie continents) I think the question is, by whom and where these handles are dished out. My personal preference is to have this done at the highest possible level, ie. RIPE-NCC, APNIC, etc... Unfortunately, until now there have not been any contributions to this aspects. Regards, Wilfried.

2 1

Re: Unique NIC/RIPE/xxx-Handles
by Duncan Rogerson 26 Jul '93

26 Jul '93

> Please remember that there are more than 2 NIC's handing out handles > and there will likely be more in the future. JPNIC (nic.ad.jp) > currently does so, as will (I suspect) the APNIC. Granted, it is So it makes sense to have a single handle: field and have the assigning agency identified by a prefix on the handle ? Dunc

2 1

Re: Unique NIC/RIPE/xxx-Handles
by Duncan Rogerson 26 Jul '93

26 Jul '93

> One of the ideas we talked about was to go to a structure like > > NIC-XY999 (derived from the current NIC-Handles by prepending NIC-) > RIPE-XY999 (newly assigned within the RIPE community) So you end up with data like : person: Duncan Rogerson . . handle: NIC-DR222 handle: RIPE-DR001 (assuming multiple handle: fields are permitted, to cope with people who for one reason or another have both types of handle). or person: A Person . . handle: RIPE-AP001 .. in the database ? Or should the name of the field distinguish between RIPE and NIC handles - ie the person object can have two fields, nic-hdl: and ripe-hdl: to cope with people who end up with a handle of each type. Dunc

2 1

Unique NIC/RIPE/xxx-Handles
by Wilfried Woeber, UniVie/ACOnet 23 Jul '93

23 Jul '93

Dear DB-folks, during the IETF we (Daniel K, Ruediger V and me) had a short ad-hoc meeting and identified some aspects of the RIPE-DB business that should be addressed and discussed. One of them, and quite urgently needed is to agree on structure and procedures to obtain unique handles for people who do not (yet) have NIC handles. One of the ideas we talked about was to go to a structure like NIC-XY999 (derived from the current NIC-Handles by prepending NIC-) RIPE-XY999 (newly assigned within the RIPE community) Reudiger even thought about adding even more structure like RIPE-Provider_ID-XY999, or RIPE-XY999-Provider_specific... The issue here is whether we want to have the Provider_ID as part of the hierarchy tree. My personal preference is the RIPE-XY999[-optional-Provider_specific...] format, the handle being unique without the Provider part. Another question is where and how to register/assign these handles. One possibility could be to have this as a service from and at the NCC, say assigned by some script. A Different approach would be to assign them somehow at the Local-IRs. Could you please comment on these? I'd like to have some form of consensus ready for approval at the next RIPE meeting. Best regards, Wilfried.

1 0