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 T=
C
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 b=
e
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 t=
o 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 cha=
nged.
> This is clearly not true. So what other than the editorial changes a=
nd
> 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 b=
it-ness
> > as hex in the description, then as the decimal equivalent.
> >
> > >
> > >I see that you also changed this to v1.2 ( was v1 ). The editoria=
l
> > >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 s=
ame
> > version number for two different versions of the MIB. The minor ve=
rsion
> > 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 pa=
rt 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 inc=
rementing
> > the MIB module version number anyway.
> >
> > >
> > >
> > > Ron Bergman
> > > Dataproducts Corp.
> > >
> > >
> >
>
>
>
>
>
=