[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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> 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
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.