On the mreview@ops.ietf.org list, I suggested to add a new error level 7 for "esoteric notices". The idea is to change the default error to level 7 for those warnings which the IETF MIB review guidelines document considers to be not important or noise (such as namelength-32 or case-redefinitions).
This means that MIB reviewers following the IETF guidelines can simply run `smilint -c /dev/null -l 6' to get the right amount of warnings produced.
Frank, do you agree with this chance? Is there anyone against introducing level 7 as described above? Let me know quickly so that I can put this in place next week.
/js
Hi!
Juergen> On the mreview@ops.ietf.org list, I suggested to add a new error Juergen> level 7 for "esoteric notices". The idea is to change the default Juergen> error to level 7 for those warnings which the IETF MIB review Juergen> guidelines document considers to be not important or noise (such as Juergen> namelength-32 or case-redefinitions).
Juergen> This means that MIB reviewers following the IETF guidelines can simply Juergen> run `smilint -c /dev/null -l 6' to get the right amount of warnings Juergen> produced.
Juergen> Frank, do you agree with this chance? [...]
I have no objection against this proposal and I think it would give a majority (as far as I can tell) of smilint users the chance to have a straight line between interesting and non-interesting errors/warnings. So, it's good and I agree.
However, I think *in general* the space of error checks is "multi-dimensional" and cannot easily be devided into interesting and non-interesting checks by a one-dimensional threshold. But following the XP style, I'm fine with what we have (and the addition of level 7). :-)
-frank
Frank Strauss writes:
Frank> However, I think *in general* the space of error checks is Frank> "multi-dimensional" and cannot easily be devided into Frank> interesting and non-interesting checks by a one-dimensional Frank> threshold.
Sure - and smilint fortunately makes all the error levels configurable. But still, having a default which conforms to guidelines document makes life for many people simpler. The real question is (and I perhaps was not clear enough about this) is whether we really need a new error level 7 or whether the same objective could be achieved by using the existing error level 6 for "esoteric" messages and simply recommend that reviewers use level 5 for their reviews. This approach would mean that we reclassify some existing level 6 messages to level 5 messages.
Looking at some of the current level 6 messages, I actually think they should be raised to level 4 (e.g. ERR_EMPTY_ORGANIZATION et. al.) so perhaps sticking with just 6 levels is not even a bad idea...
/js
Hi!
Frank> However, I think *in general* the space of error checks is Frank> "multi-dimensional" and cannot easily be devided into Frank> interesting and non-interesting checks by a one-dimensional Frank> threshold.
Juergen> Sure - and smilint fortunately makes all the error levels Juergen> configurable. But still, having a default which conforms to Juergen> guidelines document makes life for many people simpler. The Juergen> real question is (and I perhaps was not clear enough about Juergen> this) is whether we really need a new error level 7 or Juergen> whether the same objective could be achieved by using the Juergen> existing error level 6 for "esoteric" messages and simply Juergen> recommend that reviewers use level 5 for their reviews. This Juergen> approach would mean that we reclassify some existing level 6 Juergen> messages to level 5 messages.
Juergen> Looking at some of the current level 6 messages, I actually Juergen> think they should be raised to level 4 Juergen> (e.g. ERR_EMPTY_ORGANIZATION et. al.) so perhaps sticking Juergen> with just 6 levels is not even a bad idea...
That's also fine with me. With the current level descriptions, I cannot say what the real distinction between 5 and 6 should be. I have just a clear understanding about 0..5 and I don't care about further levels.
0 internal error, no recovery possible, 1 major SMI/SPPI error, recovery somehow possible but may lead to severe problems, 2 SMI/SPPI error, probably tolerated by some implementations, 3 SMI/SPPI error, tolerated by many implementations, 4 something which is recommended to be changed, 5 something that might be ok, but might not be recommended under some circumstances, 6 just a notice.
I agree, that the list in error.c should be revised carefully. In a number of cases levels should be adjusted and error tags should be added.
Another idea that came to my mind, is to add a much more verbose description to errors, since for errors like "index element `%s::%s' of row `%s' should but cannot have a size restriction" I would wonder if people get this error and do NOT ask what it means. :-)
-frank
HI,
By the way, since there are many rules in the SMI that says some thing like, "this is OK if it comes from a MIB module written following the rules in SMIv1 and converted to SMIv2", there is no set of checking that can be performed on any MIB module. That is, one must perform strict checking, and then look at the results and turn off individual items after they have been verified to be OK.
But, I'm sure you already knew this.
At 01:11 PM 2/19/2003 +0100, Frank Strauss wrote:
Hi!
Juergen> On the mreview@ops.ietf.org list, I suggested to add a new error Juergen> level 7 for "esoteric notices". The idea is to change the default Juergen> error to level 7 for those warnings which the IETF MIB review Juergen> guidelines document considers to be not important or noise (such as Juergen> namelength-32 or case-redefinitions).
Juergen> This means that MIB reviewers following the IETF guidelines can simply Juergen> run `smilint -c /dev/null -l 6' to get the right amount of warnings Juergen> produced.
Juergen> Frank, do you agree with this chance? [...]
I have no objection against this proposal and I think it would give a majority (as far as I can tell) of smilint users the chance to have a straight line between interesting and non-interesting errors/warnings. So, it's good and I agree.
However, I think *in general* the space of error checks is "multi-dimensional" and cannot easily be devided into interesting and non-interesting checks by a one-dimensional threshold. But following the XP style, I'm fine with what we have (and the addition of level 7). :-)
-frank
Regards, /david t. perkins
David T Perkins writes:
David> That is, one must perform strict checking, and then look at the David> results and turn off individual items after they have been David> verified to be OK.
Sure - one has to look at the generated warnings. Blindly changing MIBs is not smart. Blindly turning warnings also does not help, especially since you really want to turn a warning off for a specific definition rather than for the whole module. I personally prefer that definitions causing warnings simply get documented/explained in appropriate comments in MIBs.
Anyway, we were talking here about moving some warnings to a level which is usually not active during MIB reviews. Examples are warnings that descriptors only differ in case (which is important if you plan to map e.g. to CORBA IDL but not really an SMIv2 requirement) or the 32 character length requirement (which people do not consider that important these days).
/js
participants (3)
-
David T. Perkins -
Frank Strauss -
Juergen Schoenwaelder