RE: Protocol operations proposal deadline

Comments inline

> -----Original Message-----
> From: Wes Hardaker [mailto:[email protected]]
> Sent: Friday, September 13, 2002 11:35 AM
> To: Andy Bierman
> Cc: Dave Shield; Juergen Schoenwalder; [email protected]
> Subject: 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.  [...]  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.
> 
The RFC2571 architecture was designed to accommodate these conflicting
requirements of interoperability and flexibility. The architecture contains
subsystems that can have multiple supplemental models simultaneously, yet
the whole system retains a consistent architectural model to help achieve
interoperability.

SNMPv2p was never completed partly because there was so much complexity in
the design that was not modularized. If you modified one thing,
apparently-unrelated things would break. Different people had different
priorities for SNMPv2. Changing something to accommodate one feature often
inadvertently caused ripples of side-effects, which prevented the
possibility of another feature. We went around and around trying to
accommodate everybody's requirements, and trying to sort out all the
side-effects.

The purpose of RFC2571 was to deliberately create an architecture with
subsystems, which would limit the side-effects of changes to within a
subsystem. The ASIs provide a "public" interface between subsystems, and
keeps the module-specific processing separated from other subsystems, so we
stop side-effect ripples at the ASI.

If you want to add verb/option pairings, the way to do this to remain
consistent with the RFC2571 architecture would be to put the options into
the PDU with the verb, and develop a new application that knows how to deal
with a new PDU type that has verb/option pairings, and knows how to deal
with the associated access control subsystem processing. Remaining
consistent with the ASI interfaces and using the verb as the disptch
selector would require no changes to the existing message headers, the
dispatcher code, or VACM code. 

Putting the verb-options in the message header and the verb in the PDU means
that both the message header processing code and the PDU processing code
must understand the action to be performed, and the option must be passed in
a redesigned ASI from the messaging subsystem into the application
subsystem. This approach "breaks" the SNMPv3 architecture, as currently
designed. By requiring more than one subsystem to know about these options
forces all future message formats and all future PDU formats to recognize
verb/option pairings; any changes to how one subsystem supports verb/action
pairs standards the chance of making all models of the other subsystem no
longer work properly (e.g. if a new message format doesn't support
verb-options, all the applications that assume the messaging susbsystem did
something about the options will no longer work properly). I do not consider
this cross-subsystem binding a good thing.

I think we should keep the RFC2571 architectural principles in mind when
reviewing these proposals.

dbh
---
David Harrington            
[email protected]           
co-chair, IETF SNMPv3 WG