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

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

HI,

It seems like I've been waging a one person battle
on the misuse of "accessible-for-notify". I guess
I just need to write an informational RFC and then
just move on. In general, I believe that MIB designers
are trying to create new control (signalling) protocols
out of SNMP. There are many problems with notifications
in SNMP, including:
 1) flow control
 2) lack of concern and coping with  dropped or
     suppressed notifications
 3) different "authEngineID" values for traps
     and informs when using USM
 4) "missing" objects for USM engine boots and time
     for "remote" engines
 5) lack of a usable log (RFC 3014 doesn't cut it)
 etc

Regards,
/david t. perkins

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.
> 
> //cmh
> 
>