>>>>> On Fri, 21 Oct 2005 10:36:11 +0100, Dave Shield <[EMAIL PROTECTED]> said:
Dave> I don't think it's fair to add this sort of new functionality, Dave> and then *immediately* go into pre-release mode. Which means your belief is that feature freeze should actually begin before the first pre-release, which is quite counter to anything you've said in the past (or even the fact that you've implemented huge new MIBs all in the last week or so... yes, you beat the last second deadline by a week or two but with a huge amount of code). I don't mind talking about that though. Dave> A MIB interface is desirable but not essential, and is Dave> *definitely* the hardest to fix problems with. We should not be Dave> trying to rush into that. Look at the problems we've had with Dave> correcting the relocatable "exec" MIB structure - which isn't Dave> even valid! Hey, now be fair, I wrote the exec MIB as the first thing I ever did before I had even read a book about how to write MIBs ;-) Dave> I'd have been *very* uncomfortable about trying to do (c) [mib] Dave> in time for 5.3. Good, because I'm not doing it. Dave> Most of the fields listed above tend to have the same fixed Dave> values in 99% of "access" lines. So why not let them default Dave> to the normal values, and only specify them when they're different? Dave> Either using optional positional parameters (just re-ordering the Dave> fields above), or (better) using the equivalent 'snmpcmd' options? Dave> For example: Dave> setaccess read publicName Dave> setaccess write privateName -l auth Dave> setaccess execute adminName -Cn context Dave> setaccess log _all We certainly could apply easier to use tokens in the future for all the VACM stuff. I think we're too late to talk about that, but I don't think that providing those extra tokens in the future will be affected by anything today. I'm not sure it's ideal, but I don't think it's bad. Certainly redesigning the VACM tokens will be quite a bit of work both in design and in code (what you're proposing above requires state between token parsers, which would be new and take more code and static variable storage). >> And there would be wrapper tokens equivalent to the rocommunity like >> tokens to quick-create access for a given community for a given type >> (eg "logcommunity"). Dave> That's one approach, certainly. Dave> An alternative would be to generalise the xxCommunity directive: Dave> community read-only public Dave> community read-write private Dave> community execute admin Dave> community log _all Dave> It's still one line, and would avoid a proliferation of new Dave> configure directives. The proliferation was more for ease of use. Read me last note and you'll see we could drop all the ipv4logcommunity, ipv4executecommunity, etc and just go with ipv4authcommunity. Whether we should merge the ipv4 transport community with the ipv6 community is subject to debate, of course. Dave> The other relevant question is how much granularity are Dave> you planning for the initial 5.3 release? >> Filtering on the actions called for an incoming trap. IE, the >> community of "public" may only be granted the right to log it but not >> execute. The snmpv3 user "wes" might be allowed to do all actions. Dave> Ummm.... OK. I was slightly surprised you didn't have a Dave> "pre-decision" filter as well: Dave> "Non-authenticated traps won't be processed at all" What's a non-authenticated trap? There is an explicit rule that if you don't have any authorization for anything it gets dropped. IE, if you can't log, net or forward it stops right there (in your handler api speak (which I like a lot having just used a lot) it returns a FINISHED if there are no VACM entries that match for the incoming PDU. -- Wes Hardaker Sparta, Inc. ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
