I vote for #1. So much of security is built on integrity, and so I would
prefer a complete failure in order to emphasize the issue and hopefully
obtain a faster resolution. Along those lines, it would also be the duty
of Metron to make sure these errors are very apparent and the consequences
are obvious. I can't tell you how many times I've seen an incident be
prolonged or incorrectly resolved due to inaccurate or incomplete
On Mon, Oct 17, 2016 at 12:49 PM Otto Fowler <ottobackwa...@gmail.com>
> 1 for me.
> The Stellar transformations are part of creating a compete document (
> along with the parsing ) that will be passed to other topologies for
> further processing. Failure on either side should be an error. This avoids
> inconsistency downstream and other problems. If Metron were to allow this,
> then it should be a configurable ‘policy’, which defaulted to case 1.
> On October 17, 2016 at 12:15:54, Casey Stella (ceste...@gmail.com) wrote:
> Hi Everyone,
> When we have a Field Transformation which is in error in the parser, the
> current behavior is to send the message in question to the error queue. I
> wanted to have a discussion around what the correct state of affairs for
> this is.
> The way I see it, we have one of two options:
> 1. Send the message to the error queue as it's consistent with what
> would happen if a parser failed
> 2. Skip the failed transformation
> Normally I would be in favor of 1 (which is current behavior), but we DO
> have some information that we could pass on since the parser did succeed
> even though the field transformations did not.
> I wanted to open this up for discussion and see if I could get a good
> direction from the community.