At 22:52 04/28/97 PDT, Harry Lewis wrote:
>Classification:
>>Tom, thank you for the fine work on the Job MIB draft. I am sure we will make
>rapid progress from this point.
>>I've done a very quick review and have the following initial comments (working
>from the jmp-mibv.pdf draft):
>> 1. Line 1175 - I do not think we should start the MIB at jobmonMIB5.
> I understand, this is a hold-over from the printer MIB where we
> needed to align with a printer MIF and you just didn't have time
> to correct this. I want to mention it as a comment to this draft
> so it will surely be addressed. I think leaving space for the
> conformance statement is a good idea, so I propose starting the
> job MIB at jobmonMIB2.
See Jeff Case's e-mail where he said:
>no, i have to tell you that this is a bit odd ... usually, one would do
>this
> foomib
> foomib.1 foomibobjects
> foomib.1.1 group 1
> foomib.1.1.1 first object or table in group 1 of foomib
> etc
> foomib.1.2.1 first object or table in group 1 of foomib
> etc
> foomib.2 foomibconformance
> etc
For the Job Monitoring MIB this would be:
jobmonMIB
jobmonMIB.1 jobmonMIBObjects
jobmonMIB.1.1 jmGeneral
jobmonMIB.1.1.1 jmGeneralTable
jobmonMIB.1.1.1.1 jmGeneralEntry
jobmonMIB.1.1.1.1.1 jmGeneralNumberOfActiveJobs
jobmonMIB.1.1.1.1.2 jmGeneralOldestActiveJobIndex
..
jobmonMIB.1.2 jmJobID
..
jobmonMIB.1.3 jmJobState
..
jobmonMIB.1.4 jmAttribute
..
jobmonMIB.2 jobmonMIBConformance
jobmonMIB.2.1 jobmonMIBCompliance
jobmonMIB.2.2 jobmonMIBGroups
Correct?
This would add another level of OID arcs to the ones in the
Internet-Draft (V0.81).
>> 2. Line 1197 - What possessed you to rearrange the order of the
> jmGeneralEntry sequence? Your previous draft had JobSetName,
> JobPersistence, AttributePersistence, NumberActive, Oldest,
> Newest. The reordering just makes busy work for anyone who
> has been trying to keep up with a prototype (unless there is
> a good reason, of course).
Sorry about that.
I put the more important items first and the jmJobSetName
last, which isn't of interest on systems that have only one Job Set
and hard code the Job Set Index as 1. I thought that might help.
But if it doesn't, I can change the order back.
Or is it better to leave it as it is, since changing it back would
be yet another change?
In the future I'll not make such "gratutous" changes. I think this was
the only change that wasn't based on some e-mail message, or by attempting
to clarify something that someone had a question about or confusion that
someone had, or related to one of the open issues.
>> 3. Line 1350 - I don't think the name of an OID should necessarily
> contain the word "index" if the name is otherwise fully self
> describing. For instance, jmJobSubmissionID is sufficient to
> NAME this OID, even though it is used as an index.
I agree that jmJobSubmissionIDIndex could be changed to just jmJobSubmissionID,
since there aren't any other objects, such as jmJobSubmissionName
that it could be confused with. On the other hand, being consistent
in always appending the word Index if it is used as an index is helpful
to implementors. On the other hand, this Index is not your usual index,
since it is up to 32 octets, not the normal 16-bit or 32-bit Integer.
So I agree that jmJobSubmissionIDIndex could drop the Index and even
remain consistent with the convention that the word Index is used as a
suffix, but for integer indexes only.
Ok?
>> 4. Line 1483 - Is there an SNMP rule that every name in a table
> has to start with the same set of words. For example, why
> do we need the word STATE in jmJobStateKOctetsCompleted and
> jmJobStateImpressionsCompleted?
I'm not certain whether it is a rule or just a convention.
[On this particular issue, I hope we can do away with the entire State table,
since each of its objects are also replicated in the Attribute table.
See ISSUE 68 (and 67),]
For example, the corresponding attributes are already shorter:
jobKOctetsCompleted and jobImpressionsCompleted for the objects whose
names you want to shorten.
If we could delete the Job State Table entirely,
the resolution of this issue would become moot.
>> 5. Line 1602 - Again, I think it is very confusing to tag the word
> "index" onto the end of the object names jmAttributeTypeIndex and
> jmAttributeInstanceIndex, just because these objects are used to
> index the table. I think the names should be shortened to
> jmAttributeType and jmAttributeIndex.
Lets let the group decide. My suggestion is to keep the Index, because
these are 32-bit and 16-bit indexes respectively. On the other hand,
I don't feel too strongly about these, since there aren't other objects
with similer names that these might be confused with. Thought knowing
that these objects are indexes is pretty key to understanding the
Attribute Table.
>>Tom, I know it's a lot of work to produce this draft. My comments may
>seem like "nits"... I hope you take this as a good sign... if this
>is the extent of all our comments then it means we have come very
>close to consensus on the Job Monitoring MIB - FINALLY!!
Thanks for the comments. I finally have the .doc file so that changes
are easy to make that the group wants. Seems like we are close enough
to agreement to only make future changes that are agreed to by the group
via e-mail, telecon, or at the meeting.
The one big issue left, as far as I'm concerned is getting rid of the
Job State table altogether (ISSUE 68). All of the objects in the
Job State table are duplicated as attributes in the Attribute table, including
the jmJobStateAssociatedValue object which is duplicated as the
jobStateAssociatedValue attribute. So deleting the Job State table
loses no information. And the jmGeneralOldestActiveJobIndex allows
an application to start right with the first active job in the Attribute
table.
Maintaining one table, instead of two, seems
a lot simpler for an agent, reduces the number of objects, and simplifies
understanding, and increases the chances that different agent implementations
will present the same interface to application software.
A second issue (which I didn't add to the issue list, but should) is if we
do agree to delete the Job State Table, do we really need the
jobStateAssociatedValue which is a copy of the pertinent attribute depending
on the job's state. Or can an application access the
attributes that it wants directly, perhaps independent of state and
then pick which attribute to use based on the state that came back?
A third issue (which I didn't add to the issues list, but should)
is that the current jmJobStateAssociatedValue object (and
jobStateAssociatedValue attribute)
has a fixed idea about the processing and printing states. There are
different kinds of (high end) printers for which separate states for processing
and printing is very natural. On the other hand, most desktop printers
interpret and mark together, perhaps offset by a short paper path of 1-6
impressions), will not show the job in processing for the first 1-6 impressions
and then transition the job to printing for the remaining impressions (which
would replace the copy of the jobKOctetsRequested attribute value with the
copy of the impressionsRequested attribute value. Such desktop printers
will use only one job state.
In other words, while the AssociatedValue object/attribute could reduce
the number of octets transferred somewhat, I'm concerned about the
complexity of the agent, and the fact that the Associated Value concept
is another example of where there are two ways to access the same data
(three ways if we keep the Job State Table).
I'm also concerned that this complexity might increase the chances
of different agent implementations that present a different interface
to application software that might confuse such software that was attempting
to interwork with agents from different vendors.
Getting rid of the jobStateAssociatedValue attribute (and corresponding
object in the Job State Table), would solve this third issue.
>>Harry Lewis - IBM Printing Systems
> objects happen to be used to index the table.
>>Harry Lewis - IBM Printing Systems
>>