RE: 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