[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: firstname.lastname@example.org
- Subject: Re: draft-ietf-eos-oidcompression-00.txt
- From: Matt White <email@example.com>
- Date: Sun, 29 Apr 2001 14:36:24 -0400
- Delivery-date: Sun, 29 Apr 2001 11:34:50 -0700
- Envelope-to: firstname.lastname@example.org
--On Saturday, April 28, 2001 5:43 PM -0400 Robert Story
>> 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.