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