[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Protocol operations proposal deadline
[Apologies for the delay in responding to this thread]
> 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.
Having different features available isn't really the same thing
as "N different ways to send a given PDU". At least not if
the features are carefully thought about.
> 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.
Fair enough. I'd rather be able to make progress reasonably
quickly, without having to wait ages for the one big step to
>> 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.
Yup - I'd be happy with that.
It seems clear from what you and others have said, that overloading
the data varbind list isn't wonderfully popular. And I'd agree that
a separate field would be a cleaner solution.
If we're looking at a new PDU format (and presumably SNMP version?)
for Wes' OOPS proposal anyway, then changing the format for the other
protocol operations as well seems reasonable.
> A separate options length field solves
> the limited number of bits problem.
I get the impression you'd prefer a simple bit-string style approach,
rather than the varbind list I originally proposed. Yes?
(Note that's "prefer" rather than "want" or "like", I hasten to add!)