#150 Consequences of rephrased R1164

[Martin]

Comment

old version of R1164 in draft 0

R1164: An SDC PARTICIPANT SHALL protect TCP communication by means of TLS.

new version of R1164 in draft 1 revision 0

R1164: An SDC PARTICIPANT SHALL protect access to BICEPS services by means of TLS-secured connections.

A core question arising from my side is the following: What does "access to a BICEPS service" mean?
a) covers request and response or subscription and notifications, respectively
b) only the request is covered

Implication of a): the UPD-based streaming is prohibited forever as TLS does not work over UDP
Implication of b): the responses/notifications can be transferred unsecured without violating the requirement

I think interpretation b) would be horrible. Consequently, only a) makes sense. Thus, do we really want to prohibit SOAP-over-UDP streaming?

[Martin]

On behalf of @schlich09:

Proposal: change TLS to secure channel.

TLS is still forced and there is an amendment ticket for secured soap-over-udp (see ticket [opensdc:ieee11073-20702:#4] ) or maybe DTLS for multicast might be standardized someday.

[David]

Changed requirement:

• An SDC PARTICIPANT SHALL protect access to BICEPS services by means of secured channels.

Added notes:

• Depending on the actual transport technology binding, a secure channels is implemented, e.g. by using a TLS-over-TCP connection.
• Unlike the IEEE 11073-10207, the implementation of this standard requires consistent protection of all BICEPS services.