>-----Original Message----- >From: Ron Bergman [mailto:rbergma@dpc.com] >Sent: Tuesday, December 22, 1998 07:42 >To: jmp@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@cp10.es.xerox.com> >To: jmp <jmp@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-array
s/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 > >