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
>finally happen.

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
with meta-data. 

>  (Note that's "prefer" rather than "want" or "like", I hasten to add!)
>
>Dave

Andy