[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Protocol operations proposal deadline
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.
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:
(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