In ftp://ftp.pwg.org/pub/pwg/jmp/contributions/
-rw-r--r-- 1 pwg pwg 16234 Feb 5 06:13 jmp-ira.txt
I'd like to cover it at the meeting.
Since it is plain text, I've also added it to this message:
=========== 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.