The following are issues relating to the Job MIB that should be discussed
this Friday in Savannah. My recommended action is included with each
item.
A. Many REFERENCE clauses in this MIB refer other sections of the
document. This is not allowed by the SMI, because the MIB, i.e.,
section 4, is required to be extracted and used stand-alone.
From RFC 1902: "The REFERENCE clause, which need not be present
contains a textual cross-reference to an object assignment defined
in some other information module. This is useful when de-osifying
a MIB module produced by some other organization."
ACTION: Delete all REFERENCE clauses and move reference information
into DESCRIPTION when appropriate.
B. Defining the meaning of enumerated labels in ASN.1 comments (as
is done in the definition of JmAttributeTypeTC) is not conformant
to the SMI.
ACTION: Move all attribute enumeration definitions to a new section
outside of the MIB portion.
C. I am also very surprised about the VERY superfluous use of
capitalized SHALL, MUST, SHOULD, MAY etc.
From RFC 2119: "These words are often capitalized."
"Imperatives of the type defined in this memo must be used with care
and sparingly. In particular, they MUST only be used where it is
actually required for interoperation or to limit behavior which has
potential for causing harm (e.g., limiting retransmissions)"
ACTION: Review the use of these words and remove or change to lower
case any that are not absolutely necessary.
D. The following is inappropriate in an IESG standards document:
-- jobProcessAfterDateAndTime(51), DateAndTime (SNMPv2-TC)
-- OCTETS: The calendar date and time of day after which the
-- job SHALL become a candidate to be scheduled for
-- processing. If the value of this attribute is in the
-- future, the server SHALL set the value of the job's
-- jmJobState object to pendingHeld and add the
-- jobProcessAfterSpecified bit value to the job's
-- jmJobStateReasons1 object. When the specified date and
-- time arrives, the server SHALL remove the
-- jobProcessAfterSpecified bit value from the job's
-- jmJobStateReasons1 object and, if no other reasons remain,
-- SHALL change the job's jmJobState object to pending.
the IETF does not standardize the format in which an application
program displays its output. DISPLAY-HINT, which is only a "hint",
is the closest we get to that.
ACTION: Respond to Keith McCloghrie explaining that this is not a
standardized display format.
Ron Bergman
Dataproducts Corp.