Re: guidelines 4.8 (read-only + full compliances)

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

[ in reply to comments/review <draft-ietf-ops-mib-review-guidelines-00.txt> ]

On Fri, 7 Feb 2003, Wijnen, Bert (Bert) wrote:
> - last bullet on page 21
>   I'd actually remove the last few words. SO I would change
> 
>      example is provided by the DIFFSERV-MIB [RFC3289].  Authors SHOULD
>      consider using this technique in situations where it is
>      appropriate.
> 
>   into
> 
>      example is provided by the DIFFSERV-MIB [RFC3289].  Authors SHOULD
>      consider using this technique.
> 
>   Or maybe the last sentence:
> 
>      It is strongly RECOMMENDED to use this technique.
> 
>   because I think it makes it MUCH easier for an agent to express
>   what it complies with, and so it potentially makes things easier
>   on the manager (assuming everyone implements correctly and makes
>   correct claims).

I don't want to recommend that people use this technique in situations
in which it does not apply -- as would obviously be the case if all the
objects in the MIB were read-only.  So how about:

   - On the other side of the coin, MIB module authors need to be aware
     that while a read-only compliance statement is sufficient to
     support interoperable monitoring applications, it is not sufficient
     to support interoperable configuration applications.  A technique
     commonly used in MIB modules that are intended to support both
     monitoring and configuration is to provide both a read-only
     compliance statement and a full compliance statement.  A good
     example is provided by the DIFFSERV-MIB [RFC3289].  Authors SHOULD
     consider using this technique when it is applicable.
___________________________________^^^^^^^^^^^^^^^^^^^^^

I think that the narrative makes it clear that the technique does
apply to MIB modules like DIFFSERV-MIB that are intended to support
both monitoring (which can be done read-only) and configuration
(which obviously requires a lot of read-write and probably
read-create stuff).  And it obviously does not apply to a read-only
MIB.  There is of course a continuum between those two extremes, and
in such cases I want people to THINK about ("consider") what applies
to their MIBs.  That's why I'm resisting a blanket recommendation.

Let me give you one example of some MIB modules with writeable
objects where I think that having a full compliance in addition to a
read-only compliance would not have been very useful.  The trunk
MIBs (DS1, DS3, and SONET) date back to about a decade ago and were
written with monitoring applications in mind, which was the main
focus of SNMP in those days.  Configuration was for the most part
intended to be left to proprietary means, e.g., enterprise MIB
modules.  There are, however, a few read-write objects in the trunk
MIBs because some of the implementors preferred to use writeable
versions of standard objects instead of defining duplicate objects
for those functions in their enterprise MIBs.  In other words, the
objects that were made writeable were made that way as a convenience
to help vendors simplify their enterprise MIBs a little.  They did
not (and were not intended to) replace the enterprise MIBs or other
proprietary configuration mechanisms.  Since it is not possible to
do away with the proprietary MIB module for configuration, a full
compliance for those MIB modules would not add much value.  In the
case of the SONET-MIB such a compliance statement would have failed
the "multiple implementation" requirement needed to advance on the
standards track:  although all the writeable objects are implemented
as read-write by some vendor, no two of them implement all of the
writeable objects as read-write.

Maybe I am too focused on legacy cases, but I don't want to start
trying to force-fit things like dual compliance statements where
they don't seem to apply.  Having said all that, I will be happy if
you can find some stronger words to use than what I proposed above,
provided that we make it clear that we are not trying to force
people into doing things when they don't make sense.

Thanks,

Mike