[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Protocol operations proposal deadline
At 10:20 PM 9/6/2002 +0100, Dave Shield wrote:
>> 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?
I think it's cleaner to keep meta-data out of the varbind list.
I think there's an incorrect assumption that added new
protocol operations via varbinds is somehow going to make
the (agent and NMS) code design easier than adding a
new message wrapper or PDU types.
I think overloading the varbind list is problematic.
What happens if the VACM config eliminates these fields
from view in the response PDU and the command generator
can't tell which option requests were granted?
>Similarly, if both sides of the conversation have agreed to the use
>of a particular feature - how does this violate the rules?
I am concerned about unintended consequences in both the implementations
and the standards documents. I would rather not use the varbind list
for anything but MIB data.
>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".