We held a Xerox-wide design review the proposed version 1.3 of the PWG Job
Monitoring MIB that included a number of client-side developers as well as
agent developers. We believe that the single bit array,
jmSystemAttributeSupport, indicating attribute support should be replaced
with three bit arrays:
1) A bit array specifying which supported attributes can contain meaningful
integer data.
2) A bit array specifying which supported attributes can contain meaningful
string data.
3) A bit array specifying which supported attributes can have more than one
integer or more than one string value.
There are two main areas of concern regarding the use of "dictionary" or
attribute defining MIBs. First is the efficiency with which attribute
values can be requested and obtained from the device and second is the
ability to create generic management middleware that can be reused when the
MIB is extended with additional attributes and can be used with different
management applications that use different combinations of attributes. Such
middleware obtains all of the attributes and keeps a local copy of the
attributes updated as the device runs. Any management application then
deals with the client-side local copy by calling the client-side management
middleware for any combination of attributes which are returned immediately
without querying the device.
Some items of note which should be considered in the following discussion
are:
1) Most management applications must support SNMPv1 and SNMPv2 so that
relying on a getBulk type operation is not viable.
2) Most management applications support multiple SNMP protocol stacks some
of which have quite small packet size limits such as 480 octets so relying
on a maximum size of more than that is not viable.
One of the major concerns of many management applications is the
minimization of network traffic and a major factor in determining the amount
of traffic is the number of strings to be retrieved. The reason for this is
due to the fact that strings can be fairly long, up to 63 octets. Couple
this with the limited packet size available and it is easily seen that if a
large number of strings are to be retrieved then a large number of packets
will be required. At most only 6 strings can be requested in a single
packet, else there is the risk of not all of the data fitting in the packet.
This is because each string can be up to 63 octets and the OID for each
string can be around 15-20 octets, say around 80 as a maximum. 484 divided
by 80 is 6 strings maximum. If only a single bit array is used then both
the integer and string values will have to be requested for all of the
supported attributes. Since most of the string values will be NULL this
results in a large number of packets with unnecessary data (the null
strings). With an indicator of which attributes can actually have valid
string data then only those attributes need to be requested and the number
of needed packets can be optimized. This same argument applies to integers
as well, although, to a lesser degree since 24 or so integers can be
requested in a single packet.
Being able to request this information from the device rather than encoding
it directly into management application middleware makes the application
middleware more robust, generic and re-usable. Encoding the information
directly into the application middleware that an application needs means
that the middleware can not be used with any application. It also means
that if new attributes are added to a MIB then the application middleware
will have to be modified to accommodate them. Neither of these situations
is desirable from a software design and product deployment point-of-view.
Adding the bit array that indicates which attributes might have more than
one value and which ones cannot, means that the management application knows
which values should be retrieved with several GetNext operations in order to
pick up all the values and which only need one direct Get. While the
specification indicates which attribute MAY have multiple values, many
implementations MAY only actually implement one value. For example, the
number of fileName or documentName attribute values per job MAY only have a
single value for many implementations that only support one document per
job, though multiple values are allowed. The same for mediumRequested, etc.
So the third bit array indicates which attributes could have more than one
value for that implementation.
Having these three bit arrays also allows management middleware to obtain
attribute extensions from a device that were registered after the management
middleware was shipped. Only the management application needs updating that
wants to take advantage of the newly registered attributes.
Since these bit arrays are all read-only and never change while the device
operates, they are very low cost in implementation and can be put into ROM.
While we share the group's concern about "creeping elegance" and "mission
creep" and want to see the PWG Job Monitoring MIB approved, we believe that
these three bit arrays are the end. There does not seem to be any other
support information about an implementation that could be added to the new
System Group. So we believe that this addition would be the end.
We have produced complete compilable alternatives to V1.3 and stored them in
a sub-directory of the usual place:
ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-arrays/jmp.dicftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-arrays/jmp-mib.docftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-arrays/jmp-mib.mibftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-arrays/jmp-mib.pdfftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-arrays/jmp-mib.txtftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-arrays/jmp-mib-rev
.doc
ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-arrays/jmp-mib-rev
.pdf
Here are the relevant changes:
In Section 3.3.8 Attribute Specification update the paragraphs on the bit
array support:
A management application can determine which attributes are supported
and whether the integer and/or the octet string values are supported
with meaningful value by querying the jmSystemAttrIntegerSupport and
jmSystemAttrOctetsSupport objects, respectively. Management
applications can also determine which supported attributes might
support more than one integer value or more than one octet string value
by querying jmSystemAttrMultiRowSupport.
These support bits are indicated in hex for each range in the line
starting with "support bits starting:". Note: these objects permit a
management application to determine the degree of support, even when
there are no jobs present in the system. They also permit management
middleware to fetch all attribute values for all jobs, including future
extensions, and keep them updated for one or more management
applications at the same time.
Replace the jmSystemAttributeSupport bit array object with the following
three bit array objects:
jmSystemAttrIntegerSupport OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0..63))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A bit array indicating which attributes of the MIB this
implementation supports with meaningful integer values.
The value of this object is a sparse bit array in which bit n
is a 1 if attribute n is supported with the
jmAttributeValueAsInteger object with meaningful values, where
n is the value of the enumerated attribute type in the
JmAttributeTypeTC used in jmAttributeTypeIndex (and the
jmMirrorAttrTypeIndex if the jmMirrorAttrTable is implemented).
Bit n MUST be 0 (or beyond the end of the returned bit array),
if attribute n is not supported or is always returned with a '-
1'(other) or '-2'(unknown) value.
The high order bit of the first octet in this octet string
corresponds to an attribute type of 0 (reserved), i.e., the bit
string uses the Big Endian numbering convention. Compare with
the BITS data type in SMIv2 [SMIv2-SMI] which has the same
format but requires contiguous enumerated bits. Trailing
octets in the octet string that contain only zero bits MUST NOT
be returned.
Note: private attributes cannot be represented in this bit
array because their enum values are in the range 2**30 to
2**31-1. See section 3.3.8.
Example: An implementation supporting the attributes:
jobStateReasons2(3), jobStateReasons3(4), and jobName(23)
would return a one-octet string value of { '18'H }, since
jobName is an octet string value, not an integer value.
This object helps a management application determine which
attributes with meaningful integer values MAY be present on
jobs in this system."
DEFVAL { ''H } -- no attributes are required
::= { jmSystem 3 }
jmSystemAttrOctetsSupport OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0..63))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A bit array indicating which attributes of the MIB this
implementation supports with meaningful octet string values.
The format and semantics of this object is the same as
jmSystemAttrIntegerSupport, except that bit n indicates that
attribute n supports the jmAttributeValueAsOctets object with
meaningful values, instead of the jmAttributeValueAsInteger
object. Bit n MUST be 0 (or beyond the end of the returned bit
array), if attribute n is not supported or is always returned
as a zero-length octet string value.
If an implementation supports both jmAttributeValueAsInteger
and jmAttributeValueAsOctets with meaningful values for
attribute n, bit n MUST appear in both bit array objects with a
1 value.
Example: An implementation supporting the attributes:
jobStateReasons2(3), jobStateReasons3(4), and jobName(23)
would return a three-octet string value of { '000001'H }, since
jobStateReasons2 and jobStateReasons3 are integer values, not
octet string values.
This object helps a management application determine which
attributes with meaningful octet string values MAY be present
on jobs in this system."
DEFVAL { ''H } -- no attributes are required
::= { jmSystem 4 }
jmSystemAttrMultiRowSupport OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0..63))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A bit array indicating which MULTI-ROW attributes of the MIB
this implementation supports with multiple integer values
and/or multiple octet string values.
The format of this object is the same as the
jmSystemAttrIntegerSupport and jmSystemAttrOctetsSupport
objects. Bit n MUST be 1, if attribute n is actually supported
with more than one integer and/or more than one octet string
value. Bit n MUST be 0 (or beyond the end of the returned bit
array), if attribute n is not supported, is always returned as
a single integer value, or as a single octet string value. For
every bit n that is a 1 in this bit array, there MUST be a
corresponding 1 for bit n in either jmSystemAttrIntegerSupport,
jmSystemAttrOctetsSupport, or both.
Example: Consider an implementation supporting:
(a) the jobStateReasons2(3), jobStateReasons3(4) SINGLE-ROW
integer attributes
(b) the jobName(23) SINGLE-ROW octet string attribute
(c) more than one integer value for the mediumRequested(170)
and mediumConsumed(171) MULTI-ROW attributes AND
(d) more than one octet string value for the fileName(34),
documentName(35), and mediumConsumed(171) MULTI-ROW attributes
(e) no octet string values for mediumRequested(170).
Such an implementation would return:
jmSystemAttrIntegerSupport 22 octets:
{ '18000000 00000000 00000000 00000000 00000000 0030'H }
jmSystemAttrOctetsSupport 22 octets:
{ '00000100 30000000 00000000 00000000 00000000 0010'H }
jmSystemAttrMultiRowSupport 22 octets:
{ '00000000 30000000 00000000 00000000 00000000 0030'H }
Example: Consider an implementation that supports the
fileName(34) MULTI-ROW attribute, but does not support more
than one document per job. Such an implementation would NOT
return a 1 bit for bit 34 in jmSystemAttrMultiRowSupport, since
such an implementation would never return more than one
fileName value for a job. It would return a zero-length
string, since it never returns more than one value.
This object helps a management application determine which
attributes may return more than one integer value or more than
one octet string value on jobs in this system."
DEFVAL { ''H } -- no attributes are required
::= { jmSystem 5 }
Tom Hastings, Ira McDonald, Paul Gloger, Gary Padlipsky, Mike Elvers, Ang
Caruso, Joe Filion
(310) 333-6413