[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: draft-ietf-eos-oidcompression-00.txt (fwd)
Sandra> If the snmpXProtoStandard object defined in the Extended Protocol
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
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
Sandra> the new PDUs and compressed OIDs, but it also seems to me that the
Sandra> Generator _should_ check before sending the new PDUs or compressed
Sandra> to verify that the Command Responder is capable of supporting these.
Sandra> Otherwise the Command Generator cannot report to the
Sandra> the true reason for an error in the response and as a result it
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
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
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
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.