Re: coex draft last call -- review of Section 2

After carefully reviewing Section 2 of the coex draft
draft-ietf-snmpv3-coex-v2-02.txt I find that I agree
with all but two paragraphs.

- The first problem is in item (3) of the first numbered list in
Section 2.1.1:

(3)  For any object with an integer-valued SYNTAX clause, in which the
     corresponding INTEGER does not have a range restriction (i.e., the
     INTEGER has neither a defined set of named-number enumerations nor
     an assignment of lower- and upper-bounds on its value), the object
     MUST have the value of its SYNTAX clause changed to Integer32, or
     have an appropriate range specified.

The question I have is why this is a "MUST" and not a "SHOULD".  If
I am correct in my reading of RFC 2578 -- and I'm sure that someone
will promptly let me know if I'm not -- then there is nothing illegal
about an INTEGER with no subrange or enumerations;  in fact it's
completely equivalent to Integer32 with no subrange.  In view of
this, it seems that the "MUST" in this statement is unjustified.

In attempting to figure out where this restriction came from, I
found that this provision dates back to RFC 1452 and was carried
unchanged into RFC 1908, RFC 2576, and the present draft.  Now,
at that time (April 1993 -- nearly a decade ago!) the then-current
SMIv2 document, RFC 1442, did in fact prohibit plain INTEGER with
no subrange or enumeration:

RFC 1442, Section 7.1.1, "Integer32 and INTEGER":

   The Integer32 type represents integer-valued information between
   -2^31 and 2^31-1 inclusive (-2147483648 to 2147483647 decimal).  This
   type is indistinguishable from the INTEGER type.

   The INTEGER type may also be used to represent integer-valued
   information, if it contains named-number enumerations, or if it is
   sub-typed to be more constrained than the Integer32 type.  In the
   former case, only those named-numbers so enumerated may be present as
   a value.  Note that although it is recommended that enumerated values
   start at 1 and be numbered contiguously, any valid value for
   Integer32 is allowed for an enumerated value and, further, enumerated
   values needn't be contiguously assigned.

This language was relaxed in the next revision -- this is from RFC 1902,
Section 7.1.1, "Integer32 and INTEGER":

   The Integer32 type represents integer-valued information between
   -2^31 and 2^31-1 inclusive (-2147483648 to 2147483647 decimal).  This
   type is indistinguishable from the INTEGER type.  Both the INTEGER
   and Integer32 types may be sub-typed to be more constrained than the
   Integer32 type.

   The INTEGER type may also be used to represent integer-valued
   information as named-number enumerations.  In this case, only those
   named-numbers so enumerated may be present as a value.  Note that
   although it is recommended that enumerated values start at 1 and be
   numbered contiguously, any valid value for Integer32 is allowed for
   an enumerated value and, further, enumerated values needn't be
   contiguously assigned.

That was left unchanged in RFC 2578, Section 7.1.1, "Integer32 and
INTEGER", except for the clarification regarding enumerations:

   The Integer32 type represents integer-valued information between
   -2^31 and 2^31-1 inclusive (-2147483648 to 2147483647 decimal).  This
   type is indistinguishable from the INTEGER type.  Both the INTEGER
   and Integer32 types may be sub-typed to be more constrained than the
   Integer32 type.

   The INTEGER type (but not the Integer32 type) may also be used to
   represent integer-valued information as named-number enumerations.
   In this case, only those named-numbers so enumerated may be present
   as a value.  Note that although it is recommended that enumerated
   values start at 1 and be numbered contiguously, any valid value for
   Integer32 is allowed for an enumerated value and, further, enumerated
   values needn't be contiguously assigned.

It appears to me that the questionable provision was erroneously carried
forward from the very first vers ionof the coex document.  So unless
someone can give a good reason why this provision should stay, I suggest
the following fix:  change "MUST" to "SHOULD" and move this paragraph
into the 2nd list in Section 2.1.1 (i.e., the list of changes that are
desirable but not absolutely required).

- The second issue is with regard to the last paragraph of Section 2.3:

   In order to ease coexistence, object groups defined in an SMIv1
   compliant MIB module may be referenced by the INCLUDES clause of an
   invocation of the AGENT-CAPABILITIES macro:  upon encountering a
   reference to an OBJECT IDENTIFIER subtree defined in an SMIv1 MIB
   module, all leaf objects which are subordinate to the subtree and
   have a STATUS clause value of mandatory are deemed to be INCLUDEd.
   (Note that this method is ambiguous when different revisions of an
   SMIv1 MIB have different sets of mandatory objects under the same
   subtree; in such cases, the only solution is to rewrite the MIB using
   the SMIv2 in order to define the object groups unambiguously.)

I know that this has been around since RFC 1908 (that seems to be
where it was introduced), but I wonder if the popular MIB compilers
actually support it (Dave, Juergen, Frank, please speak up).  I've
not checked SMICng but my poking around with smilint-0.4.1 suggests
that support there is partial at best (actual membership in imported
"groups" doesn't seem to be checked).  If this is not actually
supported in implementations I would recommend that it be removed
from the spec, since it's not mentioned in RFC 2580 and so is not
guaranteed to be supported by an SMIv2-compliant MIB compiler.

//cmh