Why restriction on reading messages? It is not like an external observer is not going to be able to see the lights go on or off.
I am not sure what you mean by synchronous manner. Does this mean that the light needs to change state between the command and the response message? (As opposed to an asynchronous manner.) Or do you mean in a synchronized manner where everything happens at a given time relative to the command (which could be all at the same time). The solution in section 4 does not seem to meet the following requirement "Only authorized members of the application group must be able to read and process messages." The statement is made that AT-R tokens with references are more efficient from a bandwidth point of view. Does this mean that there is going to be a recommendation that these be provided prior to the first command so that all n devices dereferencing the pointer will not kill the bandwidth? This document needs to have a solution for dealing with nonce space allocation for the cases where more than one sender is going be able to use the same key. This is going to be part of the problems with replay detection as well as security considerations. Should the algorithms be using high water detection of sequence numbers rather than the case of not yet used? Or is that an application specific type thing? How does section 5.2 Token Verification reconcile with the idea of doing references in AT-R tokens? In section 6.3, if a device has multiple security domains, why could they not come from multiple KDCs? The term low latency needs to be much more clearly defined about what it means in this context. In a manufacturing facility, I might have a tighter latency requirement for communicating commands to valves that I would on dealing with lights that might take a while to come on anyway. Does that mean that you feel that this would be an ideal solution for such an environment? The same thing might easily be said for emergency alarms. I want all of them to come on and come on fast in the event of an emergency. A better description of what is meant by low-latency is clearly needed. I do not think that the current security requirements is sufficiently strident to reflect both the threat of breakage, cross-breakage and restrictions on where it should be used to pass muster. Jim _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
