We may want to reply to David Perkins that we don't think that any of the
object should be MAX ACCESS of READ-WRITE. This is only a Monitoring MIB.
Should we?
Thanks,
Tom
-----Original Message-----
From: Ron Bergman [mailto:rbergma at dpc.com]
Sent: Monday, September 21, 1998 13:06
To: jmp at pwg.org
Subject: JMP> Re: job mib feedback (fwd)
As you can see there has been some activity directed towards the Job MIB
since the last meeting. I received the following today from Bert Wijnen,
who is helping to move the MIB to RFC status.
I would like to discuss the following comments in the Savannah meeting on
Friday. We need to either revise the document or justify our position.
It is our best interests to revise the documents to conform as long as the
change does not functionally change the MIB.
Any comments or discussion prior to the meeting would be helpful.
Ron Bergman
Dataproducts Corp.
---------- Forwarded message ----------
Date: Mon, 21 Sep 98 20:25:11 DST
From: Bert Wijnen <WIJNEN at VNET.IBM.COM>
To: rbergma at unspecified-domain, lpyoung at lexmark.com, chrisw at iwl.com
Cc: moore at cs.utk.edu, hastings at cp10.es.xerox.com, harryl at us.ibm.com
Subject: JMP> Re: job mib feedback (fwd)
Ref: Your note of Mon, 21 Sep 1998 07:35:32 -0700 (Pacific Da
Subject: Re: JMP> Re: job mib feedback (fwd)
OK, if you are going to do another revision, then pls consider these
comments. Up to you how much you pick up.
>From Perkins:
- misuse of the REFERENCE clause
for objects to indicate implementation requirements, and
- defining objects with read-only maximum access when it
appears that at least read-write access is appropriate.
There might be (and probably are)
more technical problems, but my review time was limited.
>From Keith McCloghrie
1. 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.
2. Defining the meaning of enumerated labels in ASN.1 comments (as
is done in the definition of JmAttributeTypeTC) is not conformant
to the SMI.
3. 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.
I am also very surprised about the VERY superfluous use of
capitalized SHALL, MUST, SHOULD, MAY etc.
Bert