[c-nsp] XR6 process conflicts

Saku Ytti saku at ytti.fi
Tue Sep 15 05:14:48 EDT 2020


On Tue, 15 Sep 2020 at 11:22, tim at pelican.org <tim at pelican.org> wrote:

> I'd usually want to err on the side of having more data and putting appropriate filtering between the data and the person viewing, rather than NOT having data it later turns out would be useful.

Yes tons of (bad) input isn't a problem. Where we make mistakes is
generating a lot of inactionable or redundant output for human
consumption. It is much better to omit sending alerts about real
problems to humans than to generate a lot of inactionable alerts and
messages for human consumption.
We will quickly learn to ignore input if it's rarely actionable and
mistakes due to humans ignoring legit alerts will be far more common
than legit alerts not being generated. Of course oftentimes this is a
game of where the blame falls, if you generate a lot of useless alerts
but never miss alerts, you did your job and the problem is on the
consumption side for not reacting.

So rather fix situations where you discover them where you suppress
legit alerts than spew out trash you don't know for a fact to be
actionable. You will have better overall results but of course you
will have to carry the blame of managers asking 'why didn't we get
alert'.

-- 
  ++ytti


More information about the cisco-nsp mailing list