[Bro-Dev] changing Notice::policy mechanism

Vern Paxson vern at icir.org
Mon Nov 5 08:41:10 PST 2012

> I'm not completely tied to the "policy" keyword, but does it seem
> unreasonable to have something like this immediately executed event that
> we've been discussing?

Yeah, it seems somewhat strange and confusing.

If we back up, it seems to me there are several things the framework
tries to achieve.

	(1) Associate predicates with different possible cases.  This
	    is the "n$note == Whatever" clause that's currently included
	    in basically every policy element.

	(2) A predicate that applies logic when that case holds to yield
	    a classification decision.

	(3) Priorities to decide which predicate "wins" when multiple ones
	    of them match the case.

	(4) The ability for an early winner to short-circuit processing by
	    others that match the case, either for efficiency or to prevent
	    their side-effects.

What I wonder about is having a starting point of dealing with (1) differently.
Conceptually, one would like to say:

	switch n$note {

	case Notice::Sneakiness:
		if ( pred1() ) ...
		if ( pred2() ) ...


but the problem is that we want refinement of the code inside each
case, without having to edit the overall code block.

I know that languages going as far back as CLOS had mechanisms for
doing this sort of refinement.  Not being a CLOS hacker, this is just
from ancient memory, but I believe the CLOS equivalent for what we
want would be:

	function policy_action(n: Notice::Info &case n$note==Notice::Sneakiness,
				other_arguments_here ...)

That seems like too much verbiage.  But it has me wondering whether there
might be some sort of prioritized case construct that works better than
"match ... using".  Ideally this would be a language construct that nicely
applies in other switch-like contexts, too.


More information about the bro-dev mailing list