Wes> The other thing I considered doing... Wes> ... was augmenting the VACM MIB's vacmAccessEntry to add Wes> more columns for the different types of trapd (or to add a Wes> supplemental table with an arbitrary string index for different Wes> "registries" of event action types instead to be more flexible for the Wes> future).
Yes - that's pretty much the model I had in mind, too. I was probably thinking in terms of an integer-indexed augmenting table rather than a string-indexed one, but either would be fine. Wes> The thing is, the VACM is well documented and moderately Wes> understood by most people and fits most of the bill. Designing Wes> something entirely new means making people understand something Wes> entirely new and probably equally as complex by the time we're done Wes> with it. But augmententing the VACM access table isn't designing something "entirely new". It's taking an existing, familiar mechanism, and extending it in a reasonably natural manner. I'd actually suggest that using existing MIB objects for the "wrong" purpose is probably *more* confusing, than extending things cleanly. Wes> Now, the one issue that I'm surprised David P. hasn't raised (I've Wes> been waiting) is that the VACM is designed for a single engineID Wes> acting as the responder. For trap reception, this is no longer the Wes> case and there can be a [EMAIL PROTECTED] and a [EMAIL PROTECTED] that need to be Wes> mapped to a different group name for purposes of authorization. I need to go back to the SNMPv3 specs to check, but isn't that part of the distinction between "user names" and "security names" ? The VACM presumably works with (SM-independent) security names. I'd expect the user->security mapping to be where the [EMAIL PROTECTED],2} stuff would need to be addressed. That was actually part of the original problem - or at least following directly on from it. We started with David's observation that the trap handler (and probably the agent (and clients?)) simply dropped "bogus" incoming PDUs silently - giving no indication of the problem. That then led us to the whole question of how to handle [EMAIL PROTECTED],2} in a way that is flexible, secure, and scalable. [I was actually expecting you to scream blue murder at the very idea of wildcarding engineIDs. Your passing comment sounded surprisingly positive. Does that mean you think this might be useful/sensible (in certain situations, obviously)?] The discussion has strayed a bit since then! :-) Dave ------------------------------------------------------- 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
