RE: printermib - compliance statement(s)

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

Thanks for your reaction. I will push back some more.
Dave, you have been in the review team for these MIBs
too, maybe you can send the below to the authors too.
That way they can see that it is not just me.

Thanks,
Bert 

> -----Original Message-----
> From: Harrington, David [mailto:dbh@enterasys.com]
> Sent: woensdag 5 februari 2003 6:35
> To: Wijnen, Bert (Bert); Mreview (E-mail)
> Subject: RE: printermib - compliance statement(s)
> 
> 
> Hi,
> 
> I think the cost of adding a new compliance is minimal, and 
> there is no benefit derived from not changing the compliance 
> name. So from a cost/benefit standpoint, I don't see a 
> justification for not making the change.
> 
> The idea behind compliance statements is to improve 
> interoperability between agents and managers, not between 
> older implementations and newer implementations. An agent 
> claiming compliance to prtMibCompliance should be compliant 
> to prtMibCompliance. Not changing the name means there are 
> two divergent definitions of what that means. A manager 
> loading a mib module and using the prtMibCompliance 
> definition should have to deal with only one consistent 
> definition to understand the behavior of a prtMibCompliance 
> compliant agent. From the standpoint of interoperability, 
> having two compliance definitions with the same name is bad practice.
> 
> I believe the new compliance rules should be in a newly-named 
> compliance statement and new groups defined as needed, 
> without changing the existing compliance rules. There is no 
> need to deprecate the old compliance or groups; 
> implementations can choose which compliance level they wish 
> to meet (and claim).
> 
> dbh
> 
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> > Sent: Tuesday, February 04, 2003 3:21 PM
> > To: Mreview (E-mail)
> > Subject: printermib - compliance statement(s)
> > 
> > 
> > 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?
> > 
> > 
> > > - You have added changes to prtMIBCompliance
> > >   e.g. a lot more objects are now OK in Read-Only mode
> > > - You have added new OBJECT-GROUPS to prtMIBCompliance.
> > > 
> > > If I understand RFC2580 correctly, then such is never allowed.
> > > Did you guys discuss that in your PRT WG?
> > > 
> > > The proper way to do that is to
> > > - Leave existing OBJECT-GROUPs as is (at least do not remove
> > >   or add objects)
> > > - Leave existing Compliance in tact.
> > > - Create new OBJECTS GROUPS  (you have done so for complete
> > >   new object groups, but if you want to add objects to an
> > >   existing group, you copy the existing group, give it a
> > >   new name and make the addtions to the new group.
> > > - Create a new Compliance statement.
> > > - Optionally depreacte the old compliance statement.
> > > 
> > > RB>> Our new compliance statement is actually less strict than
> > > RB>> RFC1759 since the changes add more objects that may be
> > > RB>> read-only and all the new groups are optional.  All
> > > RB>> conforming RFC1759 implementations will conform.  This
> > > RB>> was carefully reviewed during our last update of the
> > > RB>> conformance section.  Do we really need to add the old
> > > RB>> compliance statement as deprecated?
> > > 
> > To me it feels that that is the correct way to do it.
> > Your "the new one is less strict than 1759" makes me think...
> > if you and all the major implementers of this MIB agree...
> > then maybe it is OK. But at least add something to that effect 
> > to the descitption clause.
> > 
> > If we were strict, then the old compliance statement should
> > have for objects that now have one of the new (extended, e.g.
> > with additional enumerations) TCs, that OBJECT listed with a 
> > SYNTAX of the set of enumerations that just existed in 1759.
> > 
> > Not sure how strict we want to be for a recycle at PS.
> > 
> > Other opinions?
> > 
> > Bert
> > 
> > Thanks,
> > Bert 
> > 
> > 
>