I agree with Ron. My main concern is that we not disturb the actual operation
of the MIB... this appears to be strictly a documentation issue. Since the IETF
mentioned one such example, if we have found 4 similar I think it best to
respond.
Harry Lewis - IBM Printing Systems
rbergma at dpc.com on 10/13/98 03:02:46 PM
Please respond to rbergma at dpc.com
To: Harry Lewis/Boulder/IBM at ibmus
cc: hastings at cp10.es.xerox.com, jmp at pwg.org
Subject: Re: JMP> RE: Review of Job Monitoring MIB of October 2, 1998
Harry,
What I see in the MIB is four other TCs that, like JmAttributeTypeTC,
contain very long, detailed specifications of each enumeration in the TC
definition. The specification details should be removed from the MIB
section. I don't want this to come back from the ADs as aonther fix.
If it easy to fix, and I don't see why not, I prefer to do it now and be
done with it.
Does this make the MIB harder to use? Maybe, maybe not. With all the
cross references we have, I don'e see how it could be that much more
difficult.
Any opinions?
Ron Bergman
Dataproducts Corp.
On Tue, 13 Oct 1998, Harry Lewis wrote:
> You were just recommending moving TC's to a consolidated place in the
> document... right? I didn't see any problem with doing that.
>> Harry Lewis - IBM Printing Systems
>>>>jmp-owner at pwg.org on 10/13/98 09:07:33 AM
> Please respond to jmp-owner at pwg.org> To: hastings at cp10.es.xerox.com> cc: jmp at pwg.org, Harry Lewis/Boulder/IBM at ibmus, rbergma at dpc.com> Subject: JMP> RE: Review of Job Monitoring MIB of October 2, 1998
>>> Tom,
>> Since there have been no comments from others regarding the changes to the
> TCs, I assume no one else cares. I have this feeling that this will be
> another issue with the IETF, so I believe it is best if we beat them to
> the draw. So, unless others support my position, keep it as is.
>> Concerning the version number change, your reply indicates that new
> attributes and enums cannot be added unless the version number is changed.
> This is clearly not true. So what other than the editorial changes and
> the addition of the two attributes makes this version 1.2?
>>> Ron
>>> On Mon, 12 Oct 1998, Hastings, Tom N wrote:
>> >
> >
> > >-----Original Message-----
> > >From: Ron Bergman [mailto:rbergma at dpc.com]
> > >Sent: Thursday, October 08, 1998 13:46
> > >To: Tom Hastings; Harry Lewis
> > >Cc: jmp at pwg.org> > >Subject: Review of Job Monitoring MIB of October 2, 1998
> > >
> > >
> > >Tom,
> > >
> > >Your proposed changes look very good!
> > >
> > >I did notice that there are four other TCs that reflect the
> > >same situation
> > >as with JmAttributeTypeTC. They are:
> > >
> > > JmFinishingTypeTC
> > > JmMediumTypeTC
> > > JmJobSubmissionTypeTC
> > > JmJobStateTC
> > >
> > >In the case of the first two, the definitions could be added
> > >as comments
> > >with the enums. For the second two, the specs should also be
> > >moved out of
> > >the MIB and into the text
> > >
> > >I will submit a proposal for these changes unless the other JMP
> > >participants feel strongly that a change here is not required.
> >
> > I don't think we should bother. It wasn't commented on by the IESG. Moving
> > the explanations out of the TC makes them a lot harder to use. The
> > information is spread to two places. For attributes, because there are so
> > many, it makes sense to move them out.
> >
> > I think that they really objected to having -- in the middle of a
> > DESCRIPTION clause (which I removed in doing 1.2.
> >
> > >Also the bit-mapped TCs are structured very different than
> > >what is in the
> > >current Printer MIB and the HR MIB. I suggest everyone look
> > >at this and
> > >indicate if we should revise.
> > >
> > > JmJobServiceTypesTC
> > > JmJobStateReasonsTC
> > > JmJobStateReasons2TC
> > > JmJobStateReasons3TC
> > > JmJobStateReasons4TC
> >
> > Since the IESG folks didn't comment on them, I think they are fine having
> > the bit assignments and the description of each bit as part of the
> > DESCRIPTION clause. Also I think it is a lot clearer to show the bit-ness
> > as hex in the description, then as the decimal equivalent.
> >
> > >
> > >I see that you also changed this to v1.2 ( was v1 ). The editorial
> > >changes should not affect the revision status, nor should the
> > >addition of
> > >the 2 new enums. So I prefer that the MIB remain at v1.
> >
> > Yikes! There would be a terrible confusion problem if we use the same
> > version number for two different versions of the MIB. The minor version
> > number changes shows that some attributes have been added and/ or
> > clarifications.
> >
> > If we don't have a different version number, how can you tell which MIB you
> > have? (Of course, if the TCs were a separate file, then the MIB part could
> > have kept the same version number. But suppose there had been some
> > clarification text added to even the MIB part, then you wind up incrementing
> > the MIB module version number anyway.
> >
> > >
> > >
> > > Ron Bergman
> > > Dataproducts Corp.
> > >
> > >
> >
>>>>>