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.
> >
> >
>