[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Protocol operations proposal deadline
At 02:07 PM 9/11/2002 +0100, Dave Shield wrote:
> [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.
Having lots of optional features is problematic for NMS applications
which attempt to support many different agent platforms. I don't
write NMS apps for a living, but I've worked for almost 14 years
with NMS developers, providing embedded NM agent features for them.
A common theme: They would gladly give up flexibility for consistency
and stability. Get the API right the first time and don't make
them keep rewriting the same code to support new platforms.
>> 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
The IETF is so slow, and vendor deployment is even slower,
that a couple little steps take as long as one big step.
>>> 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?
I like the concepts proposed in your draft. The only issues I have
are the granularity of the requests and overloading the varbind list
> (Note that's "prefer" rather than "want" or "like", I hasten to add!)