Here is the final set of editorial comments on version 0.83.
1. The header line for the following attributes/flag bits is indented
too far. (Does not match the other entries.)
jobSourceChannelIndex(25) (page #46)
jobProcessAfterDateAndTime(51) (page #49)
jobCompletedTime(194) (page #57)
jobProcessingCPUTime(195) (page #57)
exceedAccountLimit (page #67)
2. In the header for physicalDevice(32) (page #47), the reference
"(see HR MIB)" is not per IETF format. The proper format does
appear in the text that follows. I suggest that the first
reference be deleted.
3. In jobHoldUntil(53) (page #49), I do not understand " 'no-hold' ".
4. What is the difference between Toner Economy (tonerEconomyRequested
and tonerEconomyUsed) and Toner Density (tonerDensityRequested and
tonerDensityUsed)? (see page #51) They appear to be identical from
the description. (or very very close!)
5. The reference for DateAndTime (page #56) should be:
"See SNMPv2-TC [SMI-V2]" (The part in brackets is missing.)
Also, as in item #2 above, the text "(SNMPv2-TC)" should be removed
from the attributes that follow (numbers 190 to 195).
6. In jmJobStateReasonsTC (page #61) the third line of the description:
"...to provides additional..." S/B "...to provide additional..."
7. Also in jmJobStateReasonsTC (page #61) the last sentence of the
fourth paragraph:
"For ease of understanding, the JmJobStateReasons1TC
reasons are presented in the order in which the reason is most
likely to occur, not counting the 'other' and 'unknown' reasons."
This paragraph invites a challenge and I suggest that it be removed.
8. In jobProcessAfterSpecified (page #62), the text:
"...specifies a time that is still in the future,
either set when the job was created or subsequently by an
explicit modify job operation."
Do we care how this was defined? Is it possible that another method
could be used? I suggest that the sentence be shortened to:
"...specifies a time that is still in the future."
9. I am confused by the abortedBySystem entry (page #63).
"abortedBySystem 0x2000
The job was aborted by the system.
NOTE - this reason is needed only when the system aborts a
job, but does not put the job in the aborted job state. For
example, if the system aborts the job, but places the job in
the pendingHeld state, so that a user or operator can try
the job again."
If the job is in the pendingHeld state, why would aborted be
reported? Either provide a better explanation for this flag or
remove it.
10. In heldForRetry (page #67), change the text:
"...but the error might not be encountered if the job is
re-tried in the future, such as phone number busy.."
To:
"...but the error might not be encountered in the future.
Example causes are a phone number busy.."
11. In jmGeneralJobPersistence (page #72), the second paragraph:
"Depending on implementation, the value of this object MAY be
either: (1) set by the system administrator by means outside
this specification or (2) fixed by the implementation."
Since this is a read only object do we need to define how it is
configured? We only need to describe the function.
12. For jmGeneralAttributePersistence (page #73) the above comment (11)
also applies.
13. In jmJobIDEntry (page #74), I did not realize that
jmGeneralJobSetIndex was no an index into this group. (If it is an
index, the object jmJobIDSetIndex (page #75) can be removed.) Why
is this not an index?
14. The object name "jmJobIDJobIndex" (page #75) is awful! I suggest
"jmIDJobIndex".
15. In jmJobStateReasons1 (page #77), I find the following statement
hard to disagree with, but why do we need to state this?
"Furthermore, when implemented as with any MIB data, the
agent SHALL return these values when the reason applies and
SHALL NOT return them when the reason no longer applies whether
the value of the job's jmJobState object changed or not."
All this really states is that the value of an object must be valid.
We do not have a similar statement for any other object.
16. Also in jmJobStateReasons1 (page #77), the next sentence:
"When
the job does not have any reasons for being in its current
state, the agent SHALL set the value of the jmJobStateReasons1
object and jobStateReasonsN attributes to 0."
I suggest it be reworded to:
"When the agent cannot provide a reason for the current
state of the job, the value of jmJobStateReasons1 object
and jobStateReasonsN attributes shall be 0."
17. Appendix B should be moved to the Mapping RFC but we should keep
it here until the Mapping RFC plans are firm. (This will be the
primary agenda item next week in Redmond.)
18. The section numbering of the Appendices is somewhat strange, but
I am not sure if this should be changed.
19. In section 7, the reference to ipp-model (page #89) I believe:
"...in progress.." should be "...work in progress.."
The end of my comments (but I reserve the right to make additional
comments in the future.)
Ron Bergman
Dataproducts Corp.