- db-wg - mailman.ripe.net

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

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

10 Oct '96

=> 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. = =One note on this one: = =The new software doesn't create a new object anymore when adding a NIC =handle to an existing object. It will only do this when there are other =differences between the new and old object then the 'changed:' and the =added NIC handle attribute. Thanks for the note. => 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. = =Wasn't this proposal on the wish list for a long, long time (and even =accepted by the database working group as a good thing) ?!? = =davidk> List of current proposals: =davidk> =davidk> 5) whois -tv Yes it was. I'll re-word that to properly reflect history. From the technical point of view, it doesn't hurt to propose it again for implementation :-) => Action (11) on RIPE NCC (Ambrose Magee), => To change the DB-SW to obsolete the advisory: attribute in inetnum: objects. = ^^^^^^^^ = =No further comments ... ;-) That's the fate of lazy people (like me) who do a cut-n-paste from the local *broken* copy. Yours, standing at the corner of the room, and facing the walls, Wilfried.

1 0

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

09 Oct '96

Hi David ! => Z. AOB => - clarification abou mailing lists => - obsolete advisories in inetnum objects => => Action (11) on RIPE NCC (Ambrose Magee), => To change the DB-SW to obsolete the advisory: attribute in inetnum: objects. = =Just to avoid even more confusion on this trickey advisory topic: = =I assume you are talking about the 'aut-num:' object since the 'inetnum:' =object never had support for this ... You're right, of course. I was mixed up, and John's notes are correct anyway! Could the minute folks at the NCC (Roderik?) please fix the text ? Thanks and apologies, Wilfried.

1 0

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