Subject: JMP> 5th Set of Comments on Version 0.83

From: Ron Bergman <[email-masked]>
Date: Mon, 28 Jul 1997 18:17:15 -0700 (PDT)

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.