snip...
>There is one change that would affect any current implementations
>that I strongly suggest that you do. Table jmAttributeTable has
>three accessible columnar objects. The first tells you the "type"
>(either integer, octet, or both) of the value of the attribute.
>The second two columns are the attribute's value. I suggest that
>instead of this single table, that you have two tables. Each table
>would have a single accessible column. The first table would contain
>integer valued attributes, and the second table would contain
>octet string valued attributes.
[David did not mention that there is actually a fourth index which
is an "instance" index for those attributes that can have more than
one value per job. I'm not sure whether this fact changes the argument
or not.]
snip...
We need to consider this suggestion and either accept it or justify
why not. Lets get collected comments (such as Harry's below) and
respond to David. David is a noted authority on SNMP, so accommodating
his comments will help forward our document.
Xerox developers have several views and we are in the process of
reaching a consensus (I'll send you results Thursday, 7/10).
Harry Lewis's developers have made a review and are not convinced that
it is a good idea to split the table:
>Return-Path: <harryl@us.ibm.com>
>From: Harry Lewis <harryl@us.ibm.com>
>To: <hastings@cp10.es.xerox.com>
>Cc: <jkm@underscore.com>, <rbergma@dpc.com>, <bpenteco@boi.hp.com>
>Subject: Splitting the Attribute Table
>Date: Wed, 9 Jul 1997 10:52:02 PDT
>
>Tom, we have conducted a review here, regarding your recommendation
>to split the attribute table into two tables - one for Integer values
>and one for Octets - and are of the opinion that the current attribute
>table is superior. Here is our summary.
>
>1. First, we assume that attributes will have a null string for the
>valueAsOctet and -2 for valueAsInteger if appropriate.
>
>2. With GetNext, we do not believe network traffic is an issue because
>the "extra" null string or -2 will fit in the PUD packet.
>
>3. We believe, using get next, there are less calls required with the
>current scheme than would be needed if the table was split.
>
>Example:
>
> Integer Octet
> ------- -----
>
> -2 X
> X Null
> X X
> X Null
> -2 X
>
>
>Consider the above excerpt. It will take 5 get next calls using the current
>method. But it would take 6 calls if the table were split (one for each X
>which represents a real value).
>
>4. While, in most cases, the monitor will know whether or not the attribute
>is defined as Integer, Octet or Both... there are cases where it could
>be EITHER. With the current scheme, the monitor "finds out" what this
>particular device has instrumented in one get next (for each attribute).
>With split tables, you have to look in both tables to know (this may
>just be a restatement of (3) above).
>
>5. There is no storage savings in the agent if done properly, where the
>agent knows which syntax is being used.
>
>Tom, this is our summary. I think the ball is "in your court" to decide
>whether or not to open this problem to a wider audience, send us a
>DETAILED "rebuttal" or accept our findings.
>
>
>Harry Lewis - IBM Printing Systems
>
>