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

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

new text WFM (works for me)

Thanks,
Bert 

> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: donderdag 13 februari 2003 1:13
> To: Mreview (E-mail)
> Subject: Re: guidelines 4.8 (read-only + full compliances)
> 
> 
> [ 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
> 
>