Subject: JMP> Conformance/Indexing of Job ID table

From: Harry Lewis <[email-masked]>
Date: Tue, 1 Jul 1997 12:36:31 -0400

I do not favor such dramatic changes at this late date. I don't see the purpose
of most of these changes i.e. they don't appear to make anything work any
better.

The one change I would support is making jmJobSubmissionID a fixed length
string and eliminating the length byte which gets us around the IMPLIED
SMIv1/v2 problem.

Harry Lewis - IBM Printing Systems

------- Forwarded by Harry Lewis/Boulder/IBM on 07/01/97 10:24 AM --------

        [email-masked]
        06/28/97 04:02 PM
Please respond to [email-masked] @ internet

To: [email-masked] @ internet
cc:
Subject: JMP> Conformance/Indexing of Job ID table

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.

---

From: [email-masked] (Ira Mcdonald x10962)
Date: Tue, 1 Jul 1997 13:14:29 PDT

Hi Harry,

Glad you think going to fixed length is a good idea.  The other changes
aren't especially important, except for the misplaced definitions for
job set index and job index (which were also pointed out by David
Perkins, recently).  I understand from Tom that there is resistance
to using the extra indices in the Job ID table to handle duplicates
(after all that was the submitting client's screw up, anyway).
Without adding them (once the true definitions of the job set index
and job index are moved to their respective primary tables, which
David Perkins feels is necessary to remove illegal usage and I
would certainly say is removing NON-STANDARD usage), you'll
need 'shadow' objects in the Job ID table (not indices, just
data) to return the matching values for a given client job
submission ID.

Cheers,
- Ira McDonald
------------------------ Harry's note ------------------------
>From [email-masked] Tue Jul  1 12:43:11 1997
From: Harry Lewis <[email-masked]>
To: <[email-masked]>
Subject: JMP> Conformance/Indexing of Job ID table
Date: Tue, 1 Jul 1997 09:36:31 PDT
Sender: [email-masked]
Status: R

------- Forwarded by Harry Lewis/Boulder/IBM on 07/01/97 10:24 AM --------

        [email-masked]
        06/28/97 04:02 PM

Cheers,