- db-wg - mailman.ripe.net

Fwd: Re: Short summaries of WG sessions [DataBase]
by Wilfried Woeber, UniVie/ACOnet 08 Oct '96

08 Oct '96

The attached text fragment for the RIPE 25 Minutes was submitted yesterday. You might want to have that as an interim summary while the full DB-WG minutes are being worked on... Cheers, Wilfreid. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Here's the Summary for the DB-WG Meeting, RIPE 25, Amsterdam I might again be too verbose, I don't know. Please feel free to fix my typos and any broken sentences. Roderick, apologies for the one-day delay over the promise... Wilfried. Chair: Wilfried Woeber Scribe: John LeRoy Crain Participants: 51 (according to the sign-up list) The following agenda was agreed: A. Administrative stuff - volunteering of the scribe - WG-agenda bashing B. DB-SW status report by the RIPE NCC - recent changes, V2.0 - new features: experience, feedback C. DB consistency and sanity checks - at time of transaction (create/modify) - at regular intervals - input from other WGs - input from the NCC (address space handling) - RIPE/(NIC)-Handle space, special cases, like ROLExxx-RIPE, RIPExxx-yyy, AUTOxxx-RIPE D. Inverse lookup discussion - recursive lookup on by default, should this change? - extending the list of attributes that can be use in -i lookup? E. Documentation - structure and contents as proposed by the NCC - user input F. New functionality - things on the consolidated wish-list - url handling - inet-rtr object extension Y. General input from other WGs - DNS WG: registration of 2nd level (and lower) domains - Local-IR WG: proposal to have the SW enforce mandatory attributes (status, NIC-handles) Z. AOB - clarification abou mailing lists - obsolete advisories in inetnum objects ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ [ The following summary is not necessarily following ] [ the actual agenda and sequence of discussions, for ] [ a complete report refer to the WG minutes, please! ] Results and decisions The usual report about the status of the DB and the DB software was offered by the RIPE-NCC (Carol Orange) and well received by the group. There is still a couple of minor bugs around (as can be expected anyway when implementing a major new softeware release), these bugs are being fixed asap. The behaviour of the software when doing an inverse lookup ("-i" flag) is to be changed to imply "-r" (recursion disabled). NIC-Handles (in general) and the status: attribute for inetnum: objects should be enforced by the DB software. This is to bring the software in line with the requirements in the address allocation guidelines documentation. The proposed flag day for these changes is 1.1.1997. In order to avoid confusion, the string AUTO (which is used to request and control automatic handle assignment) shall be reserved (not to be used for a real handle). There was general consensus that the quality and consistency of the data in the RIPE-DB should be improved. The group formally supports this activity which is also part of the RIPE NCC Activity Plan for 1997. A project has been set up with the Free University of Amsterdam to look at the consistency issues. Students may wish to interview selected users. Current thinking is that there shall be more sanity checking at the time of a transaction (each time) and that we need some background checks that can be performed at regular intervals. These should then catch inconsistencies which can not be properly detected by the transaction tests. Making this process succeed is expected to require collaboration and some effort from Local-IR folks as well as from the routing folks. Ambrose Magee was introduced as the new primary maintainer of the DB-SW. He then reported on the proposed structure of the Documentation for the RIPE Database objects, the usage and the software. The group endorsed the concept with some minor proposals for improvement and stressed the importance of the documentation, and in general, the importance of consolidation vs. new functionality. Input received from the DNS-WG asked for a referral mechanism in the RIPE-DB to support registering 2nd and lower level domain objects at the site of a TLD Administration, but still offering access with whois by way of the RIPE-DB. There was a reasonable number of TLDs represented that promised support on their end for implementing that approach. The decision reached calls for an interim solution to add a referral mechanism to domain: objects. This would only be used in (TLD) domain: objects that describe the TLD and point to the authoritative DB that holds the 2nd and any lower level data. During the discussion of the DB-SW behaviour of handling multiple maintainer entries, it was clarified that there is no hierarchy involved. The software just scans all entries and tries to find a match. The first match found is honored. This is in line with the current concept and design. New actions: Action (1) on Wilfried Woeber and Carol Orange, To come up with a technical proposal for better DB consistency checking. Action (2) on all WG members, To think about implications of the proposed DB consistency checking and to provide input. Action (3) on RIPE NCC (Carol Orange, Daniel Karrenberg), To report about the FUA findings (on DB consistency) at next ripe meeting. Action (4) on RIPE NCC (Carol Orange, Daniel Karrenberg), To document the approach to find and change references to person objects in order to support migration to mandatory handles (using inverse look up and "search and replace") and send it to the list. Action (5) RIPE NCC (Ambrose Magee) (time allowing), To implement the change that "whois -i ..." implies "whois -i -r ..." Action (6a) on Wilfried Woeber, To ask on the DB-WG mailing list about the need of improved inverse lookup functionality (more attributes allowed for -i). Action (6b) on Daniel Karrenberg, To look at query logs for "failed" -i attempts. Action (7) on Ripe NCC (Ambrose Magee), Produce the RIPE-DB Documentation a.s.a.p. and according to the agreed structure. Action (8a) on RIPE NCC (Carol Orange), Publish the "known bugs" list, on the Web or on the FTP-Server. Action (8b) on RIPE NCC (Carol Orange), Publish the "open issues" list (consolidated wishlist) on the Web or on the FTP server. Action (9) on RIPE NCC (Ambrose Magee, Carol Orange, Daniel Karrenberg), To propose and implement (a.s.ap.) a referral mechanism for TLD domain: objects (only). Action (10) on Wilfried Woeber and the RIPE NCC, To make a proposal on the technical and procedural requirements of making the status: attribute for inetnum: objects mandatory. Action (11) on RIPE NCC (Ambrose Magee), To change the DB-SW to obsolete the advisory: attribute in inetnum: objects. Action (12) on RIPE NCC (Ambrose Magee), To add mailing lists with their descriptions to the database documents. WW, 7-OCT-1996. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------

2 1

TEST database.
by RIPE Database Administration 04 Oct '96

04 Oct '96

Dear Colleagues, The test version of the RIPE database is back on-line. Requests for maintainer objects in the test database should be sent to <ripe-dbm(a)ripe.net>. This is to be changed in the near future. Participants in the RIPE Database 2.0 Workshop during the recent RIPE meeting had test objects and maintainers created for them in the test database. If you wish these objects to remain in the test database, please send a message to <ripe-dbm(a)ripe.net> as soon as possible. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

1 0

Re: mnt-lower attribute not allowed?
by Wilfried Woeber, UniVie/ACOnet 04 Oct '96

04 Oct '96

Hi Steven et.al. ! => => The AS object that matches the origin AS of a route object could be the => parent object of the route object, but then people are still able to put => route objects in with another origin AS which might not be desired by the => owner of the non-portable CIDR address space. Furthermore, a second => hierarchy exists: the IP prefix tree. => => You might want to try to formulate a proposal that is not too => complicated and also addresses the concerns of most people ... = =How about making the inetnum object the parent of the route object? =I think it would make sense to allow the "owner" of the inetnum to create =the route objects.. I'm not convinced that this is the way to go. For two major reasons: - in many environments the routing is handled differently from the address allocation. In particular, where filters or other things are (semi-)automatically derived from objects in the DB, it's certainly not feasable to have the customers ("owner" of the address space) change things without coordination. If they do, it might not reflect reality at all or it might interfere with local logistics. And there's the issue of porting PA address space for a limited amount of time to a different ISP. - I think we should come up with a concept that works as well outside the RIPE-coordinated address space and the central registry concept. I think we should . come up with a solution that works for routing-registries that do not include an address registry in the same DB, . find a solution that works uniformly across all parts of the address space (A, B, C-19[3-5], TWD, et.al.) = You can also keep the owner in the "notify:" field of =the route object, so once you delegate maintenance of the route object to =someone else, you can still keep track of what's happening with it. = =Or does this sound ludicrous? No, it made me think, thus it was a very useful approach :-) I'd favour an approach that is (conceptually) similar to the handling of domain objects - something like an upstream search based on the AS #. Although I haven't a clear picture of how it could work in reality, because the "tree" is certainly less well-defined than in the DNS namespace. Cheers, Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------

1 0

mnt-lower attribute not allowed?
by Schmitz＠rus.uni-stuttgart.de 04 Oct '96

04 Oct '96

Dear colleagues, yesterday I tried to apply the hierarchical authorisation scheme on route objects. However, I did not succeed. As an example, have a look at this: route: 193.174.0.0/15 descr: DFN-AGG-1 origin: AS1275 mnt-by: DFN-MNT mnt-lower: DFN-MNT changed: poldi(a)dfn.de 950907 changed: noc(a)noc.dfn.de 961001 source: RIPE password: ... resulted in: Update FAILED: [route] 193.174.0.0/15 route: 193.174.0.0/15 descr: DFN-AGG-1 origin: AS1275 mnt-by: DFN-MNT changed: poldi(a)dfn.de 950907 changed: noc(a)noc.dfn.de 961001 source: RIPE *ERROR*: attribute "mnt-lower" unknown in route object Is this just an error in typing (I took the same spelling as given in the RIPE database 2.0 workshop), or is hierarchical authorisation not done for route objects (in the workshop there was only an example for inetnum objects), or is it just not implemented yet? If it was implemented only for inetnum objects I do not see any reason why it should not be also possible for route objects. Could anybody please give a hint? Regards Joachim _____________________________________________________________________________ DFN Network Operation Center, Dr. Joachim Schmitz, (finger help(a)noc.dfn.de) >>>>>> mailto: noc(a)noc.dfn.de <<<<<< Rechenzentrum Universitaet Stuttgart, Allmandring 30, D-70550 Stuttgart Phone: 0711-685-5810, 0711-685-5576, FAX +711 6788363 (business hours) EMERGENCY phone +711 1319 139 with answering machine and pager _____________________________________________________________________________

4 3

Hierarchical Authorisation.
by RIPE Database Administration 02 Oct '96

02 Oct '96

Hi, Joachim ! Hierarchical authorisation is currently available for inetnum and domain objects. >From the HELP & HOWTO document: - You can protect against people *creating* (only creating) objects direct (one level) below in the hierarchy of an object type (only for 'inetnum:/domain:' objects) by using your maintainer in a 'mnt-lower:' attribute. The authorization method of this maintainer object will then be used upon creation of any object direct below the object that contains the 'mnt-lower:' attribute. This is also mentioned in the Release Notes of the new software. Hope this helps. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

1 0

More attributes for indexing?
by Steven Bakker 02 Oct '96

02 Oct '96

Hi folks, At the last RIPE meeting there was some discussion about which attributes would be useful to keep indices on. Well, since our office move last weekend, I came up with a (rather predictable) one: $ whois -i ad "Lockton House" % ignored attribute "address" since it is not indexed as a reference % no attributes specified for -i query $ _ Dang! It would be nice to have an index on address, although such an index might become veeerrrry large, due to the fact that you can specify multiple "address" attributes per object; dunno. Any thoughts? Cheers, Steven

4 3

Re: interesting person entry...
by Wilfried Woeber, UniVie/ACOnet 27 Sep '96

27 Sep '96

=> I personally feel that this should be done through the config file: give => every attribute a property of allowed empty lines or not. For example => 'remarks:' lines can be read easier when they may contain empty lines => while empty rev-srv: lines are useless. => I roughly agree about the approach, but see below. > Wilfried: I suggest a collection of all attributes should be analyzed > to see where empty lines are useful and where not. I currently do not > have an overview of all attributes but I feel that > - single ones > - attributes used as reference (e.g. tech-c) > - attributes necessary for administrative database purposes (e.g. changed > or source) > must not be empty (just as it came to my mind). Agreed. > I wonder how many > attributes might be left over which could carry empty lines. I feel that > the address attribute should not have empty lines. However, empty lines > could be useful as David noted on the remark attribute. I think all the lines where syntax checking is being done should *not* allow empty lines. To some degree I can see the usefulness of *single* empty lines within a *block* of attributes that allow free format text. Currently remark:, trouble:, and address: comes to my mind - and maybe a few more. But even then, the optical effect that is described can easily be obtained by e.g. putting a "." or "-" as the only character into the value field. I suppose that would remove some complexity from the software to support this "cosmetic sugar". Thus it would be my personal proposal to disallow empty lines altogether (empty in the sense of an attribute having no value supplied). Your input is very welcome, and yes, that could be put onto the draft agenda for RIPE-26 if there is no clear consensus or any strong feelings. Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------

2 1

interesting person entry...
by Schmitz＠rus.uni-stuttgart.de 26 Sep '96

26 Sep '96

Dear colleagues, dear Ambrose, by accident I discovered a person entry which in its form is definitely not wanted: *pn: Stefan Seiz *ad: Herdweg 73 *ad: \ ... > 128 empty address lines!!! *ad: / *ad: 70174 Stuttgart *ad: Germany *ph: +49 711 18748-0 *fx: +49 711 18748-32 *em: index(a)schwaben.com *nh: SSE2-RIPE *ny: noc(a)ecrc.de *ch: wer(a)ecrc.de 951115 *so: RIPE I am in no position to decide whether the entry was done including these empty lines or whether this is an error of the database software. I think a check should be implemented during acceptance of new database objects (or updates) which - removes empty input lines (or fields which do contain nothing but white space) - afterwards checks whether all mandatory fields for the object are filled in should be done (actually I expect such a test to be performed anyway...) Could anybody please check what is wrong here? Thank you! Joachim _____________________________________________________________________________ DFN Network Operation Center, Dr. Joachim Schmitz, (finger help(a)noc.dfn.de) >>>>>> mailto: noc(a)noc.dfn.de <<<<<< Rechenzentrum Universitaet Stuttgart, Allmandring 30, D-70550 Stuttgart Phone: 0711-685-5810, 0711-685-5576, FAX +711 6788363 (business hours) EMERGENCY phone +711 1319 139 with answering machine and pager _____________________________________________________________________________

3 3

interesting person entry... (followup)
by Schmitz＠rus.uni-stuttgart.de 26 Sep '96

26 Sep '96

Dear colleagues, regarding empty input lines in the RIPE database: rubin$ egrep '^\*ad: *$' ripe.db.pn | wc -l 13442 rubin$ egrep '^\*..: *$' ripe.db.* | wc -l 15522 (with the database as of this morning around 2:10 am) I estimate this really should be changed... Regards Joachim _____________________________________________________________________________ DFN Network Operation Center, Dr. Joachim Schmitz, (finger help(a)noc.dfn.de) >>>>>> mailto: noc(a)noc.dfn.de <<<<<< Rechenzentrum Universitaet Stuttgart, Allmandring 30, D-70550 Stuttgart Phone: 0711-685-5810, 0711-685-5576, FAX +711 6788363 (business hours) EMERGENCY phone +711 1319 139 with answering machine and pager _____________________________________________________________________________

1 0

RE: RE: HELP! 'networkupdate', diskussion on short names of attributes
by Markus Bock 20 Sep '96

20 Sep '96

Hi all ! Contents: --------- 1. Thanksgiving for quick response 2. More about the problem with 'networkupdate' 3. Comments on short names of attributes 4. Comments on whois -i option 5. Question on destination for emails in 'RIPE DB' context 1. Thanksgiving for quick response ================================== At first I would like to thank - Wilfried Woeber, UniVie/ACOnet - Geert Jan de Groot, RIPE NCC - Carol Orange, RIPE NCC and specially - David Kessens who gave me quick response to my 'cry for help'. Thank you very much for your suggestions and for taking time to think about that problem with the 'networkupdate' client programm. Below you can read more about the progress in that case. And no, there is no reason to say sorry for a 'delayed response'. I'm pleased about your quick and helpful reactions. Thank you again! 2. More about the problem with 'networkupdate' ============================================= Below i repeat parts of David Kessens answer ... > Hi Markus, > > Markus Bock writes : > > > > For writing database front ends which manipulate and visualisize > > the stored data we want to use the 'networkupdate' program to > > have access to the database from different workstations via LAN. > This function is indeed present for this purpose. Yes, great. I think with the direct network update-method one has many potentialities to develope client-server based applications with a two task architecture like you see in the sketch below (just an example). ----------------- client-area | application | ----------- ----------------- | networkupdate | ----------------- | ^ v | communication drivers & protokolls // // network ======================================== \\ \\ // || VV communication drivers & protokolls | ^ v | ----------------- server-area | DB-server | ----------- | whoisd | ----------------- | | ----------------- / \ / \ ________ ___________ (________) (___________) | DB | | DB | | source | | source | | XXXX | | OWN | -------- ----------- > Maybe I make something wrong or this effect has something to do with > > running under Slowaris 2.5 ... ? > May be, may be not. Could you try the C version of networkupdate > (available from ftp.ripe.net/tools/whois-tools*) and see if the same > problem happens ? Yes I did it. The same problem happens NOT. I performed several tests with the C version and everything is working fine giving the estimated results. Just for information: --------------------- I had to do the following changes inside the makefile of the C versions of the ripe whois tools to compile it successful at our site under Solaris 2.5 with gcc: - define '-DSYSV' added - additional LIBS 'LIBS= -lresolv -lsocket -lnsl' added - changing the syntax to call install # install: ${PROG} # $(INSTALL) -c ${DESTDIR} -s -m 755 ${PROG} networkupdate # $(INSTALL) -c ${MANDIR}/whois.1 -m 444 whois.man > Could you try 'networkupdate -h whois.ripe.net'. You should get a message > back that tells you that you are not authorized to network updates. The > problem is problably in the client side of the software if you don't get > this message. Yes, I did it. - With the perl version I didn't received the message that tells me that I'm not authorized to do network updates. There is an analogical problem like I described in my 'cry for help'. 'networkupdate' terminates immediately. - With the C version I received the estimated message % ERROR: ***You are not authorized to do network updates***. With this results I agree with you that the problem is problably in the client side of the software. I tried to find out what is potentially wrong in the software by taking the examples for a client and a server from L. Walls camel book and comparing it with the RIPE DB SW (I assume that the same mechanisms are used by the RIPE DB SW). But I was still not able to change it in that way that these examples are able to handle the input of multiple lines (I'm not familar with 'command buffering or not' stuff) or to produce an analogical failure like decribed above. So I have no further result with this case. Has anyone tested the perl version of the networkupdate programm succesfully at his site ? If yes, in which enviroment (OS, version, HW etc.) ? > Please contact <ripe-dbm(a)ripe.net> and see if they can help you with > extra debugging code in the whoisd daemon/whois client to do a more > detailed trace of what is happening in the server software. Yes, thank you. I'll do it. > I hope this helps, > David K. > PS Please don't expect any fast responses right now since I am still busy > with moving & am not working yet. I have, however, already built a new > computer & got a ppp account at ISI so I am not completely > disconnected anymore ;-). Yes, thank you again. Your help enables me to go sucessfully on with my work. Also this gives me the opportunity to wish you success and good luck for your future at ISI. 3. Comments on short names of attributes ======================================== First: ------ While testing the RIPE DB for use to store own data objects I examined the following cases: Assume that you have to store 30 or more new database objects with about 300 (or more) new attributes in a (SPLIT) RIPE database (I already did it). Because you will have problems to find sensefull short names for attributes you use a numbering scheme like this: # DB-object dummy A1 ATTR A1 dummy_longname_1 ATTR A2 dummy_longname_2 ATTR A3 dummy_longname_3 # DB-object dummy A1 OBJ A1 ATSQ A1 A2 A3 OBJ A1 MAND A1 OBJ A1 MULT A2 A3 OBJ A1 UNIQ A1 OBJ A1 KEYS A1 Seems ok. *** But be careful. Don't use uppercase letters *** for naming database objects and attributes *** in a SPLIT database. The side effects are that at first everything is working fine (indexing, dbupdate updates via email etc.). The data will be stored correctly. But if you query the database via whois and whoisd you ever get the message that will be displayed if no match was found (have a look in your ripedb-config file). What happened ? After I had a look at the source code of the whoisd I think one can find the explanation in this section # sub findsplitdbs { # local(*keys, @preselection)=@_; # local(@searchdb)=(); # # print STDERR join(" ", keys %CLASSLESSDBS), "\n"; # @preselection=grep($CLASSLESSDBS{$_}, @preselection) if (scalar(grep(/^$VALIDPREFIXKEY$/o, @keys))==scalar(@keys)); # # # # and now we are going to do something really smart... # # and trickey things # local(@upperkeys)=@keys; # grep(tr/a-z/A-Z/, @upperkeys); # # # # see comment below why we need this # local(@tmpkeys,@tmpupperkeys); # local($tmp); and so on. I think that with this the software is not able to find the datafiles, i.e. which are named by this konvention /whereever/it/is/SOURCE.db.OBJECT /whereever/it/is/SOURCE.db.OBJECT.pag /whereever/it/is/SOURCE.db.OBJECT.dir where OBJECT is in uppercase letters. Does somebody agree with me ? Second: ------- Above I wrote about a problem to find sensefull short names if you have to store many new database objects with many (many) attributes. What you have at least for this is a two letter code with all alphabetic characters (in lowercase) and all digits. So you have (26+10) * (26+10) = 1296 (I hope it is correct...) possibilities for short names. This seems to be enough. But you have still the problem to find sensefull short names for a large amount of database objects and attributes. Maybe I see a problem 'where no problem is' but I can assume that in future even the RIPE database (if it will growth by objects and attributes) will reache the border finding sensefull names for short attributes. So my questions are: - Is it possible to use in future only the long names of attributes and objects or - needs this change too much manpower and time ? >From a view of data modelling I think the short names are redundant even if I know that from a view of implementing the database and writing code they are useful (i.e. for doing syntax checks). 4. Comments on whois -i option ============================== Wow ! I really like this option. If you have a somewhat clever data modelling you can realize something like a 'where clause' which is known from SQL. Another thing is that you can realize something like a 'join' over two database objects. You just have to play a little bit around with the 'KEY' and 'REC' terms inside the definition of your database objects. 5. Question on destination for emails ===================================== in 'RIPE DB' context ==================== I don't know if the database working group is the right address to report everthing in context RIPE database. Should one better report only for i.e. problems with implementation and porting the software directly to the database maintainer at RIPE NCC <ripe-dbm(a)ripe.net> ? and on the other side Should one better report only i.e. issues about the database concepts directly to the database working group ? Is there somewhat like a rule for this ? Thanks again ! have a nice day, Markus

2 1