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

Jon

On Mon, Oct 17, 2016 at 12:49 PM Otto Fowler <ottobackwa...@gmail.com>
wrote:

> 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.
>
> Best,
>
> Casey
>
-- 

Jon

Reply via email to