Subject: JMP> Job MIB comments

From: Harry Lewis <[email-masked]>
Date: Thu, 19 Jun 1997 19:50:49 -0400

Tom, thanks for getting the v0.82 draft out. Here are my comments on the PDF
version.

1. deviceAlertCode (6) needs pointer to SNMP alert table - See pg. 36.

When the device is a printer, the alert code SHALL be the printer alert code.
This is the current definition. But, this is not very effective when
genericAlertCodes are used. An index into the
alert table would provide more information (rather than just JAM, you'd know
jam in Input 3, for
example). Maybe this is too much info for job monitoring? But it's just as
easy  for the agent.

2. deviceAlertCode (6) is may be multivalued - See pg. 36.

More than one alert may be in effect. Do we need to clarify that this attribute
can be multi row?

3. What happened to serverAssignedJobNumber (2x) - See pg. 37

We used to have serverAssignedJobNumber, with syntax integer. I think we
combined
this with serverAssignedJobName (22) and dropped it, but in so doing, it is not
listed as
Octets (only). What about the original concern that (OS/2 and perhaps other)
some os's
use an integer not a text string. Are we saying the integer must be converted
to text?

4. Persistence of serverAssignedJobName - See pgs. 36, 37

Two other attributes (jobOwner and jobName) mandate "long" persistence. If you
read the
note under serverAssignedJobName, it leads in with the same reasoning, but
stops short of
requiring "long" persistence. Which persistence value is serverAssignedJobName
intended
to follow?

(Aside... this leads to another whole question about persistence of tables vs.
persistence
of specific attributes or objects and whether or not the 3 objects above should
just be added
to the job state table. Separate topic but probably needs further discussion).

5. jobProcessAfterDateAndTime (51) - Octets vs Integer - See pg. 40-41

Shouldn't this be Octets, not Integer?

6. Eliminate "timeSince" Attributes - See pg. 47

This is too much work for the agent and is contrary to SNMP in that sysUpTime
should do
the trick. I don't mind using a JmTimeStampTC rather than sysUpTime so much,
but the
NMS, not the agent, should calculate the times since. I believe time can be
synchronized
by allowing jobSubmissionToDeviceTime to be multivalued - one DateAndTime
passed
in on submission and one jmTimeStampTC stamped by the printer.

7. IMPLIED/IMPLICIT - See pg. 61

The note reads "an IMPLICIT statement is NOT provided in the following INDEX
clause, since it
was not an SMIv2 feature. Therefore, the extra ASN.1 tag SHALL be included in
the varbind
in the SNMP request and the response."

First, we think the terminology is IMPLIED, not IMPLICIT. Also, we think the
IMPLIED statement
SHOULD (SHALL?;-) be included because it saves a byte on each varbind. If you
left this
out because it is not part of v1 (as stated) I think there are other examples
(like DateAndTime)
where you are using v2 constructs.

8. "Requested Attribute" defaults

For requested attributes like copies, toner, quality etc. what if the requested
value is not passed
in? Should the agent use the device default?

9. Misc editorial

We noticed, in the text version, jobHoldUnitl is in the TOC twice.
In the text and PDF versions jobHold is missing.

>>> Harry Lewis <<<

---

From: Tom Hastings <[email-masked]>
Date: Thu, 19 Jun 1997 18:41:58 PDT

Harry,

Thanks for your comments.  I've listed the ones that should be issues
to be covered at the meeting next week.

Thanks,
Tom

>example). Maybe this is too much info for job monitoring? But it's just as

I agree we should add an attribute which is an index into the Printer MIB
alert table.  Leaving the deviceAlertCode(6) provides for a server
(configuration
2) to put something about the printer, ok?

ISSUE 104: Add deviceAlertIndex attribute which is index into alert table?

Proposed new attribute:

deviceAlertIndex(8)     -- Integer32(0..2147483647)
    -- INTEGER:  MULTI-ROW:  The device alert table index for the device that 
    -- the job is using.  When the device is a printer, this index SHALL be the
    -- index into the prtAlertTable defined by the Printer MIB[1].  Whether
    -- this attribute is instantiated for this job when another job is 
    -- using the device depends on implementation.

>More than one alert may be in effect. Do we need to clarify that this attribute

Yes, for both deviceAlertCode(6) and deviceAlertIndex(8).  Done.

>use an integer not a text string. Are we saying the integer must be converted

I think you are referring to the jmJobIdNumber attribute that Ron proposed
along with jmJobIdName.  We deleted both when switching over to your
jmJobSubmissionID table scheme.  Ron is in agreement I believe with not
needing either jmJobIdName or jmJobIdNumber.

So for servers that assign numbers to jobs before submitting them to 
devices (configuration 3), rather than names, 
I would suggest that having the agent converting a number that it received
in the job submission protocol to a text string would mean that
we could use the same attribute and that an application would not need to
deal with two attributes when querying.

However, we should add a sentence clarifying that the text string
may be a name or a number.

ISSUE 105: Ok to clarify that serverAssignedJobName(22) can be all digits?

>requiring "long" persistence. Which persistence value is serverAssignedJobName

ISSUE 106: Should serverAssignedJobName persist longer too?

>to the job state table. Separate topic but probably needs further discussion).

Agreed.  See ISSUE 93 in what I submitted as comments from Xerox developers.

>Shouldn't this be Octets, not Integer?

Yes.  Done.

>NMS, not the agent, should calculate the times since. 

Good issue.  The three timeSinceJobWasSubmitted(192), 
timeSinceStartedProcessing(195), and timeSinceCompleted(197)
were added becaue this is the way IPP does these time attributes.
On the other hand, is easier as you point out for the agent to use the
JmTimeStampTC jobSubmissionToDeviceTime(191), jobStartedProcessingTime(194),
and jobCompletedTime(196) and the NMS can do the work.  Also having fewer
time attributes to choose from does make the NMS's job easier.  I'm in
favor of removing the three timeSinceXXX attributes.  An agent instrumenting
an IPP system will have to do a little more computation.

ISSUE 107: Ok to remove the three IPP timeSinceXxx attributes?

An agent instrumenting an IPP implemenation will either have access to 
the time that the job's state change happened and can convert to JmTimeStampTC
or only has the time-since-xxx value and will have to substract that from
the time of day and substract sysUpTime from the result to return the
jmTimeStampTC value.

>                                                       I believe time can be

Rather than making jobSubmissionToDeviceTime MULTI-ROW, in which an NMS
wouldn't know whether the first value was a submission time to a server
or a submission time to a device, see ISSUE 93a in the Xerox comments
to keep two attributes, but call one jobSubmissionTime and the other
jobSubmissionToServerTime for use in configuration 3 only when both times
are needed.

>First, we think the terminology is IMPLIED, not IMPLICIT. 

Agreed.  SNMP uses IMPLIED, ASN.1 uses IMPLICIT. So I'll change the note
if it stays.  Done.

Also, we think the
>where you are using v2 constructs.

ISSUE 108:  Add IMPLIED to jmJobIDEntry INDEX statement on page 61?

>in? Should the agent use the device default?

Interesting question? In any case that would be implementation dependent.
This is a difference between ISO DPA and IPP.  In DPA, the server does
populate the job object with the defaults.  In IPP, the server doesn't,
so that the defaults are only applied if neiter the requester nor the
document PDL supplies the attribute.

ISSUE 109: Ok for agent to supply defaults for the job attributes depending
on implmentation?

>In the text and PDF versions jobHold is missing.

Oops!  Looks like I didn't update the TOC after adding jobHold attribute.
It will be in the TOC next version.