I have some comments and questions. Perhaps some of these should be
sent to the IESG commenters before the JMP meeting to get their feedback?
Tom
-----Original Message-----
From: Ron Bergman [mailto:rbergma at dpc.com]
Sent: Monday, September 28, 1998 13:19
To: jmp at pwg.org
Cc: Tom Hastings
Subject: JMP> Job MIB Issues for Savannah PWG Meeting
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.
TH> Ok.
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.
TH> The only reason that the definitions were ASN.1 comments, was because
TH> an unnamed, but very popular and good, MIB compiler would not accept
TH> a DESCRIPTION clause with that number of lines, so we had to make them
TH> ASN.1 comments.
TH> The question that I have is, if we move all attribute definitions
TH> out of the MIB portion altogether, will we make the MIB module
TH> almost useless when "the MIB, i.e., section 4, is required to be
TH> extracted and used stand-alone" as described in point 1 above?.
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.
TH> We should change any that are not required for interoperability.
TH> However, I think that most of them are required for interoperability.
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.
TH> I agree.
Ron Bergman
Dataproducts Corp.