Re: printermib - compliance statement(s)

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

On Tue, 4 Feb 2003, Wijnen, Bert (Bert) wrote:

> Following is a discussion on the differences between
>   <draft-ietf-printmib-mib-info-13.txt>
>   RFC1759
> The question is if they can just use the "updated"
> prtMibCompliance or if they need to deprecate the
> existing one and add anotehr one.
> 
> I am kind of inclinded to let it go... 
> Opinons?

I know we get exhausted beating on people to fix
things (and they get equally tired of us doing so),
but please don't let this one go by unless they have
a VERY good reason (which I find hard to imagine).

> > - You have added changes to prtMIBCompliance
> >   e.g. a lot more objects are now OK in Read-Only mode

Adding OBJECT clauses should not be allowed unless it is
done in such a way as to leave the meaning of the original
compliance unchanged.  Sometimes you have to that to
avoid silent changed of meaning (remember the discussion
about this point when enums were added to RMON-MIB to
support HC extensions?), but it should be avoided in all
other cases.  In particular, adding OBJECT clauses that
change MIN-ACCESS to read-only can break management
applications that that assume that an agent will implement
the objects as read-write.

If the WG could plausibly argue that (a) they are fixing a
bug (i.e. they really mean to have MIN-ACCESS of read-only)
and (b) that most of the deployed manager implementations
won't be broken then maybe you could grant them a waiver
for this.  At least an agent that conformed to the previous
version of the compliance statement would still comply with
the new one.  But I still would prefer that they not do it.

> > - You have added new OBJECT-GROUPS to prtMIBCompliance.

I would never allow this.  It silently changes the meaning
of any compliance statement or capabilities statement that
references the group.  Those can (and in the case of
capabilities statements, will) reside in other modules
that are not subject to IETF change control.

What is so hard about deprecating all the old groups
and the old compliance statements, cloning a copy of
those constructs with new names, and putting the
changes into the clone?  And what added cost does
it impose on deployed implementations to do that?

I say make them follow the rules on this.  The rules
make sense (i.e., are _not_ Crappy) and it doesn't
cost much to comply with them.

Mike