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

Re: draft-ietf-eos-oidcompression-00.txt

>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?

>   Before generating messages that ellicit no response, a command
I'd like to see the algorithm to determine if a message will ellicit no
response before the messages is sent! :)

>   generator MUST ascertain through advertised capabilities that the
>   command responder is capable of processing compressed OIDs.
Again, why not let the user specify whether or not to use the new PDUs and
compressed OIDs?

>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.

>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.