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

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

This discussion goes back to why "accessible-for-notify" was added
in the first place. It was added after an interim meeting near
the DFW airport in the early 1990's.

I believe it's meaning and use has changed.

If so, saying there is an i.e./e.g. error would be incorrect.

Instead, just call it for what it is....
The SNMP community has found a change in meaning useful,
and has been using a practice that differs from the
document. The SMI is being updated to reflect the
existing practice.

There are several other items in the SMI where practice
differed from the text, and the text was updated to
reflect practice.

Popping up a level, we still have the bigger issue of
"good MIB design" for event reporting and "exception
based management". There is little written on this topic,
and there is a belief by SNMP experts (I don't know the
percentage), that SNMP is not an appropriate technology
for supporting exception based management.

I suggest that we have a BOF on this topic at the
next IETF. Here is an agenda:
  1) Overview of Polling with "trap-directed polling"
     vs exception based management
  2) Overview of SNMP protocols and SMI to support
     notifications
  3) Walkthrough of the tables used for notification
     distribution in SNMPv3 (snmpNotifyTable, snmpTargetAddrTable,
     snmpTargetParamsTable, snmpNotifyFilterTable,
     and snmpNotifyFilterProfileTable) and briefly the
     security tables (usmUserTable, vacmViewTreeFamilyTable,
     vacmAccessTable, vacmSecurityToGroupTable,
     vacmContextTable, and snmpCommunityTable). Then
     a walkthrough of the "flow" that follows after
     an event occurs that shows how entries in the tables
     are used to determine the possible notification
     targets, and the potentential filtering and
     suppression that may occur. 
  4) Walkthrough of the tables of the LOG MIB from RFC 3014.
     Then a walkthrough of how they would be used
     to store notifications, and how notifications
     would be retrieved from them.
  5) A check to see if the existing mechanisms are
     well defined (clear, concise, complete, and
     unambiguious), and provide the features at
     reasonable costs for use in "trap directed polling",
     and exception based management.
  6) A list of proposed additions and clarifications
     to improve the current mechanisms.
  
On Thu, 13 Jan 2005, Juergen Schoenwaelder wrote:
> On Thu, Jan 13, 2005 at 03:48:54PM +0100, Wijnen, Bert (Bert) wrote:
> 
> > > On Thu, Jan 13, 2005 at 02:52:33PM +0100, Wijnen, Bert (Bert) wrote:
> > >  
> > > > Randy Presuhn suggested that we probably have intended that 
> > > > accisble-for-notify was/is OK (in other words that we potentialy 
> > > > have meant "e.g." instead of "i.e.". I personally agree with that.
> > > 
> > > If there is concensus that "i.e." should have been "e.g.", then we
> > > should file an RFC errata and probably that is even good enough
> > > since I believe we really discuss a corner case here and if we try
> > > to clarify all these corner cases in the review guidelines document,
> > > the guidelines document may become less usable.
> > > 
> > That would be fine with me too. But in order to do that we need more
> > supportive statements here. In fact maybe better is to state it in this doc
> > and do the RFC-erratum after approval of this BCP. That way it goes through
> > IETF Last Call (sorry to worry about process).
> 
> I can agree to post an errata that there is an i.e. / e.g. error or
> something like that but I am not so sure I want to have this corner
> case largely discussed in the review guidelines document. 
> 
> I understand your procedural concerns - on the other hand, we managed 
> to get other erratas posted for the SMIv2 and perhaps we can use the
> same path? All boils down to whether we can reach a strong support
> here (assuming the relevant people are listening here anyway).
> 
> /js
Regards,
/david t. perkins