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