[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Protocol operations proposal deadline

Title: RE: Protocol operations proposal deadline

Comments inline

> -----Original Message-----
> From: Wes Hardaker [mailto:wes@hardakers.net]
> Sent: Friday, September 13, 2002 11:35 AM
> To: Andy Bierman
> Cc: Dave Shield; Juergen Schoenwalder; eos@ops.ietf.org
> Subject: Re: Protocol operations proposal deadline
> >>>>> On Fri, 06 Sep 2002 15:07:47 -0700, Andy Bierman
> <abierman@cisco.com> 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.

David Harrington           
co-chair, IETF SNMPv3 WG