Hi Ambrose,

RIPE Database Administration writes :

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

I have a couple of comments on things that you list as bug that might sometimes be better listed as a feature or are not as a bug at all...: under persons:

2/. FEATURE Titles such as "Dhr" will be interpreted as names; a request to create a person object for "Dhr J Russell" will receive a nic-hdl = DJR#-RIPE, not JR#-RIPE.

3/. FEATURE Titles such as "Mr" will be rejected.

2 & 3 are the same issue. The software has a built in list of common titles. However, such a list can never be complete and making it complete might hurt people that speak other languages and that might have a common title in one country as their first name in their local language. Therefore I included a short list (that contains Mr(s)/Dr among others) that would catch most of the problems. Of course, any very common title that I forgot can be added if desired so.

4/. A person object may be created with a nic-hdl of the form ASxxxx, even if there is an aut-num object with the same AS number. A whois enquiry on ASxxxx will retrieve both objects.

What's the bug here ? It is perfectly valid to have AS# as your InterNIC handle and it can indeed also be a valid AS number at the same time: $ internic AS100 Sackheim, Andy (AS100) andys@DAVSYS.COM daVinci Systems, Inc. 5410 NW 33d Ave Suite 100 Ft. Lauderdale, FL 33309 (305) 484-8100 In the past there was a bug in the database software that would regard AS# as an AS number and thus wouldn't look up any persons that had the same AS# as their NIC handle.

5/. The Auto-Nic-Hdl mechanism allows a maximum of four initials.

However, when using the finger handle mechanism, a RIPE nic-hdl may be generated which has more than 11 characters e.g.

ambrose $finger handle.AMBROSE@whois.ripe.net

gives

First free handle: AMBROSE251-RIPE.

I think that the limit of four is a healthy limit. This limit can be increased if desired. It seems that the bug is in the finger tool, not in the Auto_Nic-hdl mechanism. The problem here is that there is never decided about a formal limit on the number of initials.

6/. When a pseudo-person object is deleted, and its nic-handle used in a genuine role object, the role object is not found using a recursive look-up, even though it is in the database.

This is not true. The problem some people might have had was: role objects are not allowed in 'admin-c:' fields as decided by the database workinggroup. The software is optimized to not do unnessecary lookups and will thus not do a lookup for a role object in 'admin-c:' fields. The real bug is thus that there is no check that disallows the use of role objects in 'admin-c:' fields, this is not possible right now due to the lack of the 'non-existing references' checking (which is a known problem!). The problem can be softened by changing the config file and allowing role objects in the 'admin-c:' fields (for lookups). However, this defeats the decision made by the database working group for not allowing role objects in the 'admin-c:' field... In all objects:

1/. The "NEW" keyword is case insensitive. If it appears anywhere in the Subject line of an update, the update will be disallowed with the message "ERROR: object already exists".

E.g. an update with the following in its header:

Subject: Old person object, but new address.

This is a feature but probably not a very desirable one... I think it is a good thing to keep the keywords case insensitive (this was also the case for LONGACK), however something a less common word then NEW could solve this problem just like LONGACK (nobody is using that in real life ;-)) or keep an exception for NEW only ... In routes:

2/. RIPE-181 states that the guardian attribute is mandatory in the aut-num object. However, it is optional in the database template.

This is change decided by the database working group some time ago. Some people would like to go even further and would like to obsolete the attribute altogether or convert it to 'notify:' attributes.

3/. RIPE-181 states that "Whenever a route object is created or deleted or the comm-list attribute changes, the guardians of all communities and ASes referenced by the old and new objects will be notified in addition

The 'guardian:' attribute is behaving exactly as a 'notify:' attribute.

From the 2.0 release notes:

- All support for the historical 'guarded' objects have been removed. The guardian attribute can be obsoleted if the database working group wishes to. Present guardian attributes will act as a 'notify:' attribute. In inetnum:

2/. An inetnum object may be created with an range limit of *.*.*.* - 255.255.255.255; a warning will be generated, but the entry will be allowed.

This can be solved with an hierarchical authorization 'inetnum:' object. I don't think it's a good idea to include thousands of specific tests for problems that happen only once in 1,000,000 updates. These kind of tests tend to cause more harm then solving anything: If you disallow 255.255.255.255 people can still do 255.255.0.0 or 10.0.0.0 - 194.0.0.0. However, in *all* cases the software will issue a warning that you used a very large range and asks the user to check if that was intended. This should catch most of these problems. Furthermore, this kind of errors is so obvious that other people will report it very, very soon when found as happened recently ... In maintainer objects:

1/. Use of MAIL-FROM authorisation:

use the full e-mail address gievn in the "From" field of the mail header of the update message.

This is not true. You may use part of the E-mail address, however be warned that the matching is done case-sensitive as specified by RFC822 (this is in fact sometimes a very nice security by obscurity mechanism ;-)) David K. ---