[Coin] A few comments on draft-kunze-coin-industrial-use-cases-00.txt

["David R. Oran" <[e-mail]>]

This is a useful first start at documenting an important use case, so 
thanks for taking the time to write and submit the draft. I think it 
would be a good document to adopt once the RG is fully formed and 
operational.

I have a few comments:

1. On security, you say:
“ Another aspect is that business data leaving the premise and control
    of the company further comes with security concerns, as sensitive
    information or valuable business secrets might be contained in it.
    Typical security measures such as encrypting the data makes in-
    network computing techniques hardly applicable as they typically 
work
    on unencrypted data.  Adding security to in-network computing
    approaches, either by adding functionality for handling encrypted
    data or devising general security measures, is thus a very promising
    field for research.”

	While it is true that data flowing over external links and ISPs 
represents a security hazard, the converse implication that data staying 
in the enterprise, or even confined to the factory floor is safe from 
confidentiality or modification threats and hence needs less protection 
is not. One would hope that by adopting in-network computing as a 
paradigm, this would be seen as an opportunity to actually *upgrade* the 
security of industrial automation by dealing with the multi-party nature 
of the communication paradigms and in fact allowing data to be:
		- encrypted over all links
		- authenticated by any element possessing the keys to read it
		- provenance tracked through any device that has the necessary keys 
and permissions to modify it

	Therefore, from a security standpoint, treating a network element like 
a switch or router that either observes of modifies data differently 
from a computational host that does so would be a mistake in my view.

2. On the need for sensor traffic filters, a bit more detail on the 
question of “how to design” would be helpful, since different design 
requirements lead to quite different capability requirements on the 
elements doing it. A few initial thoughts:
	- fuzzing thresholds with some soft state on values can suppress 
readings that haven’t changed enough to matter
	- If there are redundant sensors giving similar readings such that 
you’d like to suppress the redundancy, you need to either send some 
periodic suppression stats computed by the filter, or annotate the 
non-suppressed sensor data with either some count of the samples 
suppressed, or some error bars computed from the set of received values.
	- we learned quit painfully for event logs (which are similar 
time-series data to sensor data) that you need to periodically send 
something so an upstream computation element can tell the difference 
among potential data loss, the lack of new readings, or a broken data 
source.

3. The point about safety is well taken. I’m not sure it’s necessary 
to say much more about this, however from personal experience I’d like 
to emphasize that you can’t achieve the requisite level of safety only 
by measures “inside” the system; especially not by relying on the 
computational elements alone. For example in the case of industrial 
robots, the environment needs human-visible safety boundaries that are 
not computed from the operation of the robot, but in fact mark the 
absolute physical extent of the robot’s reach. These are either 
painted on the floor, by placing the robot inside a physical bounding 
box that cannot be opened by the software, or some other 
outside-the-system mechanism. It may be that in-network computing 
doesn’t affect this at all, but it’s worth a conversation to see if 
there are new hazards introduced. Therefore when you ask “How can the 
software give guaranteed safety over best-effort networks?” the answer 
for me is clearly “no” and in fact is “no” for **any** kind of 
network.

4. I might split up the security discussion into two pieces, or more it 
to the “security Considerations” section rather than leaving it 
“N/A”, which is a red flag for much of the community.

Thanks,
DaveO