Subject: JMP> Comments on JMP V0.82 from Xerox developers

From: Tom Hastings <[email-masked]>
Date: Thu, 19 Jun 1997 14:57:02 PDT

The following comments are from an internal review at Xerox of the Job
Monitoring MIB, V0.82.  I started numbering these issues starting with the
next free issue in issues.doc.

ISSUE 88 - Add jmGeneralNumberOfJobsProcessed object since server or printer
was booted?

Most MIBs have some sort of utlization counter.  The Job Monitoring MIB
should have one also.  Add the object to the jmGeneralTable.  We assume that
this object SHALL NOT be persistent across power cycles.

The DESCRIPTION is proposed to be:

jmGeneralNumberOfJobsProcessed  OBJECT-TYPE
SYNTAX      Integer32 (0..2147483647)
MAX-ACCESS  read-only
STATUS      current
DESCRIPTION
"The number of jobs that have completed processing for this job set since
the server or device was powered on."
::= { jmGeneralEntry 7 }

ISSUE 89 - Add jmGeneralAttributesImplemented object with bits for each
attribute implemented?

Instead of an application not knowing which attributes an implementation
implements and trying to discover by getting errors, or by always using Get
Next, instead of Get, how about adding a jmGeneralAttributesImplemented
object to the jmGeneralTable that has a bit for each attribute implemented.

jmGeneralAttributesImplemented  OBJECT-TYPE
SYNTAX      OCTET STRING(SIZE(0..32))
MAX-ACCESS  read-only
STATUS      current
DESCRIPTION
"A bit string indicating which JmAttributeTypeTC enum values are
implemented.  The value is a constant independent of which bits are currenly
in entries in the jmAttributeTable.  The most significant bit of the first
octet is assigned the value 0 to correspond to enum 0 (not used), the next
most significant bit of the first octet is assigned the value 1 to
correspond to enum 1 (other), the next bit is assigned the value 2
(unknown), 3 (jobStateReasons2) etc. up to 32*8 - 1 = 255"
::= { jmGeneralEntry 8 }

ISSUE 90 - The (MANDATORY) OCTET STRING objects should have a minimum MAX
size required

Otherwise, trivial implementations can implement too short sizes and be
conforming.  The SNMP conformance syntax as the end of the MIB has provision
for specifying the minimum maximum that SHALL be implemented.  The 63 in
OCTET STRING(SIZE(0..63)) is the maximum size and the 0 is the minimum size
for an instance  returned on a Get operation.  The (MANDATORY) OCTET STRING
objects are with suggested MAX size required:

jmGeneralJobSetName	8 octets required to be implemented
jmJobSubmissionID	32 octets required to be implemented

ISSUE 91 - The MANDATORY jobOwner attribute should have a minimum MAX size
required
Otherwise, trivial implementations can implement too short sizes and be
conforming. 
 
We suggest that 16 octets of the maximum 63 be required to be implemented.
Such a maximum will also help with the next issue.

ISSUE 92 - The MANDATORY jobOwner attribute needs to persist as long as
there is job data

92a:  The MANDATORY jobOwner attribute needs to persist as long as there is
job data.  Otherwise, a client that does not have access to the
jobSubmissionID or a system that does not have a jobSubmissionID cannot
identify the jobs in the jmJobTable, after the agent removes the job's
attributes from the jmAttributeTable.  

92b:  If it is agreed that the MANDATORY jobOwner SHALL persist for the
longer period of time, then it should be moved to the jmJobTable, where all
the other MANDATORY attributes have been made objects.  

92c:  Then the jmAttributeTable could be made OPTIONAL, so that really low
end printers would not need to implement the jmAttributeTable at all.
Experience at Xerox with low end non-queuing printers suggests that not
requiring the jmAttributeTable is a win.  With a required maximum of only 20
octets (see previous issue), it is reasonable to move the jobOwner to the
MANDATORY jmJobTable.

ISSUE 93 - The jobName and jobSubmission[ToDevice]Time should be MANDATORY
93a:  The windows queue monitoring show three attributes: jobOwner, jobName,
and start time.  In IPP, jobName is a MANDATORY attribute.  In order to work
for all configurations, the jobSubmissionToDeviceTime should be changed to
jobSubmissionTime and be used for all three configurations: configuration 1:
device, configuration 2: server, and configuration 3: device.  The
jobSubmissionToServerTime shall only be used in configuration 3, where
jobSubmissionTime is also used (for the device).  Then jobSubmissionTime can
be made MANDATORY (since it can be used in all three configurations).  

93b:  If the jobName attribute is made MANDATORY then it should have a
minimum maximum value specified for conformance.  We suggest that 12 octets
is sufficient.

93c:  If jobName and jobSubmissionTime are made MANDATORY, then they should
be moved to the jmJobTable as well, so that the jmAttributeTable can remain
OPTIONAL (see previous issue).

ISSUE 94 - Are the 8 octet fields in the jobSubmisionID printable or binary?
The text says "8-decimal-digits".  Could it be allowed to be a binary
sequence number or random number?   Then the chances of collision are even
lower.

ISSUE 95 - When reducing the size of the jobSubmissionID field from 2 to 1,
the other fields weren't increased by 1.

ISSUE 96 - Add a jobSubmissionID format for jobOwner

The first octet would be an ASCII '4'.  The next 8 would be a sequential
number, and the remaining 23 octets would be the low order 23 octets of the
jobOwner.

ISSUE 97 - Add some jobSubmissionID formats for numeric identifiers

97a - Add one for POSIX user numbers
97b - Add one for user account numbers
97c - Add one for DTMF incoming FAX routing number

ISSUE 98 - The sequence number and random number in the jmJobSubmissionID
should be the least significant field, not the most significant field

Then a requester can leave off the sequential number or random number in a
GetNext and find all of the jobs from a particular MAC address or client URL
(or for a particular jobOwner).  In order to make this switch, we need to
specify that when the MAC address, client URL, (jobOwner, or numberic id) is
shorter than 23 octets, that the field is shortened, rather than being
padded out to 23 octets.  The least significant field is always 8 octets
with leading zeroes, so that we don't need any delimiters between the two
fields.

So the spec would become:
  Format
  Number   Description
  ------   ------------
  1        octets 2 to n: upto last 23 bytes of the jobName 
           attribute; n < 26
           octets n to n+7:  8-decimal-digit random number

  2        octets 2 to n: Client MAC address; n < 26
           octets n to n+7:  8-decimal-digit sequential 
           number
           
  3        octets 2 to n: last 23 bytes of the client URL;
           n < 26
           octets n to n+7:  8-decimal-digit sequential 
           number

  ..       to be registered according to procedures of a 
           type 2 enum.  See section 7.3 on page 22.

ISSUE 99 - The jobSubmisionID format '0' makes no sense

98a:  There are two interpretations of the text there:

1. The agent only puts a single digit of '0' for the entire jobSubmissionID
index - but each subsequent submission would replace the entry.

2. The agent tacks on whatever it wants after the '0' to make a unique
jobSubmissionID index for each job.

98b:  If interpretation 2 is correct, then could we require the agent to use
the jobOwner instead, rather than leaving it unspecified how the agent fills
in the entry if interpretation is correct?

ISSUE 100 - The jobSubmissionIDTable should have jmJobSet and jmJobIndex as
indexes

The current formats will have collisions of jobSubmissionIDs occasionally.
The statement on lines 1695-1697:  "None-the-less, collisions could occur,
but without bas consequences, since this MIB is intended to be used only for
monitoring jobs, not for controlling and managing them." is incorrect, since
future IETF and priviate MIBs are likely to have 'missles', not 'cameras'.
We've had experience with a table like this (jobClientIdTable) for a year
and a half and we added the jmJobIndex equivalent to the row entry that the
agent adds to make sure that no entry ever gets overwritten.
So we propose that the jmJobSet object and the jmJobIndex objects be added
as the least significant indexes to the jmJobSubmissionIDTable.  They are
only simple integers and jmJobSet is likely to be 1 in most implementations.

ISSUE 101 - add jobSubmissionID as an attribute, so can find the ID when
scanning a job or attribute table.

An accounting program that wants to find the jobSubmissionID would have to
scan the entire jmJobSubmissionIDTable

ISSUE 102 - Make a TC out of the jobSubmissionID formats, so can publish new
ones more easily?

ISSUE 103 - Specify a minimum required persistence time for
jmGeneralAttributePersistence

Put the lower bound right in the ASN.1.  We suggest 60 seconds as a minimum
with a recommendation of 300 (5 minutes).  Even add a DEFVAL of 300 as the
default.  The real low cost device that doesn't want to keep job information
around will have a small number of jobs anyway, since how many jobs can just
a device process in a minute anyway?  

The spec would become:

SYNTAX      Integer32(60..2147483647)
MAX-ACCESS  read-only
STATUS      current
DESCRIPTION
"The minimum time in seconds for this instance of the Job Set that an entry
will remain in the jmAttributeTable after processing has completed , i.e.,
the time in seconds starting when the job enters the completed, canceled, or
aborted state.  The value of this object MAY be either (1) set by the system
administrator by means outside this specification or MAY be (2) fixed by the
implementation, depending on implementation.  

This value SHALL be equal to or less than the value of
jmGeneralJobPersistence.  This value SHOULD be at least 300 which gives a
monitoring application five minutes in which to poll for job data."
DEFVAL      { 300 }          -- 5 minutes
::= { jmGeneralEntry 5 }

---

From: JK Martin <[email-masked]>
Date: Fri, 20 Jun 1997 12:54:52 -0400 (EDT)

Tom,

So, one day before the PWG meetings you present a list of 16 new
issues (disregarding, for a second, the many "sub-issues" you've
presented).

This is the same old stuff that has kept the Job MIB from making
significant progress these last two years.  This is Not Good.

No matter what, the Job Monitoring MIB is going to CLOSE its
effort on Friday, June 27, right???

	...jay

----- Begin Included Message -----

>From [email-masked] Thu Jun 19 18:22 EDT 1997
Date: Thu, 19 Jun 1997 14:57:02 PDT
To: [email-masked]
From: Tom Hastings <[email-masked]>
Subject: JMP> Comments on JMP V0.82 from Xerox developers

 

           

The spec would become:

----- End Included Message -----

---

From: Tom Hastings <[email-masked]>
Date: Fri, 20 Jun 1997 11:15:38 PDT

>effort on Friday, June 27, right???

Absolutely right!  Harry refers to some of the same issues.

Tom

---

From: [email-masked] (Ira Mcdonald x10962)
Date: Fri, 20 Jun 1997 15:12:58 PDT

Hi Jay,

Would you prefer half a viable standard now to an actually
usable one a little later.  You certainly managed to offend
the Xerox SNMP implementors who took the time to review the
latest draft in detail and post their comments (thanks to
Tom's editorial cleanups) BEFORE the PWG meeting.

The IETF strongly urges all sanctioned working groups to
make ALL substantial decisions solely via mailing list.
Face to face meetings may suit some of the PWG members,
but they certainly penalize the distant folks (in other
countries) and those who speak English as a second 
language.

How about constructive comment on the input from Xerox
implementors?

Disgruntled,
- Ira McDonald (outside consultant at Xerox)
  High North Inc

---

From: JK Martin <[email-masked]>
Date: Fri, 20 Jun 1997 19:12:02 -0400 (EDT)

Ira,

First off, it would have been nice to toss each of the 16 issues
on the mailing list as they were identified, rather than waiting
until the very last minute and throwing the whole lot onto the list
as people are getting ready to fly to the PWG meetings next week.

I don't think that's too much to ask, do you?  Moreover, I *expressly*
made such a comment to Tom during the JMP meeting in San Diego last
month, strongly encouraging him to not repeat this same scenario as
has been done so often in the past.

And, by posting issues as they arise to the mailing list, you not
only allow for interleaving of human effort, but you also satisfy
the IETF working group rules you have referenced.

Second, I would have preferred a MINIMALLY USEFUL IMPLEMENTATION
out in the marketplace over a year ago.  This certainly would have
been possible if some folks didn't constantly insist on tossing in
the kitchen sink into the effort.  (Believe me, I'm not the only
one who has made this statement over the last two years.)

Of course I didn't mean to offend the Xerox implementors.  However,
I think it's high time Xerox takes a few moments and considers the
rest of the JMP group's desire to FINALIZE the FIRST IMPLEMENTATION
of this Job Monitoring MIB.

There's a difference between "Good" and "Good Enough".

There is always Version 2 (and 3 and 4...).  If NASA took the same
approach to designing rockets as was done in designing the Job MIB,
then we never would have made it to the moon back in 1969...since NASA
would still be trying to figure out how to design that same rocket
to get to Pluto.

Steve Waldbusser kept telling us (in so many words, and on so many
occasions back in 1993-1994):

  Start off small and minimal, with (ideally) NO optional objects
  whatsover, to get some real market experience with a wide base
  of interoperable products.  Then, go back and do Version 2, taking
  into account what you learned in Version 1.

This is all I (AND OTHERS) have been asking all this time, to start
off small and get product in the field ASAP.

You make a reference to a "half viable standard".  When the dust settles
on the latest round of mapping Job MIB objects to TODAY'S EXISTING
PRINTING SYSTEMS, I'll bet you will find that such systems can barely
handle the majority of defined objects.

The bigger the design, the more work to develop.  The bigger the
product, the more likely you will lose on robustness and interoperability.

Please extend my apologies to the Xerox implementors.  I'll need to
partition quite a bit of time to review the 16 issues now presented
on the list.  Chances are, now that the PWG meetings are upon us (and
we're hosting them), I won't get such time until the JMP meeting next
Friday...if I'm lucky.

	...jay

----- Begin Included Message -----

>From [email-masked] Fri Jun 20 18:10 EDT 1997
Date: Fri, 20 Jun 1997 15:12:58 PDT
From: [email-masked] (Ira Mcdonald x10962)
To: [email-masked], [email-masked]
Subject: Re: JMP> Comments on JMP V0.82 from Xerox developers
Cc: [email-masked]

Hi Jay,

Disgruntled,

----- End Included Message -----

---

From: Tom Hastings <[email-masked]>
Date: Fri, 20 Jun 1997 17:24:07 PDT

>the IETF working group rules you have referenced.

Jay,

I'm sorry that I didn't understand what you were suggesting in 
San Diego.  Now that you are being *specific* that you prefer to see
each issue sent as a separate mail message and sent when discovered,
instead of one week ahead of the meeting (the PWG agreed deadline),
I understand what you are saying.

Bob also mentioned to me yesterday that he preferred short mail messages
on a specific topic rather than a long list.  That he tends to read
a mail message that is a screenful and postpones reading longer ones.

If others feel the same, lets change the way we work.  The mail traffic
will go up...

Tom