>>>>> On Mon, 05 Sep 2005 15:22:38 +0100, Dave Shield <[EMAIL PROTECTED]> said:
Dave> The underlying idea of restricting access to different categories Dave> of action (separately configurable) is probably sensible enough. Dave> But trying to shoehorn this into the existing VACM table is Just Dave> Plain Wrong. The other thing I considered doing, which I'd argue is potentially the best thing to do, was augmenting the VACM MIB's vacmAccessEntry to add more columns for the different types of trapd (or to add a supplemental table with an arbitrary string index for different "registries" of event action types instead to be more flexible for the future). The thing is, the VACM is well documented and moderately understood by most people and fits most of the bill. Designing something entirely new means making people understand something entirely new and probably equally as complex by the time we're done with it. Now, the one issue that I'm surprised David P. hasn't raised (I've been waiting) is that the VACM is designed for a single engineID acting as the responder. For trap reception, this is no longer the case and there can be a [EMAIL PROTECTED] and a [EMAIL PROTECTED] that need to be mapped to a different group name for purposes of authorization. -- Wes Hardaker Sparta, Inc. ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
