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

>>>>> C M Heard writes:

Mike> - The second issue is with regard to the last paragraph of
Mike> 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.)

Mike> I know that this has been around since RFC 1908 (that seems to
Mike> be where it was introduced), but I wonder if the popular MIB
Mike> compilers actually support it (Dave, Juergen, Frank, please
Mike> speak up).

I do not think that libsmi implements this feature. I think it would
be doable to add this with a reasonable amount of programming but I
doubt that it is worth the effort.

Mike> I've not checked SMICng but my poking around with smilint-0.4.1
Mike> suggests that support there is partial at best (actual
Mike> membership in imported "groups" doesn't seem to be checked).  If
Mike> this is not actually supported in implementations I would
Mike> recommend that it be removed from the spec, since it's not
Mike> mentioned in RFC 2580 and so is not guaranteed to be supported
Mike> by an SMIv2-compliant MIB compiler.

My understanding is that this rule is irrelevant for SMIv2 and thus
for SMIv2 compliance. The purpose of this rules is to allow agent
capabilities macro invocations to refer to SMIv1 definitions which
have no defined object groups.  Personally, I think this rules does
not solve the problem as it is ambiguous. I think the correct way to
handle this case is in fact to convert the module to SMIv2 and to
define suitable object groups or to at least to define object groups
that reference SMIv1 object type definitions.

Bottom line: I have no problem with getting rid of this text.

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>