Hi Tom and Harry, Saturday (28 June 1997)
First, some IETF Job Mon MIB structure/conformance recommendations:
1) Rename the 'jmJobSetIndex' object to 'jmGeneralJobSetIndex'
- move the definition from the Job ID group (a subordinate group)
to the Job General group (as the first member of the SEQUENCE)
- change MAX-ACCESS from 'read-only' to 'not-accessible' (per SMIv2)
- and import it (by reference) into the INDEX of the Job ID table.
The current location of the 'jmJobSetIndex' object is non-standard,
because it is NOT defined in the group where it is a primary index.
2) Move the 'jmJobIndex' object definition from the Job ID group to the
Job (State) group (as the first member of the SEQUENCE)
- change MAX-ACCESS from 'read-only' to 'not-accessible' (per SMIv2)
- and import it (by reference) into the INDEX of the Job ID table.
The current location of the 'jmJobIndex' object is non-standard,
because it is NOT defined in the group where it is a primary index.
3) Do NOT move 'jobOwner' to the Job (State) table, since the Job ID
table will overlap (in some implementations) with this attribute.
4) Change the conformance for the Job ID group from 'Mandatory'
to 'Optional' - since the Job ID group would no longer contain the
two major index objects (and itself consists of long strings).
5) Change the conformance for the Job Attribute group from 'Mandatory'
to 'Optional' - since the 'jobOwner' attribute is NOT necessary to
find client jobs, if the 'jobOwner' format is used (by the client OR
by the managed system) to assign 'jmJobSubmissionID' values (and
find entries in the Job ID table).
Second, some Job ID table indexing recommendations:
1) Remove length byte, by SMIv1 (RFC 1212, pg 9) and SMIv2 (RFC 1902,
pg 21) encoding rules, from instance qualifiers of the Job ID table
(without resorting to IMPLIED keyword) by using fixed length strings
- change SYNTAX of 'jmJobSubmissionID' to 'OCTET STRING (SIZE(32))'
- change MAX-ACCESS from 'not-accessible' (current) to 'read-only'
- define padding rules for (current) variable length job ID elements
- avoids impossible translation to SMIv1 for SMIv2 IMPLIED keyword.
Note: Fixed length Job ID elements may be blank padded on the right
(eg, NO need to stuff spaces between the MAC address and sequence
number), as the high-order key then becomes the format specifier.
2) Based on Xerox's experience with a similar Job ID mapping table
- add 'jmJobSetIndex' and 'jmJobIndex' to INDEX of the Job ID table
- ensures that ALL jobs appear in table, even w/ duplicate job IDs.
Note: Using the IMPLIED keyword on 'jmJobSubmissionID' (no longer
the low-order index element) is NOT legal in SMIv2 (RFC 1902, pg 22)
- causes a fatal compile error with SMICng (by David Perkins).
Tom, I believe it is CRITICAL not to use SMIv2 extensions which FORCE a
different 'over-the-wire' encoding between SNMPv1 and SNMPv2 for a given
object instance. Doing so would permanently preclude any SNMPv1/SNMPv2
gateway or proxy for the IETF Job Mon MIB (because nobody will translate
semantics for unique objects in such a gateway, so this IMPORTANT table
will be lost from the remote management station's MIB view).
Harry, if a remote client wants to walk the table (with ONE visible
column, the high-order index element 'jmJobSubmissionID'), GetNext will
work just fine.
Unless we change the SYNTAX of 'jmJobSubmissionID' to be 'OCTET STRING
(SIZE(32))', to remove the length byte from instance qualifiers by both
SMIv1 and SMIv2 encoding rules, and define padding rules for variable
length first elements, you CANNOT look for all the jobs with a given job
submission ID format, because the high-order key of the 'jmJobIDTable'
is ACTUALLY the length of each particular job submission ID value, and
NOT the format specifier.
Cheers,
- Ira McDonald (outside consultant at Xerox)
High North Inc
PO Box 221
Grand Marais, MI 49839
906-494-2434
PS - I made all of the above changes to a copy of the IETF Job Mon MIB
V0.82 - it compiled without errors using both the SMICng (1997 version)
and Epilogue (1994 and 1996 versions) MIB compilers.