[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Protocol operations proposal deadline
> The draft list some extended features in a TC:
> These features are not defined or even described anywhere in the
> draft. I think it's a feature of the proposal that the feature
> negotiation is independent of the actual feature extensions,
Yes - quite correct.
I'd mentioned a list of features that I was interested in earlier,
but the capability negotiation mechanism was deliberately designed
as being independent of these.
I'd toyed with the idea of using OBJECT-IDENTITY definitions to
identify each capability (thus allowing them to be documented and/or
referenced more fully), but felt that the more compact nature of
enumerated BITS probably outweighed their relative anonymity.
> they illustrate an important point -- it's very likely that these
> features cannot be cleanly retrofitted to existing SNMP versions
> because they will require that rules for the contents of the
> Response PDU will be violated for some protocol operations.
I'm not sure I follow you here - or your earlier comment about:
> [creating a] new coupling between the message processing
> module and the command responder application that doesn't exist
> in current implementations.
If you want to talk SNMPv1, there's a coupling between the MPM and
command responder, in that they both need to support SNMPv1.
If you want to talk SNMPv3 with processing module XYZ, there's a
coupling in that they both need to support XYZ.
If you want to talk EOS(dts) with capability ABC, there's a coupling
in that they both need to support ABC.
Apart from granularity, what's the difference?
Similarly, if both sides of the conversation have agreed to the use
of a particular feature - how does this violate the rules?
Remember that I'm not suggesting these features be applied retrospectively.
I'd defined a "Community-based EOS" as part of my testing - but that's a
different protocol version to SNMPv2c, so a pure SNMPv2c processing module
shouldn't ever see such "extended response PDUs".