JMP> Re: job mib feedback

[Tom Hastings <[e-mail]>]

At 11:55 07/27/98 PDT, Keith Moore wrote:
>Tom & Chris,
>
>The job mib was on the agenda for the IESG's Jul 16 telechat.
>It was held up because of problems with the specification.
>To wit:
>
>> It is on this weeks telechat agenda as a WG subission to go
>> out as INFORMATIONAL RFC. Number 3 below is real serious.
>> 
>> 1.I get 15 warnings about unused TCs.
>>   That is acceptable... but are they used elsewere?

No, they are only used in this MIB.  But they only appear as comments
in the JmAttributeTypeTC.  We have the case of a TC "using" the 15 TCs.

We could add dummy used of these TCs, to make the warnings go away, but
the "That is acceptable" sound like we don't really have to do that.

>>   In other words do you need to keep them?

Yes, because an implementation does use the values.  These TCs are the
values of attributes that are of type enum.  Attributes can also have
integer values that count and/or octet strings that are keywords or
text strings.  The Job MIB is trying to have job attributes like
IPP has Job attributes.

>>   There are strange TCs among them, for example the
>>   JmBooleanTC, which to me does not look like a Boolean
>>   since it can have 3 values!!??
>>   And we have a standard TC for a boolean: TruthValue in RFC1903

The JmBooleanTC does have three values.  The third value is 'unknown'.
That is used for the case when the agent doean't know whether the value
is 'true' or 'false'.

>> 
>> 2.The use of MUST, MAY, SHOULD, SHALL, MUST NOT and such
>>   seems completely nonsense the me. It looks as if they
>>   capitalized evry occurence of such words.

There are 5 or so MUSTs and a large number of SHALLs.  Should we change
the 5 MUSTs to SHALL to be consistent?

There are a few sentences that have SHALL which are descriptive sentences,
rather than describing an action by the agent or the NMS (management
application).  Those descriptive sentences should have the SHALL removed.  
However, shouldn't any sentence that has the agent or the NMS (management 
application) as the subject of the sentence have a SHALL, if that action
is required for a conforming agent or management application?

>> 
>> 3.The structure of the MIB is totaly "non-SNMP" like.

I suspect that you are referring to the attribute mechanism which
like a 'dictionary'.

We have found that for Printers and Jobs, that the features that
various implementors implement vary so much that we couldn't have
groups of objects.  Many objects in a group would return 'empty strings',
since there was no value to go with them.  

Most implementations need to be able to pick and choose between the various 
attributes.  Some implement two-sided printing, some implement stapling, 
some implement job names, some implement document names, some implement 
multiple documents per job, some count sheets, some count impressions,
some can only count octets, etc. etc.

>>   It is the 2nd wierdest MIB I have ever seen.
>>   I have difficulty saying go ahead and publish.
>>   But... it is work of the PWG which is outside of the
>>   IETF, right? So not sure what we can/should do.
>>   I would certainly NOT let this thing go on the standards
>>   track.

See the comments from David Perkins of over a year ago (attached)
which did not object to the attribute mechanism, though he did suggest
that we make the attributes be two tables, instead of one.  We kept the
table as one, since there are some attributes that have both an integer
and a string value.  We took account of all his other comments.

The area directors rejected putting the Job MIB on the standards track 
a year ago on the grounds that it was an application, not something that 
managed the network.  There was no concern about the attribute mechanism 
mentioned then.

>> 
>> 4.Several references may need to be changed/updated.

No doubt.  This document is over five months old.  Should we attempt to
determine which ones are out of date?

>
>My understanding was that one of the O&M ADs was supposed to 
>contact you about this, to better understand how the problems
>might be fixed.  This might have been delayed since many of
>the IESG folks were at the ISOC conference in Geneva last week.
>
>Keith
>
>


>Reply-To: <[e-mail]>
>From: "David T. Perkins" <[e-mail]>
>To: <[e-mail]>, <[e-mail]>, <[e-mail]>
>Subject: Review of Job Monitoring MIB
>Date: Fri, 27 Jun 1997 01:18:07 PDT
>X-Msmail-Priority: Normal
>X-Mailer: Microsoft Internet Mail 4.70.1155
>
>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
>
>
>