docsDevEvReporting functionality and conflicts

Marez Kevin-MGI1375 <[email protected]>
Newsgroups gmane.ietf.ipcdn
Message-ID <D5A7E45D575DD61180130002A5DB377C0E922FC6@ca25exm01>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.