=========== Comments on IETF Job Monitoring MIB Draft =============== =========== Comments on 'jmp-mib.pdf', v0.6, 23 Jan 1997 =============== From: Ira McDonald and Tom Hastings Date: 2/4/97 * General - use of end papers with roman numeral page numbers makes reading the document confusing with Acrobat - the viewer numbers pages from decimal one in all search and goto functions (which makes the Table of Contents harder to use). * General - all of your INDEX objects suffer from a range of '(0..xxx)' - they should all have their range specified as '(1..xxx)' - an index of zero is NOT legal in SMIv1/SMIv2 tables - it indicates a simple object rather than a columnar one in the 'over-the-wire' protocol. A 'pointer' (copy of an index to some other table) that isn't specified in any 'INDEX' clause should usually be '(0..xxx)'. * iii/58 - change 'Interdet' to 'Internet'. * v/122 (and 75/1970) - change 'MIB Instance Group' to 'Job Set Group'. * 3/276 - Issue 1 - yes, add a RowStatus to 'jm[Job|Resource]Table'. * 3/283 - Issue 2 - yes, add 'jmGeneralTableOverflowPolicy'. * 4/331 - suggest italics for 'Server' * 4/342 - change 'to the network' to 'to a network' (systems may be simultaneously connected to several (PSTN/FAX and Ethernet/IP) * 5/355 - delete sentence 'In other words, queueing is a subset of spooling.' - that statement is incorrect - or 'A subset of spoolers also perform queueing.' * 5/382 (and 6/392) - change 'name, value-pair' to 'name/value pair' (the hyphen isn't needed here for clarity). * 6/412 - change 'sub-set' to 'subset' (a perfectly good word). * 6/424 - change 'are accessible via the ListJobAttributes operation' to 'are temporarily visible in this MIB's Job and Completed tables'. * 13/579 - Issue 5 - yes, restore NMS to both server and printer agents. * 14/585 - Issue 6 - no, the server deletes the job when submitting the job to the printer, if the server doesn't keep the job up to date. * 14/590 - Issue 7 - yes, add boolean about data 'freshness'. * 14/597 - Issue 8 - no, since the server deletes the job when submitting the job to the printer, if the server doesn't keep the job up to date. * 15/625 - change 'System Group...' to 'MIB-II System Group...'. * 15/628 - change 'Interface Group...' to 'MIB-II Interface Group...'. * 15/630 - change 'is implementer' to 'is implemented'. * 16/669 - delete ',i.e. , could be localized' (redundant). * 17/688 - change 'DateTime' to 'DateAndTime'. - add reference: '(see SNMPv2 Textual Conventions, RFC 1903)'. * 17/692 - change 'after the standard' to 'after this standard'. * 18/728 - Issue 9 - this MIB should leave ALL its objects 'read-only' Add a paragraph that indicates that implementors could allow monitoring applications to modify objects, by adding a private table that contains an encrypted password, with date and time mixed in and set in the clear. In addition, the OID of the object to be written and the new value is contained in the table. * 18/737 - Issue 10 - yes, add object for other jobs access policy. * 18/741 - Issue 11 - no, not writeable (see Issue 9 above). * 19/749-750 - soapbox - ALL uninstrumented objects in mandatory groups of any MIB should always correctly return 'read-only' static values specified in 'DEFVAL' clauses - 'DEFVAL' is a perfectly good SMIv2 feature intended to cover this situation - returning ANY SNMP error for ANY object in a mandatory group with a legal instance qualifier (ie, set of indices) is NOT legal in a literal reading of the SNMPv2 Protocol spec (RFC 1905, page 10, in 'Get-Request PDU' handling). - that's what 'shall implement ALL the objects in this group' means! So add DEFVAL clauses to all objects. * 19/754 - Issue 12 - return 'noError' and 'DEFVAL' in variable binding. * 19/760 - Issue 13 - Printer MIB was RIGHT not to fake SNMP errors. * 19/776 - Issue 14 - you could add something like the old SNMPv2 Party table to the Job Mon MIB - the mechanism could be shared with the Printer MIB (ie, supports directed traps for Printer MIB and other device MIBs in future). - also, BOTH the NMS and Client systems will want to register for (potentially different) traps. * 20/789 - Object Groups and Tables - collapse leftmost two columns of table as '...[Group|Table]'. * 21/792+ - Datatypes used in the Job Monitoring MIB - OCTET STRING - add '(see OSI ASN.1, ITU X.208 | ISO 8824)'. - Integer32 - add '(see IETF SNMPv2-SMI, RFC 1902)'. * 22/792+ - Datatypes used in the Job Monitoring MIB - Counter32 - add '(see SNMPv2-SMI, RFC 1902)'. - DateAndTime - add '(SNMPv2 Textual Conventions, RFC 1903)'. * 25/840 - no, not writeable (see Issue 9 above). * 27/875 (and 59/1433) - JmJobTypesTC - 'print(0)' - change 'print(0)' to 'print(1)', because at 27/862 you say 'shall return a NON-ZERO value' and because SNMPv2-SMI (RFC 1902) says it recommends that enums run 'from 1 and continuously' - also, if 'print' turns no bit on, then it is impossible to tell if 'print' is one of the requested services. - 59/1433 - change 'SYNTAX' from 'JmJobTypesTC' to 'Integer32' - you intend to add multiple values from the 'TC' together in this value * 28/883 - change 'Management...' to 'Monitoring application...'. * 28/892+ - 'preprocessing(3)' - change 'The job maybe...' to 'The job may be...'. - next line, change 'of being...' to 'of: being' (ie, add colon). * 29/892+ - 'paused(13)' - change 'resumed at the point where the job was paused' to 'resumed at the point where the job was paused or at an earlier processing boundary, if necessary.' * 31/934+ (and 64/1647) - 'JmJobStateReasonsTC' - change the SYNTAX from 'OCTET STRING' to 'INTEGER' - because you are enumerating the bit-numbers to set in the target 'OCTET STRING' * 33/934+ - 'submissionInterrupted(17)' - change 'by issuing the ReleaseJob operation' to 'by using a job submission or job management protocol operation'. * 35/934+ - 'transferring(26)' - change to 'jobTransferring' for clarity (w/ log file). * 35/934+ - 'processingToStopPoint(29)' - mention auto-resume after interrupting job completes?? - couldn't 'PauseJob' also yield a 'processingToStopPoint' ?? * 35/934+ - 'validating(31)' - change 'after a CreateJob operation' to 'after the job was created with a job submission protocol'. * 36/934+ - 'exceededAccountLimit(38)' - change 'The account for which this job is drawn' to 'The account to which this job is assigned'. * 40/954+ - 'JmResourceTypeTC' - (NO unions are not legal - this whole list is confused - the type of 'jmResourceName' should NOT ever be 'Counter32' - the (coerced) type of 'jmResourceAmount' be 'Counter32', when appropriate - there are only two cases for 'jmResourceName' - 'jmResourceNameAsText' (OCTET STRING) and 'jmResourceNameAsIndex (Integer32). - also add 'other(1)' (for proprietary resource types) and 'unknown(2)' (needed for DEFVAL clause). * 40/954+ - Issue 20 - yes, add 'filename(3)' as resource type. * 41/954+ - 'interpreters(10)' and 'PrtInterpreterFamilyTC' - will publishing of IETF Job Mon as an I-D be held up until there is a new v2 Draft of IETF Printer MIB available for the TCs?? * 42/954+ - 'physicalDevice(11)' - Issue 21 - no, have BOTH 'physicalDeviceIndex' (using HR MIB) and 'physicalDeviceName' as separate possible resources (to make Job Mon independent of both Printer MIB and HR MIB) * 43/954+ - 'processingTime(20)' - is this 'CPU used time' or 'clock elapsed time' or what?? - change name to 'processingCPUTime(20)' * 43/954+ - Issue 23 - yes, add output bins resource type. * 43/954+ - Issue 24 - don't move any resource items to the 'jmJobGroup'. * 45/966 - 'JmResourceUnitsTC' - how many of these values are actually used? Need to specify which units go with which resources, else may affect interoperability. * 47/1001 - Issue 26 - 'jmJobSetIndex' must be persistent for this MIB and 'jmJobIndex' should be recommended to be persistent - about others, we should discuss this. * 48/1006 - The General Group - since this group is mandatory, why not delete Job Set Group and let the real 'jmGeneralJobSetIndex' be defined in General group?? * 49/1048 - 'jmGeneralJobCompletedPolicy' - Issue 27 - no, not writeable (see Issue 9 above). * 49/1048 - 'jmGeneralQueueingAlgorithm' - Issue 28 - no, not writeable (see Issue 9 above). * 52/1127 - 'jmQueueIndex' - why NOT monatonically increasing order, like 'jmCompletedIndex' ?? * 52/1133 - 'jmJobIndex' - change this tag to 'jmQueueJobIndex'. - change 'value 0 need not' to 'value 0 SHALL not' (because a zero instance identifier is reserved in SNMPv2 protocol for simple objects - columnar objects are NOT permitted an instance of zero). ISSUE - What about servers or printers that assign 0 as a valid job identifier? If the agent adds one, then an operator who uses both a monitoring application with this MIB and some other will be confused by the job-identifiers being different by 1. Altenatively, the agent could map a job-identifier value of 0 to the largest positive number. Then only the job-identifier value of 0 would be different between the SNMP and the job submission protocol. * 53/1175 - 'jmJobPriority' - delete 'The omission of this attribute...' - DPA lingo. * 55/1263 - 'jmCompletedIndex' - yes, monatonically increasing, but what about roll-over?? * 56/1284 - The Job Group - Issue 30 - yes, we should probably move some Job Group objects to the Resource Group to lighten up the implementation cost of this MIB - Move: jmJobSourceChannel, jmJobSubmissionTime, jmJobComment, jmJobTotalKOctets, jmJobKOctetsCompleted, jmJobStartedProcessingTime, jmJobCompletionTime, and jmJobAccountName to the Resource Group. * 57/1331 - 'jmJobIndex' - Issue 31 - no, do not re-introduce jmJobDeviceId since the server deletes the job while the copy of the job is in the printer in config 2b. * 59/1391 - Issue 32 - yes, if there is a separate numeric object then you need to require the uniform parsing of numeric elements from client-side identifiers. * 59/1398 - Issue 33 - Some systems need both, such as BSD.. * 59/1413 - Issue 34 - In either SNMPv1 or SNMPv2, the uninstrumented objects in mandatory groups should return their static DEFVALs. * 59/1433 - 'jmJobTypes' - change SYNTAX from 'JmJobTypesTC' (bits) to 'Integer32' (bitmap). * 61/1498 - 'jmDeviceIndex' - change '(hrDeviceIndex)' to '(to 'hrDeviceTable)'. * 61/1501 - 'jmDeviceIndex' - add reference: '(see Host Resources MIB, RFC 1514)'. * 61/1504-1505 - change 'shall return the SNMP ... rather than zero' to 'shall return zero, to indicate 'none''. * 61/1520 - Issue 37 - yes change 'jmJobSourceChannel' to use the enum, to avoid Printer MIB dependencies. * 62/1538 - Issue 38 - yes, add 'jmJobChannelInformation' to Server, to avoid Printer MIB dependencies. * 63/1624 - Issue 39 - no, return (-2) for unknown. * 65/1700 - Issue 41 - no, ALWAYS round up, so that the guage becomes non-zero as soon as any formatting activity commences and remains rounded up throughout - more user friendly. * 66/1757-1758 - 'jmJobAccountName' - change 'SNMP error ??? shall be returned' to 'the null string (zero length, see DEFVAL) shall be returned'. * 67/762+ - The Resource Group - change 'and/or used resources' to 'and/or consumed resources'. * 68/1782 - INDEX clause of 'jmResourceEntry' sequence - if you added 'jmResourceType' as the second to last (rightmost) index, then this table would be automatically sorted (and indexable) via resource type (by using a partial OID in the SNMP Get-Next PDU). * 68/1785+ - 'JmResourceEntry' and 'jmResourceName' - the postulated union is illegal in SMIv1 or SMIv2 - you can have 'jmResourceNameAsText' and 'jmResourceNameAsIndex' objects (see 40/954, 'JmResourceTypeTC' comments earlier in this note). * 69/1829 - Issue 43 - see above note and 40/954 comments. * 71/1885 - conformance for 'jmQueueGroup' - use a 'GROUP' subclause in your 'MODULE-COMPLIANCE' macro for all conditionally mandatory or option groups (SNMPv2-CONF, RFC 1904), NOT just a comment. * 72/1913 - 'jmQueueGroup' - The DESCRIPTION clauses of OBJECT-GROUP macros always reiterate the 'condition(s)' for 'conditionally mandatory' groups. * 98/1991+ - the header ending in '...Index' is wrong - and it remains wrong up through page 103/2035 (Change History) inclusive.