diverging views on adding range constraints in MIB module revisions

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

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.

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.

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

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.

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.

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 (*).

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.