Most of these comments are editorial, so I'm in the process of editing them
in. I've finished all of the agreements from Nashua and am working on
editorial stuff from David and Ron Bergman.
There are three substantive issues:
1. Should we split up the jmAttribute table into two tables or not?
2. We have illegal indexing in the jmGeneralTable and jmJobTable according
to SMI rules, so I've edited those fixes in, so that the IETF won't delay
our MIB over such an issue. See jmp-oids.doc for the effect on the OIDs
that I posted in the contributions/ sub-directory.
3. How does the application find out about which coded character set
the text objects and attributes are using?
I'll send out a separate mail message on the first and third issues,
so reply on those issues to that mail message, not to this one,
so we can have a focused discussion. I want to resolve these issues
quickly (this week, if possible), as I'm just about finished with all of
the other editing.
Thanks,
Tom
>Return-Path: <dperkins at scruznet.com>
>Reply-To: <dperkins at scruznet.com>
>From: "David T. Perkins" <dperkins at scruznet.com>
>To: <hastings at cp10.es.xerox.com>, <rbergma at dpc.com>, <chrisw at iwl.com>
>Subject: Review of Job Monitoring MIB
>Date: Fri, 27 Jun 1997 01:18:07 PDT
>X-Msmail-Priority: Normal
>>HI
>>I finished looking over the document. (I spent about 5 hours)
>In general, the objects that are defined in the MIB module are
>relatively few in number and easy to understand. However, the
>document has some problems and the MIB module has some problems
>that can be easily solved without changing the semantics of
>the MIB objects or losing any capabilities.
>>There is one change that would affect any current implementations
>that I strongly suggest that you do. Table jmAttributeTable has
>three accessible columnar objects. The first tells you the "type"
>(either integer, octet, or both) of the value of the attribute.
>The second two columns are the attribute's value. I suggest that
>instead of this single table, that you have two tables. Each table
>would have a single accessible column. The first table would contain
>integer valued attributes, and the second table would contain
>octet string valued attributes.
>>On the document itself, none of the cross references seemed valid!
>In general you have way too much text in the descriptions for the
>textual conventions and objects that should be in the text that
>comes before the MIB module.
>>The MIB and the agent don't "instrument" a managed device. An SNMP
>agent provided access to instrumentation. Thus, many times throughout
>the document were I saw sentences like the following, it would cause
>me to grit my teeth:
> An agent is the network entity that accepts SNMP requests from a
> monitor and implements the Job Monitoring MIB by instrumenting
> a server or a device.
>This is not correct! A correction of the above text is the following
>text:
> An agent is the network entity that accepts SNMP requests from a
> monitor (an SNMP management application) and provides access to the
> instrumentation for managing jobs modeled by the management objects
> defined in the Job Monitoring MIB module.
>>The reason why the original text is not correct is that the instrumentation
>is independent of the mechanism used to access the management information.
>That is, the instrumentation could have a local interface so that a
>program could be run on the server or device that displayed management
>information on a local console.
>>On your configurations of printers-clients-servers, you specify three
>and say that configuration 2 is not the design center for the document.
>I don't understand. I think that configuration 2 would be the most common
>and think that configuration 3 is unworkable. (How would configuration 3
>work if there were a pool of printers?)
>>The approach to specifying conformance is quite inappropriate. SMIv2 has
>a well defined mechanism which is not being used properly. Yes you have
>a module compliance specification, but you also have compliance
>specifications all through the MIB module in ASN.1 comments. You need to
>remove the ASN.1 comments with compliance specifications. In the text
>of the document, you simply specify the compliance specifications by
>referencing the one or more module compliance specifications in the
>MIB module!
>The conformances for management applications is sort of silly. You
>basically say that they cannot have bugs and must correctly implement
>and use SNMP. This is silly and should be removed.
>>The module has a problem with all the objects that have type of OCTET
>STRING.
>You really need to enforce a code-point mapping. Consider a management
>application. What are they to do with the values? Do they try to figure
>out the encoding, or ask the user of the application for a hint, or what?
>>The text of section 8.1 is invalid. No other definition of MIB objects
>can cause the access for MIB objects in the current module to change.
>>The text of section 9 is bogus to the max. The "normal SNMP practice" that
>you describe does not exist. What you really want to say is something like
>the following:
>> 9. Values for Objects
> SNMP requires that if an object cannot be implemented because its values
> cannot be accessed, then a compliant agent must return an SNMP error in
> SNMPv1 or an exception value in SNMPv2. This MIB has been designed so
>that
> all objects can be implemented. In general, values for objects have been
> chosen so that a management application will be able to determine if
> a useful value is available for an object. The approach is to define
> the value 'unknown(2)' for enums, the value '-2' for integers, and the
> zero length string for octet strings to mean that a useful value is
> not available for an object.
>>Section 10 should be called just "Notifications" and not "Notifications
>and Traps". The first sentence should be "this MIB module does not specify
>any notifications."
>>At the beginning of the MIB module, you did a good thing by providing the
>RFC editor with instructions for what to do when the document is published.
>However, the details were not quite correct. You cannot have the definition
>"temp OBJECT IDENTIFIER ::= { experimental 54 }" before the module identity
>construct. You should delete the definition "temp OBJECT IDENTIFIER ::= {
>experimental 54 }, and specify the value for jobmonMIB as
>{ experimental 54 105 }, and fix the editing instructions in the comment
>before the module compliance.
>>Throughout the MIB module the text references pages and items in the
>reference section. This is a really bad thing to do, since these references
>will have not meaning after the MIB module is extracted from the document!
>Get rid of them. In the description for the module identity, create
>short labels for items found in the references section of the document,
>and use those labels in text in the MIB module. For example, to reference
>RFC 1213, you might add the following in the description:
> [MIB-2] - RFC 1213
>And specify "[MIB-2]" in your other descriptions, instead of [5] from your
>references section of the document.
>>Add the WG email and WEB site in the CONTACT-INFO description text. I'm
>sure
>that you do not want to be contacted by every university student that
>was assigned a project to write a management application that uses the
>job monitoring MIB.
>>All the ASN.1 comments for each enumerated value should be in the
>description
>text for the TC. Thus, a TC definition should look something like the
>following:
> MyTC ::= TEXTUAL-CONVENTION
> STATUS current
> DESCRIPTION "bla..bla..bla..
> The values are:
> v1(1)...bla-bla-bla
> v2(2)...bla-bla-bla
> ...
> vn(n)...bla-bla-bla"
> SYNTAX INTEGER {v1(1), v2(2), ...vn(n)}
>>In general, you provide text in the descriptions for the TCs and the values
>of the TCs that should go in the text of the document.
>>Figure 4 for TC JmJobState is messed up (due to formatting problems?).
>>The description for TC jmAttributeTypeTC is quite bogus. It is not longer
>needed, if you follow my suggestion above.
>>The indexing for tables jmGeneralTable and jmJobTable is illegal. (just
>because RMON-2 and a could other MIBs did something like this does not
>make it legal.)
>>Several of your objects need a units clause, such as
>jmGeneralJobPersistence.
>>I believe that the "helpful note" in the description for row jmJobIdEntry
>will cause more confusion than provide help.
>>You have a typo for the RFC number of the printer MIB. It should be
>RFC 1759 and not RFC 1579.
>>That's it for now.
>Regards,
>/david t. perkins
>>>