RE: diverging views on adding range constraints in MIB modulerevisions

["C. M. Heard" <heard@pobox.com>]

On Mon, 24 Feb 2003, Wijnen, Bert (Bert) wrote:
> [Mike Heard wrote:]
> > One specific question that has come up in connection with more than
> > one MIB module is what to do about index objects like this:
> > 
> > xxxZzzIndex OBJECT-TYPE
> >     SYNTAX     Integer32
> >     MAX-ACCESS not-accessible
> >     STATUS     current
> >     DESCRIPTION
> >         "A unique value to identify the row."
> >     ::= { xxxZzzEntry 1 }
> > 
> > This definition is permitted by SMIv2 rules but it is something that
> > would not be allowed to go unchallenged in a review of a
> > newly-defined MIB module. In particular, we would ask for a range
> > constraint that excludes negative values (always) and zero (because
> > it has no semantic significance in this definition and is not
> > reserved for special cases).  There was some question, however, of
> > what to do with an existing definition like this whan a MIB module
> > is revised.
> > 
> Let me first state, that if we start to be consistent in our reviews,
> then we should indeed challenge the above definition for a new
> MIB or for one that moves from experimental onto stds track.

I agree with this.  I hadn't considered the situation of a MIB module
that is moving from experimental to stds track, but since all the
definitions get new OIDs (by moving from experimental to mib-2 or
some other place under mgmt) they are really "new" definitions.

[ snip agreement on change to Integer32 (0..2147483647) being OK]

> > On the other hand, should a revision like this be allowed?
> > 
> > xxxZzzIndex OBJECT-TYPE
> >     SYNTAX     Integer32 (1..2147483647)  -- or maybe (1..65535)
> >     MAX-ACCESS not-accessible
> >     STATUS     current
> >     DESCRIPTION
> >         "A unique value to identify the row."
> >     ::= { xxxZzzEntry 1 }
[ ... ]
> I agree that I would be concerned if they wanted to advance on the
> stds track with such changes. I am not saying that I would always
> absolutely forbid it. I believe I have seen cases, where one can
> defend the "we're fixing a bug" or "we're fixing it so that it
> defines it as we originally intended". Of course I would try to make
> very sure that all the involved parties agree on such a change (and
> I know it is very difficult to ensure that... but we should have a
> warm feeling that it is pretty sure before we go along).

I might be a lot harder to convince that you would be in a specific
case, but I think I can agree with the principle.

> Of course when it recycles at PS, the same concerns should be
> raised and taken into account, but in such a case I am easier to
> be convinced. 

That's fair.

> > Now, the guidelines doc (at Juergen's suggestion) does say that it
> > is sometimes OK to break the SMIv2 rules governing revisions to MIB
> > modules, but only when the cost of following the rules outweighs the
> > benefit.  I don't think that cosmetic changes (such as the ex post
> > facto exclusion of zero from the values an integer-valued index
> > can take) fall into that category.
> > 
> Difficult to say. When we see these things we should CERTAINLY QUESTION
> the authors and the WG if they understand what they are doing and why
> they are breaking the rules. I do not believe that we can easily give
> a fixed rule as to what to do in such cases. I think we need to handle
> it case by case. I would love it if we could agree that we would bring
> such issues to this mreview mailing list and try to get to consensus
> with the whole set of MIB doctors/reviewers. Are we willing to take
> that pain. The benefit of course is better evaluation and hopefully
> a warmer feeling that it is kind-of-OK-anddoes-not-break-much
> if we in fact do violate the SMI rules after we have consensus in 
> such cases
[ ... ]
> I'd suggest that if we're all willing to give this a try, that we
> leave [the guidelines issues list] where it is, and that we try
> to get consensus on such issues on this mreview list when they
> come up.

I like this idea very much.  There will always be corner cases that
don't come up very often or that are unanticipated, and it would be
counterproductive to try to write down guidelines to handle them
all.  Consulting with the other MIB doctors (aka designated experts)
is absolutely the right thing to so in situations that aren't so
clear.  I've done that before informally, and it's good to have that
practice somewaht formalized by being able to take questions to the
mreview list.

Thanks for the feedback.

Mike