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

[Matt White <mwhite@torrentnet.com>]

--On Saturday, April 28, 2001 5:43 PM -0400 Robert Story 
<rstory@freesnmp.com> 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.

This is actually a good point and was covered at one point.  I must've 
altered the intent of that text somewhere in the editting.  Certainly the 
operator should be able to specify whether or not to use compression.


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

This text is perhaps a bit unclear.  There is a possibility that a message 
type will not be expected to generate response messages.  In those cases, 
you can't use the fallback mechanism described above.

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

The user should be able to, but I don't think this should be the default 
mode of operation.  I'll see about fixing this.


-Matt