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

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



hi

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

Sandra> unambiguously determine the cause of the failed message.

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

I Agree. The command generator SHOULD check before sending.  It's not so
much
for error reporting, as the fact that sending an unrecognised PDU will
result in an error.  As a manager, I see checking what protocol extensions
are
supported when I discover a device, caching this, and then using that as
a basis of what protocol extensions to send to the device.  I'd rather check
first, so I have fewer error conditions to worry about later on.

Sharon