Tom
>-----Original Message-----
>From: Harry Lewis [mailto:harryl@us.ibm.com]
>Sent: Tuesday, October 13, 1998 14:47
>To: rbergma@dpc.com
>Cc: jmp@pwg.org; hastings@cp10.es.xerox.com
>Subject: Re: JMP> RE: Review of Job Monitoring MIB of October 2, 1998
>
>
>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@dpc.com on 10/13/98 03:02:46 PM
>Please respond to rbergma@dpc.com
>To: Harry Lewis/Boulder/IBM@ibmus
>cc: hastings@cp10.es.xerox.com, jmp@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@pwg.org on 10/13/98 09:07:33 AM
>> Please respond to jmp-owner@pwg.org
>> To: hastings@cp10.es.xerox.com
>> cc: jmp@pwg.org, Harry Lewis/Boulder/IBM@ibmus, rbergma@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@dpc.com]
>> > >Sent: Thursday, October 08, 1998 13:46
>> > >To: Tom Hastings; Harry Lewis
>> > >Cc: jmp@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.
>> > >
>> > >
>> >
>>
>>
>>
>>
>>
>
>
>
>
>