List of known 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...:

  But then at least as an undocumented wiseguy approach. 
  Sorry for the sarcasm, but we seem to be doing some reverse intent
  engineering these days..

=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.

  I have to think about that. PArt o fme likes the approach, the other one
  thinks it's a *very* bad idea to have potentially different reject lists.
  How does that interact with NRT-Mirroring in particular and object exchange
  in general?
  
  Shouldn't that move to somehow, somewhere into the update interface, and
  maybe be made controllable?

=> 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 at DAVSYS.COM
=daVinci Systems, Inc.
=5410 NW 33d Ave Suite 100
=Ft. Lauderdale, FL 33309
=(305) 484-8100

  Agreed. No bug. We have the -T flag to control the software behaviour.

=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 at 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. 

  No, I think 4 is definitely the maximum. If we had enforced a limit of 3,
  we wouldn't have had less ambiguity with AUTO-x and the like. But now it's
  4, so let's stick with it.

=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.
=

  As the finger tool is to be decommissioned anyway, so what.

=> 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.

  Another wiseguy approach. We know, that we cannot guarantee integrity.
  Unless we change the very basic maintainance model, that is. Thus
  the SW should *not* imply integrity

= 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).

  That's exactly the other way 'round. Note that we had input recently from
  other WGs to tighten the rules and have the SW enforce the decisions.

=However, this defeats the decision made by the database working group for
=not allowing role objects in the 'admin-c:' field...

  We have discussed that and I expect some activity towards closing that gap
  in the foreseeable future.

=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 agree, about the not very desirable :-)

=I think it is
=a good thing to keep the keywords case insensitive (this was also the case
=for LONGACK), 

  It depends, see below

=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 ...

  Not just *another* exception please !!
  
  My preference would be for a real solution.
  Enforcing UPPERCASE is the minimum. 
  I'd even vote for addtional constraints, like FLAG only being recognized at
  the very begging/end of the line, or even requiring some special characters
  to surround the FLAG string.
  Pick your favourite convention, like double quotes, html brackets,...

=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.

  Unless I forget, I'll put it on the agenda for the January RIPE Meeting to
  obsolete it.
                
=> 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.

  Ditto. Another source for complexity.

=
=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.

  For that special case I agree.

=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 ...

  Again, I don't support throwing in more tests at random.
  Instead I'd like to see structural tests that can be defined, implemented
  easily (concept-wise) and enforced by the IR rules. E.g. addess ranges must
  not overlap each other and should be in line wity registry allocations,
  etc. We're discussing this issue already.

=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 ;-))

  Well for the "nice" :-/

  Is this in line with the notfication suppression logic?

  I don't think this is a good idea at all. 
  Even if it's in the Books, what do we want to achieve by trying to enforce
  it? I think reality in the Mail environment is (mostly) caseINsensitive
  these days...

=David K.

  Comments, please!

  Cheers,
  Wilfried.