>-----Original Message-----
>From: Ron Bergman [mailto:rbergma at dpc.com]
>Sent: Tuesday, December 22, 1998 07:42
>To: jmp at pwg.org>Subject: JMP> Ballot on Xerox Job MIB comments
>>>I am requesting a formal ballot regarding the recent request
>from Xerox to
>expand the object jmSystemAttributeSupport to three objects.
>Since this
>is a very last minute change, it is very important that all who have
>participated in this project review this change carefully.
>Please return
>the following ballot:
>>> Name: _____Tom Hastings_______________________
>> Company: __Xerox______________________________
>> _x_ I support this proposed change
>> ___ I reject this proposed change
>> ___ I abstain from voting for the following reason:
>> ___________________________________________________________
>>>Because the holidays will soon be here, I am setting the deadline to
>January 13th. So we should have a final vote prior to the
>Maui meeting.
>>I encourage everyone to vote!
>>> Ron Bergman
> Dataproducts Corp.
>>>---------- Forwarded message ----------
>Date: Mon, 14 Dec 1998 15:47:58 -0800
>From: "Hastings, Tom N" <hastings at cp10.es.xerox.com>
>To: jmp <jmp at pwg.org>
>Subject: JMP> Xerox comments on PWG Job Monitoring MIB Last Call
>>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.dic
>ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-array>s/jmp-mib.doc
>ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-array>s/jmp-mib.mib
>ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-array>s/jmp-mib.pdf
>ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-array>s/jmp-mib.txt
>ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-array>s/jmp-mib-rev
>.doc
>ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-array>s/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
>>