I've posted the few remaining issues for the Job Monitoring MIB, V0.81,
(same as Internet-Draft 00), along with all of the closed issues and
the reasoning for each decision:
ftp://ftp.pwg.org/pub/pwg/jmp/contributions/
-rw-rw-r-- 1 pwg pwg 50176 Apr 29 19:29 issues.doc
-rw-rw-r-- 1 pwg pwg 58405 Apr 29 19:30 issues.pdf
-rw-r--r-- 1 pwg pwg 59706 Apr 29 19:30 issues.pdr
The .pdf file has (black) revision marks to show the changes to the
issues from version 0.7.
The .pdr is the same PDF file with red revision marks, as opposed to the black
revision marks for screen viewing (or printing on a highlight color printer).
***************************************************************************
** Lets start the discussion about the issues on the e-mail list, so we can
** have a running start on the JMP meeting next week. Especially, ISSUES
** 67, 68, and 69, which require SNMP experts familiar with Get Next accessing
** sparse tables with 4 indexes.
***************************************************************************
I've also posted the MIB with *red* revision marks for looking at
the PDF file on your screen (or a highlight printer) to compare with
version 0.7 that was input to the Austin meeting:
ftp://ftp.pwg.org/pub/pwg/jmp/mibs/
-rw-r--r-- 1 pwg pwg 358881 Apr 29 19:32 jmp-mibr.pdr
Here are the open issues from issues.pdf:
1. Open Issues
Issue 61 - Need to clarify the semantics of each object and attribute with
respect to Configuration 1, 2, and 3. See Bob Pentecost EMail of 3/10 (HP
internal review). Most objects refer to the jobs as they exist in the
server or printer that the agent embedded in, i.e., is instrumenting. A few
objects, represent information that comes from upstream places in the case
of configuration 1 from the client, in the case of configuration 2, the
client as well, and in the case of configuration 3, the server and maybe
even the client as well.
ACTION ITEM (Tom): Analyze the existing attributes to see if the semantics
need clarification depending on which configuration and send to the DL.
[NOTE: some of this has been done in version 0.81 - TNH]
ISSUE 67 - Delete the three objects in the Job State table that duplicate
attributes? jmJobStateKOctetsCompleted, jmJobStateImpressionsCompleted, and
jmJobStateAssociatedValue?
An app can get all of these from the AttributeTable directlly:
jobStateKOctetsCompleted, jobStateImpressionsCompleted, and
jobStateAssociatedValue.
ISSUE 68 - Delete the Job State Group/Table all together, since all objects
are also duplicated as attributes?
If ISSUE 67 does delete the 3 objects from the Job State table, then only
the jmJobState object remains. But that is also available in the Attribute
Table as the jobState attribute.
ISSUE 69- Does order of assignment of JmAttributeTypeTC enums make any
difference?
Would it help if the mandatory attributes were first, so that Get Next would
pick them up first?
ISSUE 70 - Add some simple general device alert TC, instead of using the
Printer MIB Alert Codes.
The PrtAlertCodeTC generic values are much good to an end user without
knowing which subunit. For example, SubUnitEmpty isn't very informative by
itself. If an implementation also has the Printer MIB, then a lot more
information is available, so a copy of the Printer Alert isn't very useful.
If the implementation doesn't have the Printer MIB, then the Printer Alert
codes aren't informative enough.
ISSUE 71 - Are there any attributes that need to be clarified as to which
apply to servers and which apply to devices and which apply to either?
ACTION ITEM (Tom): Send to the DL, if find other attributes that are
different between the server and the printer.
ISSUE 72 - What should happen to jmGeneralNewestActiveJobIndex when all the
active jobs complete?
Shall agent set it to 0 or leave it alone as a pointer to increment when the
next job is accepted? If it is reset to 0 (to indicate that there are no
more active jobs), what remembers where to put the next received job? What
is remembered across power cycles, so that jmJobIndex values are not
immediately re-assigned upon power up? If the newest active job is comleted
before an older one, shall the agent search back to find the newest still
active job and decrement jmGeneralNewestJobIndex to point to it? Or should
this object really be left alone after the newest job completes and be
called jmGeneralNewestJobIndex, since the newest job may no longer be active?