RE: docsDevEvReporting functionality and conflicts

Folks,
 
Kevin's proposal also looks good to me.
 
Kevin and I (mostly Kevin :^) are working on the actual MIB module
changes to make this happen. In particular, if the RFC 3413/RFC 3014
notification MIBs are used per stdInterface(9), we specify that the
trap(1) and inform(2) bits are ignored.
 
We plan to submit a revised internet-draft today or Monday (at the
latest), so please respond if this approach is not acceptable.
 
Here is the proposed revised definition:
 
docsDevEvReporting OBJECT-TYPE
        SYNTAX BITS {
            local(0),
            traps(1),
            syslog(2),
            localVolatile(8),
            stdInterface(9)
        }
        MAX-ACCESS  read-write
        STATUS      current
        DESCRIPTION
            "Defines the action to be taken on occurrence of this
                event class.  Implementations may not necessarily
                support all options for all event classes, but at
                minimum must allow traps and syslogging to be
                disabled.
                If the local(0) bit is set, then log to the internal
                log and update non-volatile store, for backward
                compatibility with the original RFC 2669 definition.
                If the traps(1) bit is set, then generate
                an SNMP trap, and if the syslog(2) bit is set, then
                send a syslog message (assuming the syslog address
                is set).  If the localVolatile(8) bit is set, then
                log to the internal log without updating non-volatile
                store.  If the stdInterface(9) bit is set, then the
                agent ignores all other bits except the local(0),
                syslog(2) and localVolatile(8) bits.  Setting the
                stdInterface(9) bit indicates that RFC3413 and
                RFC3014 are being used to control event reporting
                mechanisms.
                
                Any attempt to SET the traps(1) or syslog(2) bits
                without setting the local(0) or localVolatile(8)
                bits MUST result in an error being generated."
        REFERENCE
            "RFC 3413 and RFC 3014"
        ::= { docsDevEvControlEntry 2 }
 
-- Rich

	-----Original Message-----
	From: [email protected] [mailto:[email protected]] On
Behalf Of Jean-Francois Mule
	Sent: Friday, April 01, 2005 3:53 PM
	To: Marez Kevin-MGI1375; [email protected]
	Subject: RE: [ipcdn] docsDevEvReporting functionality and
conflicts
	
	

	I have not seen any response or comment on Kevin's proposal. The
approach summarized below seems to address Randy's concern and looks ok
to me.

	 

	Any comments from anyone?

	 

	Jean-Francois

	 

	
________________________________


	From: Marez Kevin-MGI1375 [mailto:[email protected]] 
	Sent: Friday, March 11, 2005 12:13 PM
	To: '[email protected]'
	Subject: [ipcdn] docsDevEvReporting functionality and conflicts

	 

	To all:

	 

	There is a problem with the description of the
docsDevEvReporting MIB description and the conflicts it has with RFC3413
and RFC3014.

	 

	docsDevEvReporting dictates the logging mechanism(s) that are to
be invoked when an event occurs (trap, syslog, local, etc).  However,
RFC3413 also specifies similar functionality; more specifically with the
snmpNotify table and the snmpNotifyType object listing the enumerated
types of trap(1) and inform(2).  Additionally, RFC3014 specifies a
mechanism for the management of notification/event logging.  Taking
these two RFCs into account essentially removes all but the syslog(2)
functionality of the docsDevEvReporting object.

	 

	My proposal would be to add another enumerated type (bit) for
stdInterface(9) which would indicate the usage of RFC3413/RFC3014
mechanisms for notifications.  There should be no problems with
concurrent usage/support of both mechanisms so it would be possible to
perform notifications in both places.  Or, do we want to consider this
being an xor situation?  It would be necessary to exclude syslog(2) in
this case, since neither RFC3413 nor RFC3014 covers this functionality.
Essentially, (stdInterface && syslog) XOR (local && traps &&
localVolatile).

	 

	Does anyone have any other suggestions on how to address the
conflicts that have been created between docsDevEvReporting
functionality and RFC3413/RFC3014?

	 

	Thanks for your time and consideration on this issue,

	 

	Kevin

_______________________________________________
IPCDN mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ipcdn