Re: Protocol operations proposal deadline

[Dave Shield <D.T.Shield@csc.liv.ac.uk>]

>    The draft list some extended features in a TC:
		[snip]
>   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. 


>                                                                but
>   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".

Dave