Re: Protocol operations proposal deadline

>>>>> On Fri, 06 Sep 2002 15:07:47 -0700, Andy Bierman <[email protected]> said:

[much discussion deleted surrounding extensibility and option negotiation]

Andy> Flexibility and extensibility often come at the expense of
Andy> interoperability.

Dave> With an extensible capability-based approach, you'd end up with:
Dave> 
Dave> eSNMP   Object-Oriented-Request(colour=on|off, sound=on|off)

My take on this whole discussion is that:  You're both right.

There is a fine line to be walked.  One side we have rigidness of a
never-flexing protocol that means more interoperability since there is
only one (possibly bad) way to do things.  Typically, this is where
SNMP has sat in the past.  There was only one way to do things with no
negotiation of more complex features.  Either you understood the PDU
or you didn't.  Period.  We've seen that this makes it hard to add
minor changes in the future when it turns out that fundamental
problems exist [and hence the creation of this working group].  On the
other side of the line is absolute flexibility within the protocol
such that new and/or many optional features can be turned on at will.
Many many other protocols have gone that route and have seen equally
bad results due to the lack of interoperability.  We must be careful,
as both sides of the line are problematic.

Yes, I think it's generally agreed that more flexibility in the PDU
structure would be a good thing at this point, but we must be
cautious.  Endless flexibility leads to no interoperability.  Anyone
who disagrees with that should take a look at some other examples,
like the IKE protocol, which the IPsec working group has decided to
scrap as interoperability has turned out to be a huge problem due to
option negotiation.  When analyzing the current situation, it's very
easy to decide that since there are current problems we must sprint
across the line to the other side of the fence where the grass is
greener.

I think that you'll find in the next version of my draft, I'll be
trying to add "some" flexibility without requiring that
implementations be dependent on the features [I don't know that I've
achieved it ideally, but it tries].  In short, I'm trying to straddle
the fence between flexibility and interoperability.  It's likely I'll
get some splinters, but will have views of both sides in the long run
which is much better than lying in one extreme where the views of the
other side are completely obstructed by the fence.

-- 
"The trouble with having an open mind, of course, is that people will
 insist on coming along and trying to put things in it."   -- Terry Pratchett