Re: Protocol operations proposal deadline

At 10:19 PM 9/6/2002 +0100, Dave Shield wrote:
>Andy> I have read the SNMP Extended Capability Negotiation draft, and I
>Andy> have some comments.
>Andy> 
>Andy> 1) new protocol version vs. retrofitted features
>Andy>    I think this draft provides a good framework for retrofitting
>Andy>    existing versions of SNMP with new protocol features,
>
>Thank you (I think!), but retrofitting wasn't really the main thrust
>of this proposal.
>
>   What I was trying to do was propose a mechanism for supporting
>future extensions, without being restricted to the (relatively blunt)
>mechanisms of new protocol operations and/or versions.
>
>   The fact that the approach used the same PDU structure as existing
>versions was (from my point of view) an added bonus - if only for
>purposes of implementation and testing.  Maybe the testing examples
>(and application syntax) I used were a mistake, since people seem to
>be getting hung up on the idea of whether or not to apply new features
>to existing versions.
>   It certainly wasn't the core aim of the proposal.
>
>
>  What I'm really trying to argue is twofold:
>
>    a) Having once defined a new "extensible processing model", this
>model should be sufficient to accomodate future additional features,
>without needing to define a new version or model every time.
>
>    b) New features need not _necessarily_ be introduced via a new
>protocol operation.  Sometimes this might be the most appropriate
>mechanism, but not always.

Flexibility and extensibility often come at the expense of
interoperability.  It doesn't make the NMS design any easier
knowing there are N different ways to send a given PDU.
I've often heard NMS developers say they don't use optional
features or optional MIB objects.  I would rather see the
SNMP standards advance in finite and well-understood steps.
I'd rather see 1 big step than 10 baby steps.  Deployment
of new toolsets is a non-trivial task in many organizations.



>  To illustrate this - consider Wes' Object-Oriented request operation,
>which later (maybe a couple of years down the line) needed to be
>independently extended in two different directions (say, to add Colour
>and Sound), which still later were combined together.
>  With a new version/PDU approach you end up with something like:
>
>        SNMPv4          Object-Oriented-Request
>        SNMPv5          Object-Oriented-Request-With-Colour
>        SNMPv6          Object-Oriented-Request-With-Sound
>        SNMPv7          Object-Oriented-Request-With-Colour-and-Sound
>
>(or possibly four different processing models rather than versions - the
> underlying point still stands).
>
>  With an extensible capability-based approach, you'd end up with:
>
>        eSNMP   Object-Oriented-Request(colour=on|off, sound=on|off)
>
>
>Andy> In summary, I think we should leave existing versions of the
>Andy> SNMP PDU alone, and add new features to a new message structure
>Andy> in the cleanest manner possible.
> 
>Juergen> Although we should learn from history and have a few unused
>Juergen> bits in the new PDU format.
>
>I'm not convinced that a bit-based approach would leave us with sufficient
>flexibility.  It might accomodate a limited amount of extensibility, but
>I'm concerned that we might quickly run out of unused bits if that was
>the only available mechanism.
>
>   Maybe trying to shoehorn capability negotiation into the existing
>varbind list isn't the best way (though it proved extremely straightforward
>to implement).  But I'd ideally like to see *some* mechanism for handling
>future extensions without being tied to the version/model numbers, or
>PDU types.

This should be considered as part of the new PDU format.
Maybe an SNMP Options field, similar to IP Options would
be a good idea.  A separate options length field solves
the limited number of bits problem.




>Dave 

Andy