RE: [Fwd: Re: [RMONMIB] I-D ACTION:draft-ietf-rmonmib-raqmon-pdu-08.txt]

["David B Harrington" <dbharrington@comcast.net>]

Hi,

I have a concern over whether tables full of accessible-for-notify
objects obscures the fundamental philosophy of SNMP.

SNMP was designed to be a trap-driven-polling management approach.
There was considerable debate over interrupt-driven or polling-driven
reporting of events. Event-driven management introduces complexity and
puts a larger burden on the agent; polling-only management has
problems of timeliness; the trap-driven-polling management approach
was preferred because it allowed simpler agents and put the onus for
coordination on the manager, which often has a better "big picture"
view of the network than the agent. I have seen many attempts to use
SNMP as a purely event-driven environment, mostly by people who have
come from environments that use other management protocols and,
understandably, misinterpret the purpose of SNMP notifications.

SNMP was simply not designed to be used for event-driven management.
From Marshall Rose's "Simple Book", section 3.1.3, 
"In the Internet-standard Network Management Framework, the model used
is one of trap-directed polling. When an extraordinary event occurs,
the managed node sends a <italics>single</italics>, simple trap to the
NOC. The NOC is then responsible for initiating further interactions
with the managed node in order to determine the nature and extent of
the problem. This compromise is surprisingly effective: the impact on
managed nodes remains small; the impact on network bandwidth is
minimized; and, problems can be dealt with in a timely fashion."

I feel uncomfortable having tables of accessible-for-notify objects
because it seems to promote sending many, non-simple notifications,
thus using SNMP for event-driven management rather than event-driven
polling management. If there are many objects that need to be
communicated from an agent to a manager, then put the objects into a
readable table, send a notification to the manager, and let the
manager retrieve the tabular information.
That is much more consistent with the design of SNMP. If the
trap-directed polling approach is inconsistent with specific needs of
the management functionality being designed, then SNMP is not a good
protocol to use.

Maybe we should change the fundamental design of SNMP to make it an
event-driven environment. I don't think so personally, since the
simplicity of the trap-driven polling approach is one of the factors
that I believe helped SNMP become widely adopted. If the community
wants to change SNMP to be a protocol for event-driven management, I
would like the IETF to make such a change deliberately, not by
side-effect of one mib module design.

Changing the guidelines to say "this is how to build tables of
accessible-for-notify objects" might lead others to think that this is
an acceptable approach to doing SNMP management, and I don't want to
encourage that until after the IAB/IESG/IETF community has had a long
serious talk about the fundamental approach of the Internet-standard
Network Management Framework, and deliberately decides to change the
approach.

Until we have such a talk, and agree to make such a philosophical
shift to the Internet-standard Network Management Framework, I
respectfully oppose adding this change to the guidelines document.

David Harrington
dbharrington@comcast.net
SNMP old-dog

> -----Original Message-----
> From: owner-mreview@ops.ietf.org 
> [mailto:owner-mreview@ops.ietf.org] On Behalf Of C. M. Heard
> Sent: Wednesday, January 12, 2005 2:13 AM
> To: Mreview (E-mail)
> Cc: Mark Ellison
> Subject: Re: [Fwd: Re: [RMONMIB] I-D 
> ACTION:draft-ietf-rmonmib-raqmon-pdu-08.txt]
> 
> On Fri, 7 Jan 2005, C. M. Heard wrote:
> > On Fri, 7 Jan 2005, Mark Ellison wrote:
> > > > Here's the suggested text (corrected):
> > > >
> > > >    - For conceptual rows used exclusively for defining objects
> > > >    referenced by notification definitions:
> > > >
> > > >        - At least one non-auxiliary object must be defined
with
> > > >        a MAX-ACCESS of (at least) "accessible-for-notify"
> > 
> > I don't have an issue with including this text if the other MIB
> > Doctors agree.  I don't think it says anything different from what
> > is in RFC 2578, but when running some test cases I did notice that
> > an old version of SMICng complained about "accessible-for-notify"
> > objects in tables:
> > 
> > E: f(xx.mi2), (2089,1) Row "xxxEntry" may not object with status
of
> > "accessible-for-notify" defined under it
> > E: f(xx.mi2), (2122,1) Item "xxxNearFarFlag" has invalid value for
> > max-access
> > 
> > So maybe adding some text to cover this point is worhtwhile.
> > 
> > MIB Doctor comments, please.
> 
> I haven't heard any MIB Doctors speak up in favor of making this
> change.
> 
> Based on that, I think I have to assume that we do not have
> consensus to put it into the next spin of the document.
> 
> Mike
> 
> 
>