Hi Wilfried,

Wilfried Woeber, UniVie/ACOnet writes :

Sorry for the sarcasm, but we seem to be doing some reverse intent engineering these days..

True. But I also see most of it was documented somewhere but not always easily to find ;-( although it is *all* known at the NCC. I hope Ambrose can do this better (and has time to actually do it since I usually had only the choice of adding the AUTO-NIC-HANDLE feature OR documenting it ... :-().

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

The mirroring is completely content independant. There is one part missing: it does't tell the mirror it's own configuration (yet), so doing object configuration changes can be a bit of a pain right now...

Shouldn't that move to somehow, somewhere into the update interface, and maybe be made controllable?

It's now in the defines file (that professionnals can find very easily). I wanted too have it easy configurable but not too easy so I didn't put it in the configuration file. This can of course easily be changed. I feel that a small set of very common titles will catch most of the problems and changing this at every local RIPE database site might cause confusion.

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

In fact I tried this out first with 3 for this reason but found that this was not feasible due to the number of old objects that used already 4 initials ...

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

Exactly ;-).

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

Very good. But what do you want to advise Ambrose: Change the config file for now (note: this only affects lookups at this point since the 'non-existing references' is still missing) or let the current (also) undesirable behavior persist (at least it catches the error manually) until the software has the necessary support for catching role objects in 'admin-c' fields which needs the very wanted 'non-existing references' feature. I choose the last solution but knew that it could and can be changed in the configuration file easily if I made the wrong choice. I had to make a lot of these trade-offs in the brand new release and am sure that there are many of those choices made that people actually like (and thus go unnoticed). This is a problem for every software developer that has to make these decisions at his own and in time before the release date. I always did them in such a way that it could be configured in the other way if the database working group requested to change it (and so I did a couple of times).

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

Agreed. I used dots for a reason ;-). I would prefer to use another uncommon word or a clear separator. I just don't like case sensitivity lazy as I am...

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

Very good.

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

The last release made it at least simpler. My experience was that nobody understood the difference and thus explaining became much easier when the difference was eliminated (Note: I was not able to read in the old code what the current behavior exactly was :-(, it was different from the spec though...). Of course there is not much reason to keep two the same attributes. That's exactly the reason why I personnally support a conversion of all existing 'guardian' attributes to 'notify:' attributes and then obsoleting the whole thing as soon as possible (probably also a good time to take care of the remaining advisory attributes also ;-)). The guardian attribute is just a remaining of the old authorization mechanism that has been discarded in favor of the 'maintainer' based scheme.

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

Agreed. That was the reason I added the generic warning for large ranges, that should only occur occassionaly for people that really know what they are doing (usually at least 'allocation' sized objects) while catching most of this kind of problems. Your test is even better but at this point probably a bit to labor intensive compared to other more necessary work as things like the 'non-existing references' checks.

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

This is the way the software behaves since the stone age of the RIPE database and as specified in the appropriate RIPE document. This discussion also came up about a year ago, and it was then decided to keep it as it was. It can easily be changed (It's a one letter change) and I am happy to send the patch to Ambrose ;-) since I also don't like this case-sensititive feature and case-sensitivity in general (but you already knew that ;-)), I hope this lengthy mail is of any use :-), David K. ---