[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: draft-ietf-eos-oidcompression-00.txt (fwd)

On Sat, 28 Apr 2001, Robert Story wrote:

> >11.  When to Compress OIDs
> > ...
> >   If a command generator does not receive a response to a message with
> >   compressed OIDs and was expecting one, the message MUST be resent
> >   without OID compression unless the command responder has advertised,
> >   and the command generator read, the ability to process compressed
> >   payload messages.  In the case where a command generator has
> >   determined a priori that a specific command responder is capable of
> >   processing compressed OID messages, the compressed OID message MAY be
> >   resent according to the implementation's retry mechanism.
> >
> I don't particularly like this requirement. In particular, the bit about
> the CG having to know **from the CR** that OID compression is supported.
> What if a command line option specified that CG use OID compression? I
> think the app should return a timeout instead of forcing a retry without
> OID compression.
> Also, the last paragraph of section 5 says "The OID Compression mechanism
> ... may only be used in new PDUs ..." If the CG is sending a new PDU using
> compressed OIDs and doesn't get a response, isn't it likely that the CR
> doesn't understand the new PDU? Wouldn't it make more sense to say that it
> must convert the PDU to one of the old PDU types without compressed OIDs?

Are you saying that you don't think the Command Generator should have to
know at all whether the Command Responder supports OID compression before
sending messages with compressed OIDs to the Command Responder?  If so,
then it seems to me that unless the Command Generator can determine, prior
to sending a message, whether the Command Responder supports new PDUs and
OID compression, then the Command Generator cannot unambiguously determine
the actual cause of a failed request. For example, if a v3 message with a
new PDU type and compressed OIDs is sent to a Command Responder that
does not support the new PDUs and OID compression then this would
result in an snmpInASNParseErrs REPORT being send to the Command
Generator. Unless the Command Generator knows whether the Command
Responder supports the new PDU type and OID compression then the Command
Generator cannot determine whether the parse error is due to the new PDU
type not being supported, OID compression not being supported, or due to
a genuine error in the PDU encoding. 

If the snmpXProtoStandard object defined in the Extended Protocol MIB
can be used to specify whether new PDUs are supported and, on top of
that, whether OID compression is supported, then it seems to me that
requiring the Command Generator to determine from the Command Responder
whether new PDUs and OID compression are supported *before* sending
compressed OIDs then this would resolve the problem of being able to 
unambiguously determine the cause of the failed message.

I agree that the user should be able to specify whether or not to use
the new PDUs and compressed OIDs, but it also seems to me that the Command
Generator _should_ check before sending the new PDUs or compressed OIDs
to verify that the Command Responder is capable of supporting these.
Otherwise the Command Generator cannot report to the application/user
the true reason for an error in the response and as a result it would
not be evident how to resolve this error. Perhaps the wording of
the document should indicate that the Command Generator SHOULD
(instead of MUST) determine whether or not the Command Responder supports
the new PDUs and OID compression before sending a message with the
new PDU type and OID compression. 

> >15.3.  Defining Aggregate Row Objects
> >
> I already voiced my ideas about this in an email commenting on Jeff's
> presentation in MN, but to recap:
> >{ fooTable 2 } is always unused to date
> >This can be used for conveying table name and row number (instance)
> >...
> >Make { fooTable 2} invisible when necessary:
> >  Suggest through pduType field a la Counter64
> >
> I think that having a pduType field removes the need for { fooTable 2 }.
> Besides, if we are trying to compress OIDs, specifying a sub-oid that will
> always be the same seems a little silly.

I'm not sure if I understand exactly what you might have in mind.
The new PDUs would not necessarily be limited to row objects only, even
though the purpose of the new PDUs is to provide a mechanism for
performing row-based operations. If, for example, you need to Set a lock
on a row at the same time as you are performing an operation on that row
then you need to have the ability to include scalar objects in your row
operation PDU.  So the new PDUs would need to have the ability to include
scalars individual columnar objects (with or without instance
information), and the new aggregate row objects all within the same PDU.

The idea with the "fooTable.2" is to provide a unique naming solution to
avoid ambiguity in the OIDs. The format that was proposed for specifying
an aggregate row object was :


If you remove the need for the '2' here and instead use the following
format for specifying an aggregate row object (which is what I assume
you are proposing) :


then you could run into cases where you could not determine whether
an OID was referring to a single column object or an aggregate row 
object. If you allow scalar, columnar, and aggregate row objects all in
the same PDU then if you had "fooTable.1.2" in your PDU how would you
determine whether this referred to a columnar or row object?  If this was
a columnar object then "fooTable.1.2" would point to column '2' in
"fooTable". However, if this were an aggregate row object then
"fooTable.1.2" would refer to the aggregate row object for row "1.2" in

The use of the "2" after the tablename (e.g. fooTable.2) provides
a means of uniquely identifying whether the OID is referring to a
single column in a table or an aggregate row object for that table.

> >15.4.  Implicit versus Explicit column identification
> >
> Again, I already voiced my ideas about this in an email commenting on
> Jeff's presentation in MN, but to recap:
> I'm not sure that I believe that it can be implicit. I'm assuming that the
> conversion between the compressed from and the expanded from will take
> place in the agent engine (otherwise sub-agents would have to handle the
> conversion, and that would mean changes to AgentX). Since a sub-agent could
> register to handle a table by specifying the table OID (or a higher level
> OID), the master agent can't expand the column OIDs.
> And as Lauren pointed out, if a new CR removes a column, thing could get
> pretty confusing pretty fast.

I'm not really arguing for one or the other, but I do think that in
most cases we'll find that implicit column identification is more
space efficient than explicit column identification. If we are trying 
to make row operations simpler and more efficient, then certainly I 
think implicit column identification might be simpler and more 
efficient than explicit column identification under some operating
conditions. If you are concerned about MIB table definitions changing and
columns being added or removed, then it seems that you could require
implicit column identification to have the position correspond to the
subidentifier assigned to that column in the table and not to a relative
position in the table. For example, if fooTable was defined with only
three columns not numbered consecutively (e.g. fooTable.1.1, fooTable.1.3,
and fooTable.1.4) then to represent a row in this table with implicit
column identification you might be required to have more than 3 values in
the aggregate row object (e.g. <val, NULL, val, val>).  Then, if at
some point either column '2' or column '5' is added to the MIB definition
then it would be discernable by the Command Generator which positions in
the aggregate row object's value corresponded to which column in the
table and values for unexpected columns could simply be discarded. 
It's not clear to me that this buys us much. And, this would still
probably require modifications to AgentX but it's not clear to me that we
wouldn't want to consider this either if this level of flexibility and
efficiency reflects what people want. 



			Sandra McLeod

Sandra McLeod <mcleod@snmp.com>
SNMP Research International         |   voice: +1 865 579-3311
3001 Kimberlin Heights Road         |   fax: +1 865 573-9197
Knoxville, TN  37920                |   WWW:  http://www.snmp.com