>>>>> On Sat, 22 Oct 2005 00:02:06 +0100, Dave Shield <[EMAIL PROTECTED]> said:

Wes> redesigning the VACM tokens will be quite
Wes> a bit of work both in design and in code (what you're
Wes> proposing requires state between token parsers

Dave> Does it *inherently* requires state between token parsers,
Dave> or is that just a consequence of the current implementation
Dave> approach?

It was a complication of what you were approaching.  You said,
roughly, that you wanted the current command to only require
differences from the last one (which in hind sight may not be wise at
all, since the last one may have been in a different file entirely,
for example, or much farther up that you didn't realize).

>>> ipv4logcommunity mycommunity
>>> ipv4executecommunity mycommunity

Wes> Will not work.

Dave> Much the same comment applies - are these limitations
Dave> inherent in the structure of the VACM directives, or
Dave> just a feature of the current implementation?

Sorry, bad wording.  It'd take a lot more work and memory.

Dave> Yup - that's much better, though it does raise the
Dave> question of what the effect should be of

Dave> ipv4authcommunity  xyzzy

Nothing, unfortunately, and it currently doesn't spit an error but it
certainly should.

Dave> So let's have a bit of discussion about what the options
Dave> are, and *why* they are bad.  You never know, the combined
Dave> expretise of the whole Net-SNMP community might actually
Dave> be able to come up with something a little bit better
Dave> than you on your own :-)

I can't believe *you* just said that.  (you typically take a similar
approach: implement a bunch of stuff and *then* ask for opinions on
it ;-)

Dave> Actually, that's something else that has bitten me recently
Dave> (in conjunction with the Event-MIB/iquery handling).  Why
Dave> do we need a different directive for each transport?

Historical I think.  Now is probably the right time to ditch it for
new interfaces, I agree.


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

Reply via email to