Closed csosto-pk closed 5 years ago
Remove normative language from
To alleviate this situation, an EST-coaps DTLS connection MAY remain open for sequential EST transactions.
And elsewhere about persistent connections and TA database.
Also need to update the Parameters section to not repeat normative language from RFC7252 and to not mess with the default Congestion parameter NSTART.
I think that in the case of EST, where we are in fact tying the security layer in with the application, it is entirely appropriate for EST-COAP to say how both EST, CoAP and DTLS are used. BCP146/RFC5406 encourages application writers to be specific in how security is applied. So it is not just appropriate to mandate a particular way to use DTLS, it is required by modern IETF security process.
We partially addressed these comments.
An application layered on top of CoAP shouldn't mandate CoAP congestion control parameters.
We updated the text to not use normative language that touches on RFC7252 . The text now reads
NSTART: A parameter that controls the number of simultaneous outstanding interactions that a client maintains to a given server. An EST-coaps client is not expected to interact with more than one servers at the same time, which is the default NSTART value defined in
.
About
To alleviate this situation, an EST-coaps DTLS connection MAY remain open for sequential EST transactions.
EST-coaps transactions affect the certificates used to authenticate DTLS connections which includes the DTLS connection established for EST-coaps. Thus we need to address security concerns introduced by EST-coaps transactions like cacerts. This is addressed in the Security Considerations section. BCP146/RFC5406 encourages application writers to be specific in how security is applied, so we are following modern IETF security process.
Klaus had some comments about DTLS being affected by the application protocol.
He pointed out text
and explained that
He also talked about the parameters section saying