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