Re: List of known bugs.

[Daniel Karrenberg <]

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

How about 'createobj'? 
Not very likely to be a common word in subject lines.

the other possibility is to do away with the subject line stuff
and create a real command interface. Actually I prefer the latter.

  > >   Again, I don't support throwing in more tests at random.
  > >   Instead I'd like to see structural tests that can be defined ...
  > 
  > 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.

I agree with Wilfried. Let's look at consistency in a structured manner.
We have the folks of the free university doing just that and we will
report in January.

from a practical standpoint the 'large range' warning is cateches 
very embarrassing mistakes and generates not too many false warnings.
So it should be kept for now.

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

Keep it. Changing it will break people's schemes and the errors can
be corrected easily.

Daniel

About the stuff from ripe-181: Ambrose, please draft a short(!) note
saying what changed since then database wide and publish it as a RIPE
document updateing 181.

Daniel