- db-wg - mailman.ripe.net

Re: mnt-nfy
by zsako＠banknet.net 21 Oct '96

21 Oct '96

> From davidk(a)isi.edu Fri Oct 18 18:33:24 1996 Dear David, > > My point at the RIPE meeting was that when sending an update with a Reply-to, > > the mnt-nfy DOES get a "warning" message, that somebody made SOME updates, > > (since the "Congratulations" are sent to her), but has no clue wrt. WHAT > > exactly has been modified (usually the Subject: line does not provide accurate > > information - if at all)... > > This is true. You will receive less information then with a notification > message in this case. This is clearly a disadvantage, but also an > advantage for those people that are getting a bit tired of the amount of > mails coming from the RIPE database automatic department. OK. I understand now, this really IS a feature. > > > (Of course, the situation can be even worse if the From: line is forged...) > > But you will always get at least one message from the database whether it > is an ACK message or a notify message. The smartness only eliminates more > mails sent to one and the same E-mail address. And again <ripe-dbm(a)ripe.net> > is always willing to investigate with the maillogs if you suspect > someting like this (in fact I *did* found a forgery once and I can assure > you that the person that did it will not do it another time ...) In fact I knew the NCC has very good logging (I once had to use this "service" :) ), but I thought we could spare some investigation. However, if such "errors" are infrequent, I agree it is not worth changing the behaviour. > > > PS. I suppose (and strongly hope :)) the authentication is based on the From: > > and not the Reply-to:. > > I can tell you from first hand experience (that is the code is > implemented as required in the specs) that the authentication is done on > the From: field and nothing else then that. This is what I wanted to hear, thank you. :) (I do not worry any more). Thanks again and regards, Janos

1 0

MAIL-FROM Authentication scheme.
by RIPE Database Administration 18 Oct '96

18 Oct '96

Dear Janos Zsako, I wish to draw your attention to ripe-120. There, under "Authentication Schemes; MAIL-FROM" it states: This authentication method checks the content of the RFC822 From: header of an update request against the regular expression specified as <auth-info>. As Daniel has already stated, those with really high security requirements shoud use maintainers with a stronger authentication menthod. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

1 0

mnt-nfy
by Domain registration staff 18 Oct '96

18 Oct '96

Dear folks, Recently I found that RIPE DBM doesn't send me notification about changes of guarded objects (e.g. AS1955). Specially I send updates from the address to notify. The version 2 software is so smart, that knows that no use to notify the sender itself, or this is some bug? Regards Gabor Kiss

3 2

List of known bugs.
by RIPE Database Administration 17 Oct '96

17 Oct '96

Dear Colleagues, A list of known bugs in the software for the interface to the RIPE database is now available at: ftp://ftp.ripe.net/ripe/dbase/bugs Please send comments to <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

2 1

Re: mnt-nfy
by zsako＠banknet.net 17 Oct '96

17 Oct '96

> From owner-db-wg(a)ripe.net Thu Oct 17 16:13:02 1996 Gabor, > Recently I found that RIPE DBM doesn't send me notification about > changes of guarded objects (e.g. AS1955). Specially I send updates from > the address to notify. The version 2 software is so smart, that > knows that no use to notify the sender itself, or this is some bug? I have raised this issue in the DB-WG at RIPE-25. It was definitely considered a *bug* (not a feature :)). I was asked to repeat the experiment and send a "warning" message with the details to ripe-dbm(a)ripe.net soon after that, in order to help them identify the problem. I apologise publicly, because I must admit I forgot to do so... Regards, Janos

1 0

Re: Short summaries of WG sessions [DataBase]
by Gabor Kiss 11 Oct '96

11 Oct '96

> 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. Who are working on the referral mechanism? Is there some info on the net about the current state? I've a few idea and I don't want to reinvent the wheel. ;-) Gabor

2 1

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

11 Oct '96

Hi Gabor ! => 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. = =Who are working on the referral mechanism? =Is there some info on the net about the current state? Please see: Subj: 2nd draft, minutes of DB-WG meeting at RIPE 25 [ ... ] 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). And Daniel's comment: To: "Wilfried Woeber, UniVie/ACOnet" <woeber(a)cc.univie.ac.at> CC: db-wg(a)ripe.net Subject: Re: 2nd draft, minutes of DB-WG meeting at RIPE 25 From: Daniel Karrenberg <Daniel.Karrenberg(a)ripe.net> Date: Thu, 10 Oct 1996 18:01:55 +0200 > DNS: > > Janos Zsako thought that the referral should be implemented in the server n > ot > in the client! Definitely! =I've a few idea and I don't want to reinvent the wheel. ;-) = =Gabor Please keep us posted, either in private or on the db-wg list. Thanks, 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

draft minutes of DB-WG meeting at RIPE 25
by Wilfried Woeber, UniVie/ACOnet 10 Oct '96

10 Oct '96

This is the 1st draft of the minutes for the DB WG meeting at RIPE 25. I expect to add a couple of URLs to point to presentations as soon as they might become available from the RIPE FTP-Server. The Action List probably needs renumbering, to get it aligned with the summary notes for the plenary. As always, all comments, input and improvements welcome. 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 -------------------------------------------------------------------------- Minutes for the DB WG meeting RIPE 25, Amsterdam, NL **1st DRAFT**, 9-Oct-1996 Chair: Wilfried Woeber Scribe: John Crain Participants: 51 (according to the sign-up list) A. Administrative stuff John Crain offered to take notes. Thanks a lot, John! The proposed agenda was agreed, including the following additional items: - Input from the DNS-WG and - Input from the Local-IR WG both for agenda item Y. General input from other WGs and - advisories: in aut-num: objects for Z. AOB B. DB-SW status report by the RIPE NCC Carol Orange offered the report on the state of the RIPE Database and the DB-SW. Version 2.0 of the software was released recently and put into production at the NCC. Important new features are: - inverse lookup (whois -i) - the package is now fully classless - support for near real-time-shadowing (As an aside, a DB-Workshop was offered on Monday morning.) More details about the growth of the DB and the increase in the number of objects, etc. were shown on the slides. [ These slides are expected to become available soon ] [ at ftp://ftp.ripe.net/ripe/presentations/ ] Activities for the short term future are - produce documentation - fix any version 2.0 bugs - try to improve consistency In general, version 2.0 is found to run very well. Sabine Dolderer reported on problems with the handling of old (invalid) handles. This is one of the known problems. Sabine was asked to report the problem to the ripe-dbm(a)ripe.net mailbox. C. DB consistency and sanity checks Is it worthwhile doing more sanity checking? 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 already been set up with the Free University of Amsterdam to look at the consistency issues in general. Students may wish to interview selected users. The Local-IR staff and the users of the Routing Registry are expected to contribute to this activity. The group then identified a couple of obvious inconsistencies which should be checked, either at the time of a transaction or on a regular basis. E.g. - person/role objects being refered to no longer exists - persons (multiple) with and without nic-hdls. - person objects which are no longer referenced by any other object (proposal to eventually remove these objects, considering the age of the object) - multiple route objects with different origin, where there is obviously no trasnition and/or multi homing. The various checks, when they get implemented eventually, should at least generate warnings, both at the time of an update and on a regular basis. The logistics (frequency, identifying the proper recipients for the warnings, etc.) need more work. The discussion of a potential reservation of some NIC-Handle types (like AUTOxx-RIPE, ROLExx-RIPE, etc.) led to the conclusion - that there is no need for special handling of role: objects - and that AUTOxx-RIPE should be reserved to avoid confusion when requesting automatic handle assignment with the AUTO-xx mechanism. Niall O'Reilly suggested that the various registries should help with the transistion process by changing old person objects that are (mis-)used to define a role into correct role objects. D. Inverse lookup discussion Is automatic recursion still useful? Just observed as a fact, quite a few people have aliases defined to disable the automatic recursion for their environment. However, for compatibility reasons and because most of the casual users are expected to need the information provided by the recursion, the decision was to stick with the current default (recursion is on by default, use -r flag to disable it). However, the behaviour of the software when doing an inverse lookup ("-i" flag) is to be changed to imply "-r" (recursion disabled). Discussion then moved on to find out wether inverse lookup should be allowed for all attributes. Common feeling was that it is not necessary for all attributes, but it might be useful to implement for a couple of additional attributes. In order to find out about the real need, a discussion on the DB-WG list should be started and the NCC was asked to look at the logs to find out about "popular" failed queries. Kurt Kayser asked about the software behaviour and the timing involved when a "server running at low priority" message is issued. This message is issued for general queries that (potentially) produce a large number of hits. As long as the TCP connection is up, it's still working. E. Documentation Ambrose Magee was then introduced as the new primary maintainer of the DB-SW. He 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. In particular, the proposal is to have a main document that is stable and a set of appendices with things that may change or require more freequent updates. [ The slides are expected to become available soon ] [ at ftp://ftp.ripe.net/ripe/presentations/ ] One of the suggestins was to seperate the advanced sections (e.g. on how to obtain the database etc.) from the general user documentation. Nigel Titley proposed to start working with the sections on the whois client and utilities and move that information to the beginning of the documentation Bernhard Stockman asked for a list of all active objects (Index), including definition of the syntax and the also the semantics. Daniel proposed to add that functionality toi the software itself, probably by adding a whois -T with -v and possibly whois -T to report all objects. This is is already available for listing the schema for an individual object. F. New functionality Even thouogh there was some discussion on new functionality, like a URL: attribute and amendments to a cgi script to provide access to the data via html, it was stressed that for the time being consolidation should be the priority instead of new functions. The maintainers of the DB-SW were asked to maintain and publish the "consolidated wish-list" and the "known bug list". Y. General input from other WGs DNS: There was concern over potential conflicts between information in RIPE Database and the TLD's internal databases. Becuase of that potential conflict, some TLD administrators do not register their secondaries in the RIPE DB. Referal to their database would be useful. Daniel Karrenberg reported that this referal mechanism is already on the wish list. No design work has been done yet. There is a couple of potential implications, e.g. the idea to implement the referral for other (all?) objects. Guy Davis observed that it might be useful to do a more specific search on hosts/domains for DNS. Daniel Karrenberg was in favour of more specific, but has mixed feelings on referral because of all the different whois initiatives within the Internet. Thus he suggested to implement a quick fix for the top level domains only. Janos Zsako thought that the referral should be implemented in the server not in the client! Wilfried Woeber observed that the referral approach can only be useful if most TLD's are willing to supply an interface for whois. There was an indication of considerable interest to offer access to the local TLD data. Local-IR: Mandatory attributes (as described in the regsistry procedures) should be made mandatory in the database (enforced by the software). In particular the status: attribute in inetnum: objects and the nic-hdl: attribute in general should be made mandatory. Of course, this implies a major clean-up of the database by the LIR's! Daniel Karrenberg observed that initially this will only be applicable for new objects. The clean-up will come later. Kevin Hoadley asked for some time to implement the necessary changes to local scripts and procedures. The following discussion led to a proposal to start enforcing this on the 1st of January 1997. A. Blasco Bonito asked about potential implications of making the 'status:' attribute mandatory. Carol Orange suggested to define an additional value for the status: (USED?) to distinguish between address space allocations, assignments and usage. A. Blasco Bonito's comment that "The general attitude of LIR's who are large providers is to assign to other smaller providers. These then distribute to their customers." prompted Daniel Karrenberg to state that "If this is the case then they are not following the registration policies." A mandatory status: attribute has implications that have to be discussed in more detail. Z. AOB Brian Renaud proposed to obsolete the advisory: attribute for aut-num: objects. For 'route:' objects, these atrtributes should remain valid. Ther was general agreement and the NCC was asked to implement that change. Following up on a mail received from David Kessens, ther was a review of the various mailing lists that dal with different aspects of the database business. These are: DB-WG DB-BETA RRIMPL Daniel Karrenberg described the scope of these lists and observed that all three have their own specific use: - DB-BETA is for people running new code. - DB-WG is for architecture discussions - RRIMPL has a wider scope Bugs in the released version of the RIPE DB-SW should be submitted to ripe-dbm(a)ripe.net discussions about details of running new code should go to db-beta@ripe-net. Sabine Dolderer observed that if there are two maintainers then the "weakest" one is used. Daniel Karrenberg pointed out 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. This is the correct behaviour as all maintainers are equally authorized. To allow specific maintainer functions is at the moment beyond the functionality of the DB. Appendix: New actions [The relative numbering is going to change to match the full meeting minutes] 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, 9-OCT-1996 20:05:57

3 2

2nd draft, minutes of DB-WG meeting at RIPE 25
by Wilfried Woeber, UniVie/ACOnet 10 Oct '96

10 Oct '96

This is the 2nd draft of the minutes for the DB WG meeting at RIPE 25. It incoporates comments by David Kessens. I expect to add a couple of URLs to point to presentations as soon as they might become available from the RIPE FTP-Server. The Action List probably needs renumbering, to get it aligned with the summary notes for the plenary. As always, all comments, input and improvements welcome. 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 -------------------------------------------------------------------------- Minutes for the DB WG meeting RIPE 25, Amsterdam, NL **1st DRAFT**, 9-Oct-1996 Chair: Wilfried Woeber Scribe: John Crain Participants: 51 (according to the sign-up list) A. Administrative stuff John Crain offered to take notes. Thanks a lot, John! The proposed agenda was agreed, including the following additional items: - Input from the DNS-WG and - Input from the Local-IR WG both for agenda item Y. General input from other WGs and - advisories: in aut-num: objects for Z. AOB B. DB-SW status report by the RIPE NCC Carol Orange offered the report on the state of the RIPE Database and the DB-SW. Version 2.0 of the software was released recently and put into production at the NCC. Important new features are: - inverse lookup (whois -i) - the package is now fully classless - support for near real-time-shadowing (As an aside, a DB-Workshop was offered on Monday morning.) More details about the growth of the DB and the increase in the number of objects, etc. were shown on the slides. [ These slides are expected to become available soon ] [ at ftp://ftp.ripe.net/ripe/presentations/ ] Activities for the short term future are - produce documentation - fix any version 2.0 bugs - try to improve consistency In general, version 2.0 is found to run very well. Sabine Dolderer reported on problems with the handling of old (invalid) handles. This is one of the known problems. Sabine was asked to report the problem to the ripe-dbm(a)ripe.net mailbox. C. DB consistency and sanity checks Is it worthwhile doing more sanity checking? 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 already been set up with the Free University of Amsterdam to look at the consistency issues in general. Students may wish to interview selected users. The Local-IR staff and the users of the Routing Registry are expected to contribute to this activity. The group then identified a couple of obvious inconsistencies which should be checked, either at the time of a transaction or on a regular basis. E.g. - person/role objects being refered to no longer exists - persons (multiple) with and without nic-hdls. - person objects which are no longer referenced by any other object (proposal to eventually remove these objects, considering the age of the object) - multiple route objects with different origin, where there is obviously no trasnition and/or multi homing. The various checks, when they get implemented eventually, should at least generate warnings, both at the time of an update and on a regular basis. The logistics (frequency, identifying the proper recipients for the warnings, etc.) need more work. The discussion of a potential reservation of some NIC-Handle types (like AUTOxx-RIPE, ROLExx-RIPE, etc.) led to the conclusion - that there is no need for special handling of role: objects - and that AUTOxx-RIPE should be reserved to avoid confusion when requesting automatic handle assignment with the AUTO-xx mechanism. Niall O'Reilly suggested that the various registries should help with the transistion process by changing old person objects that are (mis-)used to define a role into correct role objects. D. Inverse lookup discussion Is automatic recursion still useful? Just observed as a fact, quite a few people have aliases defined to disable the automatic recursion for their environment. However, for compatibility reasons and because most of the casual users are expected to need the information provided by the recursion, the decision was to stick with the current default (recursion is on by default, use -r flag to disable it). However, the behaviour of the software when doing an inverse lookup ("-i" flag) is to be changed to imply "-r" (recursion disabled). Discussion then moved on to find out wether inverse lookup should be allowed for all attributes. Common feeling was that it is not necessary for all attributes, but it might be useful to implement for a couple of additional attributes. In order to find out about the real need, a discussion on the DB-WG list should be started and the NCC was asked to look at the logs to find out about "popular" failed queries. Kurt Kayser asked about the software behaviour and the timing involved when a "server running at low priority" message is issued. This message is issued for general queries that (potentially) produce a large number of hits. As long as the TCP connection is up, it's still working. E. Documentation Ambrose Magee was then introduced as the new primary maintainer of the DB-SW. He 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. In particular, the proposal is to have a main document that is stable and a set of appendices with things that may change or require more freequent updates. [ The slides are expected to become available soon ] [ at ftp://ftp.ripe.net/ripe/presentations/ ] One of the suggestins was to seperate the advanced sections (e.g. on how to obtain the database etc.) from the general user documentation. Nigel Titley proposed to start working with the sections on the whois client and utilities and move that information to the beginning of the documentation Bernhard Stockman asked for a list of all active objects (Index), including definition of the syntax and the also the semantics. Daniel again proposed to add that functionality to the software itself. This is already on the consolidated wish-list, and to be implemented by adding a whois -T with -v and possibly whois -T to report all objects. whois -T <type> is already available for listing the schema for an individual object. F. New functionality Even thouogh there was some discussion on new functionality, like a URL: attribute and amendments to a cgi script to provide access to the data via html, it was stressed that for the time being consolidation should be the priority instead of new functions. The maintainers of the DB-SW were asked to maintain and publish the "consolidated wish-list" and the "known bug list". Y. General input from other WGs DNS: There was concern over potential conflicts between information in RIPE Database and the TLD's internal databases. Becuase of that potential conflict, some TLD administrators do not register their secondaries in the RIPE DB. Referal to their database would be useful. Daniel Karrenberg reported that this referal mechanism is already on the wish list. No design work has been done yet. There is a couple of potential implications, e.g. the idea to implement the referral for other (all?) objects. Guy Davis observed that it might be useful to do a more specific search on hosts/domains for DNS. Daniel Karrenberg was in favour of more specific, but has mixed feelings on referral because of all the different whois initiatives within the Internet. Thus he suggested to implement a quick fix for the top level domains only. Janos Zsako thought that the referral should be implemented in the server not in the client! Wilfried Woeber observed that the referral approach can only be useful if most TLD's are willing to supply an interface for whois. There was an indication of considerable interest to offer access to the local TLD data. Local-IR: Mandatory attributes (as described in the regsistry procedures) should be made mandatory in the database (enforced by the software). In particular the status: attribute in inetnum: objects and the nic-hdl: attribute in general should be made mandatory. Of course, this implies a major clean-up of the database by the LIR's! Daniel Karrenberg observed that initially this will only be applicable for new objects. The clean-up will come later. Kevin Hoadley asked for some time to implement the necessary changes to local scripts and procedures. The following discussion led to a proposal to start enforcing this on the 1st of January 1997. A. Blasco Bonito asked about potential implications of making the 'status:' attribute mandatory. Carol Orange suggested to define an additional value for the status: (USED?) to distinguish between address space allocations, assignments and usage. A. Blasco Bonito's comment that "The general attitude of LIR's who are large providers is to assign to other smaller providers. These then distribute to their customers." prompted Daniel Karrenberg to state that "If this is the case then they are not following the registration policies." A mandatory status: attribute has implications that have to be discussed in more detail. Z. AOB Brian Renaud proposed to obsolete the advisory: attribute for aut-num: objects. For 'route:' objects, these atrtributes should remain valid. Ther was general agreement and the NCC was asked to implement that change. Following up on a mail received from David Kessens, ther was a review of the various mailing lists that dal with different aspects of the database business. These are: DB-WG DB-BETA RRIMPL Daniel Karrenberg described the scope of these lists and observed that all three have their own specific use: - DB-BETA is for people running new code. - DB-WG is for architecture discussions - RRIMPL has a wider scope Bugs in the released version of the RIPE DB-SW should be submitted to ripe-dbm(a)ripe.net discussions about details of running new code should go to db-beta@ripe-net. Sabine Dolderer observed that if there are two maintainers then the "weakest" one is used. Daniel Karrenberg pointed out 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. This is the correct behaviour as all maintainers are equally authorized. To allow specific maintainer functions is at the moment beyond the functionality of the DB. Appendix: New actions [The relative numbering is going to change to match the full meeting minutes] 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 aut-num: objects. Action (12) on RIPE NCC (Ambrose Magee), To add mailing lists with their descriptions to the database documents. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -WW, 9-OCT-1996 20:05:57

2 1

Slides of RIPE Database 2.0 Workshop
by RIPE Database Administration 10 Oct '96

10 Oct '96

Dear Colleagues, The slides for the RIPE Database 2.0 Workshop (held during the recent RIPE meeting) are available at: ftp://ftp.ripe.net/ripe/presentations/ripe-m25-orange-DB-Workshop.ps.tar.gz Please send any comments to <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

1 0