[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: diverging views on adding range constraints in MIB module revisions
Mike first a thank you to analyze and summarize where we are
w.r.t. these issues.
Commens inline.
Thanks,
Bert
> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: zondag 23 februari 2003 21:33
> To: Mreview (E-mail)
> Subject: diverging views on adding range constraints in MIB module
> revisions
>
>
> Hello,
>
> In off-line e-mail exchanges with some of the other MIB doctors it
> became apparent to me that there is some divergence of opinion on
> how much latitude should be allowed in revisions of standards-track
> MIB modules -- in other words, different reviewers might well give
> different answers on whether certain changes are allowed,
> particularly for modules that are recycling at Proposed Standard
> rather than being advanced. I'm bringing this up here because it
> seems to go against one of the objectives that Bert has laid out for
> the MIB review guidelines document, viz., to
>
> > - Try to come to a consistent review of different MIB
> > documents, even if done by different MIB doctors.
> > Of course there are always personal flavors and
> > subsjective comments... but with such a document,
> > we should at least not bother people with inconsistent
> > comments on various MIB and SMIv2 aspects.
>
So... with the new guidelines revision 1, what I would hope is
that we as MIB Doctors/Reviewers do the following:
- we review according to the guidelines.
- we can post comments/concerns that are based on the guidelines
to the authors and the appropriate (WG) mailing list(s).
- issues where we are not sure, or issues that are not yet
covered by the guidelines... pls bring those to the mreview
mailing list first. This serves multiple purposes:
- we find what sort of things are not yet covered by our guidelines
- we can try to come up with a consensus on the issue (e.g. if
it is really an issue or just one reviewers preference, etc).
- In fact, it might alos be good, that before we post any review
comments to a author/wg list, that we post it to mreview for
a few days for anyone to check if they see any serious troiuble
with that. I know that this is somewhat an extra step and more
work for all of us... but i think it WILL make the reviews much
more consistent (and thus in my view better).
> 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.
> Section 4.9 of the MIB review guidelines has this to say:
>
> RFC 2578 Section 10.2 specifies rules that apply to revisions of
> object definitions. The following guidelines correct some errors
> in these rules and provided some clarifications:
> [ ... ]
> - Although not specifically permitted in bullets (1) through (8),
> it is generally considered acceptable to add range constraints
> to the SYNTAX clause of an integer-valued object, provided that
> the constraints simply make explicit some value restrictions
> that were implicit in the definition of the object. The most
> common example is an auxiliary object with a SYNTAX of INTEGER
> or Integer32 with no range constraint. Since an auxiliary
> object is not permitted to assume negative values, adding the
> range constraint (0..2147483647) cannot possibly result in any
> "over the wire" change, nor will it cause any compilation
> compatibility problems with a correctly written MIB module.
> Such a change SHOULD be treated by a reviewer as an editorial
> change, not as a semantic change.
>
> So, the guidelines would condone changing the SYNTAX value above to
> Integer32 (0..2147483647), treating it as if it were an editorial
> change to the SYNTAX clause. So far, I don't think there is any
> disagreement (but if there is it would be good to know).
I agree sofar.
>
> 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 }
>
> Absent a better reason other than "tidying up", I would say no,
> because this _is_ a semantic change that _could_ lead to
> interoperability problems. It's true that our guidelines say not to
> use zero in an index (except in special cases that apparently do not
> apply here), but in my view that consideration is trumped by
> considerations of backward compatibility with an installed base.
> Here are the backward compatibility problems I can think of that
> might arise from making such a change:
>
> | agent using | agent using
> | old definition | new definition
> ----------------+----------------+------------------
> | | manager could
> | | request creation
> | | of a row with
> manager using | | index value zero
> old definition | | which agent would
> | | refuse, even
> | | though no such
> | | row was present
> ----------------+----------------+------------------
> | agent might |
> | create a row |
> manager using | with index |
> new definition | value zero |
> | which manager |
> | might not find |
> ----------------+----------------+------------------
>
> If the revision includes a more restrictive range than
> (1..2147483647) then change the words "with index value zero"
> to "with an index value outside the stated range".
>
> How serious these problems would be in practice would of course
> depend on what the installed base actually does. An IETF working
> group, however, cannot have assurances of being able to uncover
> what all (or even most) of the installed base does. So, in such a
> situation I would advise the WG not to make such a change just for
> cosmetic reasons, even in a spec that is recycling at PS. I would
> further think that such a change would disqualify a spec from
> advancing to DS (even if justified by reasons better than cosmetic
> ones) because it could invalidate the interoperability reports.
>
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).
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.
> 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
> If indeed there is disagreement on this point please let me know so
> that I can put it on the list of open issues related to the MIB
> review guidelines document (*).
>
I'd suggest that if we're all willing to give this a try, that we leave
it where it is, and that we try to get consensus on such issues on
this mreview list when they come up.
Bert
> Thanks,
>
> Mike
>
> (*) The -01 draft was submitted last night, and the list of open
> issues (to be posted to the mibs@ops.ietf.org list after the
> announcement comes out) tentatively includes the following items:
>
> - Instructions for copyright notices in IANA-maintained MIB modules
> need to be added to Section 3.8 (details await the outcome of
> discussions between the IESG and IANA).
>
> - No consensus was reached on making it RECOMMENDED to put items
> used by MCs and ACs in the IMPORTS statement, so (for now) Section
> 4.4 retains the neutral "MAY" language.
>
> - The include file in Appendix C may need to be updated; the editor
> is awaiting further input.
>
>