RE: printermib - compliance statement(s)

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

I am in fact pushing back somewhat... 
- but we have had a lot of iterations with this MIB already
- it is HUGE and takes a serious context switch when you
  have to review again
- Review (since they have so many changes here and thre
  and everywhere) takes a day at least
- they claim that all printer vendors and the (commercial)
  mgmt apps for these MIBs are pretty much in sync on this
  and really want to go this way. it is an org outside
  IETF these days, even though the docs seem to indicate
  that it is the IETF printmib WG (has not been active
  within IETF for many years).

So... I wonder.
If more MIB Doctors agree with Mike... I will push back harder

Thanks,
Bert 

> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: dinsdag 4 februari 2003 21:50
> To: Mreview (E-mail)
> Subject: Re: printermib - compliance statement(s)
> 
> 
> 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
> 
>