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



>>         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!)

Dave