Re: List of known bugs.

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@localhost
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@localhost
>
>        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.
---