Rainer Gerhards

I should stress that I am really after the actual samples rather than theoretical thoughts. I know that there are different schools of thinking and I would like to see...

the current discussion around different date formats might show a valid argument pro regex support. Can't provide more details at this moment, but thought I at least add the information...

We should probably do this with a custom type instead of a generic parser. It's easy and more aligned with the v2 philosophy (now that things have grown up :-).

For performance reasons as well as to prevent to broad matches, we need a new parser in any case.

I'd say we shold make this an option. With the v2 config, we will have much easier ways to specify options, e.g. %field:hexstring{"digits":12, "delimiter": ":", "keepDelimiter": true}%

Note: when fixed, check the testbench tests for v2-iptables parser. This may also be used during fixing.

Note: this will probably be removed in v2 in any case. So it's questionable if it is worth spending time on it.

This can be done with a custom type once we have a more generic integer parser. so do not code up a C parser.

ah, ok, I see where you are coming from. So far, I was of the thougt that "integer type, min 0, max 191" would suffice, but the idea of decoding...

This is actually a bug during rulebase processing. The "alternative" parser is checked at a location, where it's use as given here is not properly detected. It takes "a little...