- db-wg - mailman.ripe.net

doc update for the (new) RIPE DB-Software
by Wilfried Woeber, UniVie/ACOnet 01 Sep '93

01 Sep '93

Dear DB-interested folks, according to action 15.11 on me from the 15th RIPE meeting, and as the beta test phase for the new DB-Software is making good progress, we have to agree on the structure, contents and production of new or updated documentation as well. Thus I ask all of you to contribute to this discussion on the DB-WG list. A copy of this is also sent to the Local-IR list FYI, however I propose to have the real discussion going on on th DB-WG list. Amongst other things, I think we should agree on - what is the intended audience for the doc? - what is a good structure? - who should contribute and how/when do we produce the paper(s) Regards, Wilfried. ------------------------------------------------------------------------------- Wilfried Woeber : Wilfried.Woeber(a)CC.UniVie.ac.at (Internet) Computer Center - ACOnet : Z00WWR01(a)AWIUNI11.BITNET (EARN) Vienna University : 29133::WOEBER (SPAN/HEPnet) Universitaetsstrasse 7 : Tel: +43 1 436111 355 A-1010 Vienna, Austria, Europe : Fax: +43 1 436111 170 NIC: WW144 -------------------------------------------------------------------------------

2 1

Authorisation and Notification of Changes
by Daniel Karrenberg 01 Sep '93

01 Sep '93

Folks, here is my long promised writeup on the "notify" and "maintainer" attributes. I hope it is clear enough. It will be discussed at the next RIPE meeting. Hopefully no substantive changes will be necessary. Suggestions on how to improve clarity are always welcome of course. Daniel Authorisation and Notification of Changes in the RIPE Database Daniel Karrenberg RIPE NCC ABSTRACT Two new attributes for all objects in the RIPE database are proposed in order to implement a generalised method for authorising changes and to notify interested parties of any changes made to a specific object. In addition the authorisation method provides a convenient way for distributed maintenance of the database. The Notify Attribute Each RIPE database object will have an optional attribute called notify. The value of the notify attribute is one valid RFC822 e-mail address. There can be multiple notify attributes. Whenever the object concerned is changed in the database a notification message will be sent to each e-mail addresses appearing in a notify attribute. This makes it straightforward to keep track of changes to specific objects and prevent changes from going unnoticed. Multiple notify attributes make it possible to notify a number of interested parties. This could be used to alert all contact persons for an object or the local contact per- sons as well as the relevant service provider. Although it may be tempting to put many notify attributes on database objects in order to notify everyone even remotely interested, this is not recommended. A very few key addresses should be sufficient. Prior to entering any mail address here, the explicit or implicit consent of the person responsible for that particular mailbox needs to be obtained. - 2 - The Maintainer Attribute Each RIPE database object will have an optional attribute called maintainer. The value of the maintainer attribute is a registered maintainer name. There can only be one main- tainer attribute per object. Whenever a change to the object concerned is attempted in a copy of the database the maintainer attribute of the current database object is examined. If there is no maintainer attribute or the maintainer name is authorised to make changes in the copy of the database the update proceeds causing the necessary notifications as per the notify attribute. If the maintainer name has no authorisation to change the local copy of the database, the update request is forwarded to the maintainer for processing. No notifications are per- formed in this case. The following data needs to be maintained locally about each maintainer: Maintainer name Authority none change whole database change only own objects Forwarding Info mail/RFC822-address other/address Authorisation none mail/RFC-822-address other/key Application 1: Regional Registries In order to align the InterNIC and RIPE databases it has been agreed that European objects will be maintained in Europe. The RIPE NCC will provide the data for these objects to the InterNIC for inclusion in their database without further processing. The RIPE NCC will refer all updates for non-European objects to the InternNIC and the InterNIC will refer all updates for European objects to the RIPE NCC for processing. This can be achieved by creating two maintainer names: - 3 - INTERNIC and RIPE-NCC and tagging all European objects with RIPE-NCC and vice versa. The tags can be phased in slowly, avoiding a flag day with the associated massive consistency problems. Over time all objects in the RIPE database would be thus tagged. Updates from third parties for objects with the maintainer attribute added can now be referred correctly. Updates from the other registry for objects it maintains can be accepted without further checking. Example 2: Local Registries Some European local registries keep their own copies of the database containing the objects within their area. This leads to consistency problems as updates can be sent both to the RIPE NCC and to the local registry. Referrals are per- formed by ad hoc methods. Frequently only one of the data- bases is updated and alignment needs to be done manually. By registering maintainer names for the local registries and tagging the appropriate objects this can be automated and made more reliable. The NCC would forward update requests for locally maintained objects to the local registry unless they come from that local registry itself. Example 3: Guarded Objects Some objects such as the autonomous-system object (see ripe-81) need to be protected against changes by anyone but a designated guardian since changes to these objects have a direct operational impact. By registering appropriate maintainer names for the guardi- ans and tagging the objects to be protected this functional- ity can be provided in a canonical way. Any change by third parties to such an object will not only be prevented but cause automatic notification of the guardian through the forwarding mechanism.

2 1

beta release new database software
by Marten Terpstra 20 Aug '93

20 Aug '93

People, I have made a distribution of the new software. It includes most of the stuff you would need for indexing and updating a RIPE like database. For those of you who have been playing with the 2 early releases, here are some of the changes: - minor change to key generation routine (to allow certain chars) - dbupdate can now be used as an email responder - more stuff made configurable, more configuration options - some general bug fixes - a bit more documentation (I know, still nowhere near perfect) You will need some familiarity with the RIPE database structure to get this stuff running without much hastle. I have tried making it into a read, install and run package, but it is not quite really. Please understand that it IS still beta, and there may well be bugs everywhere, and it may not be as configurable as you would like, but I'm working on that. I just wanted to get this thing out so that you could play with it a bit, and see if you like it. If you do not have some time to spare to install and try to understand it, I would advide not to get the stuff just yet, but wait for the first real release (expected some time around the RIPE meeting). This release does not understand guarded fields yet, all hooks are in, just some code missing. The indexer and whoisd have been tested by some people already and did not show any major bugs. The update mechanism is not tested too well yet, so try building some test databases first to see how that all works. Most of the working and installation is described in 2 files, INSTALL and README. README should explain enough to get you started, experiment after that. You can find the stuff on: ncc.ripe.net:dbase-beta/dbase-beta.tar.Z Directory dbase-beta is unreadable, but you CAN fetch the file and note that this is NOT on ftp.ripe.net. Oh, you need PERL to run all this stuff ... Enjoy, -Marten

1 0

RIPE Database beta-software trials ...
by Marten Terpstra 16 Aug '93

16 Aug '93

[Apologies for all who received this message on the dns-wg list already, that was obviously a mistake ... -Marten] Dear all, We finally have some beta software running at the NCC for the database, and we would like you to test some things. We have created an empty test RIPE database on ncc.ripe.net running with the new whois daemon. You can send in updates to: testdb(a)ripe.net It will be processed and incorporated in a test database running on ncc.ripe.net (also a whois daemon running on that database). You should receive a ack mail back (to the Reply-To field, or From: is no Reply-To field present) and you should be able to find it in the whois server immediately. Acks should be sent to you within minutes. You can also delete objects in that test database, by simply adding a delete: line to an object. So, person: Marten Terpstra address: RIPE Network Coordination Centre (NCC) address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: Netherlands phone: +31 20 592 5065 fax-no: +31 20 592 5090 e-mail: marten(a)ripe.net nic-hdl: MT2 changed: marten(a)ripe.net 930503 source: RIPE delete: just try and delete this thing should delete this object in the database, if all fields are the same as in the database. The ordering of fields does not matter, just as long as attributes with the same name are in the same order, ie in the object above you cannot change the place of two "address:" fields. Also the place of the delete field does not matter, it can be anywhere in the object. Updating should be very quick, ack mails should be sent to you within minutes. Please try some stuff and see what happens. Comments on the format of the ack mail are also appreciated. Currently verbose ack is default ie you get at least a one line ack per object you send in, and the full object if there were errors or warnings. If you send in objects with a source other than RIPE it should complain that this is an unknown source and should refuse the update. -Marten PS All requests are already properly logged so be careful with those deletes ;-) PPS The syntax checker for this test database is VERY strict, simply because there is no manual intervention from the NCC any longer. It may well be that existing objects in the real database are no longer accepted ;-)

1 0

RIPE database software beta sites needed
by RIPE Database Management 04 Aug '93

04 Aug '93

Folks, Finally parts of the new RIPE database software are ready for some beta testing. I would like a not too big number of sites/people that are willing to run some tests on the new software, and actually have some time to spend on this to make themselves known to me. I have created a new (temporary) mailing list <db-beta(a)ripe.net> which will deal with all the beta-testing on the software. That is where I will put details on where to get the software and will send bug fixes. If you are willing to participate in the beta testing, please send a mail to db-beta-request(a)ripe.net or simply reply to this message. If you just want to see what is going on with the beta testing, you are welcome to join the list as well. Just hope that not all of you will be just listening in ;-) Suggestions/comments welcome. -Marten PS Some people already indicated they wanted to join the list, so currently I have the following people on the db-beta list: Wilfried Woeber <Wilfried.Woeber(a)CC.UniVie.ac.at> # db-wg chairman Tony Bates <tony> Marten Terpstra <marten> GARR NIS <info(a)nis.garr.it>

1 0

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