- db-wg - mailman.ripe.net

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 27 Jul '93

27 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

Re: EU.net and eu.net database entries
by RIPE NCC Staff 23 Jul '93

23 Jul '93

Piet.Beertema(a)mcsun.EU.net writes: * A day or so ago I submitted a new entry for the EU.net domain, * meant to be a change on the current entry. However, I denoted * it as "EU.net" (which is the official name) instead of eu.net. * Now it appears that the updating software saw this as a *new* * entry rather than an update, in other words it doesn't work * case-independent. On the other hand the database query s/w * does work case-independent, so "whois eu.net" now gives me * two entries... * Could you remove the old eu.net entry? I dare not submit a * change for it to get it deleted, in case the updating s/w * decides to start working case-independent in that case... Sorry Piet, old, old, old software ... The new software will take care of this, but I think the new software will change everything to lowercase. I have not written this part yet, have to put some thought in it though. Anyone in the database working group has any feeling how these should be dealt with ? From a programming point of view, handling everything lowercase is much easier, I do not really want to check every single combination of lower/uppercase before I update something ... Then again, after some thinking (I usually type faster than I think ;-) the indexing is done in lowercase, and key lookups are always normalized to lowercase before a lookup. So the real question is, should entries in the database be left untouched when it comes to upper/lowercase, or should all be normalized ? -Marten

2 1

Re: EU.net and eu.net database entries
by craig＠icm1.icp.net 23 Jul '93

23 Jul '93

> (I usually type faster than I think ;-) the indexing is done in lowercase, > and key lookups are always normalized to lowercase before a lookup. > > So the real question is, should entries in the database be left untouched > when it comes to upper/lowercase, or should all be normalized ? since all is normalized to lowercase before a lookup i think it is OK to have the database show things in capital letters as long as everyone knows all is treated as lowercase. summary: o view as is stored in the database o normalize before performing other operations on the database. craig

1 0