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

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

At 12:19 PM -0400 5/1/01, Sandra McLeod 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
> 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.
This is exactly what I wanted. I should have been specific and I would have
saved us both a bunch of typing.

>> >15.3.  Defining Aggregate Row Objects
>> >
>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 :
>	<table>.2.<row>
>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) :
>	<table>.<row>
Again, I think the confusion is mine. I was thinking of a combination of
your draft and Lauren's. Specifically if (from Lauren's draft) we have a
xxxRowPDU, and
      rowIdentifier = <vb.name=tableEntryPart,

then specifying (from your draft) tableEntryPart.2 didn't make sense, as
the <row/instance> part is encoded separately and the 2 isn't needed to
identify the object as aggregate because the new PDU type implied already
implied this.

I agree that <table>.2.<row> would be useful in table OID compression for
non-row PDUs.

>> >15.4.  Implicit versus Explicit column identification
>> >
>> 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.
I agree that it would be more efficient, but I still think that it can/will
result in unexpected behavior. The larger a network grows, the more likely
someone will have a device with out of date firmware that will confuse an
unknowing script/operator. And I think the cost, byte-wise, is reasonable
considering the savings from table OID suppression.