Aldrin,
Another point for consideration is the scope of this information. Core NiFi flows and those components are very much about data whereas those IPs may not necessarily be data for consumption, per se, but context that governs how the data flow is operating. In this case, there is a different plane of information exchange and may deserve a discrete logical channel to make this available. Not sure what you mean by governing the context but maybe I should explain myself a bit better: from a NiFi point of view the data (IPs) are still data to be consumed, the only difference in this case is that the data is very small and the final delivery mechanism is a Unix command (instead of a PutElasticSearch processor for example) The fact we update firewall ACL from the sensors themselves is relatively irrelevant to the overall flow. As an example: The IPs could be sent from sensors m1 and m2 to core and then to a completely independent set of sensors mm1-mmN where the same data is simply saved into disk (instead of running ExecuteScript). I may be wrong but I was under the impression that from a minifi point of view, what we do with the data at the end of the data flow is not a matter of relevance, if so, then at least in this case, this would still count as "data in movement scenario" that we try to cover. Would you agree?
