Dear all,













I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed
 by the IESG.  These comments were written primarily for the benefit of the operational area directors.




Document editors and WG chairs should treat these comments just like any other last call comments.













This I-D is almost ready for publication. Hopefully you can address my


comments below:





**** Technical ****





Meta:


In many cases, the recommendations being made are kind of intermixed


with the "background" information. If the text is not reorganized such


that the recommendations are more "separated" from the background info,


it would be great if, e.g. in each section, you provide a summary


(possibly in the form of a table) of all the recommendations being made.













* Section 6.1, page 21:










IoT device are assumed to have a software update













mechanism built-in and it will allow updates of low-level device













information, including credentials and configuration parameters.













This document does, however, not mandate a specific software /













firmware update protocol.








If you talk about software update mechanisms, you should probably make


some comments about the software update mechanism. e.g., it should


authenticate the software it downloads.








* Section 6.3, pages 24/25







Due to the use of Ephemeral Elliptic Curve







Diffie-Hellman (ECDHE) the recently introduced named Diffie-Hellman







groups [I-D.ietf-tls-negotiated-dl-dhe] are not applicable to this







profile.





I find this para graph hard to parse...








* Section 6.4.4:







All certificate elements listed in Table 1 are mandatory-to-implement







for client and servers claiming support for certificate-based







authentication. No other certificate elements are used by this







specification





Should there be any RFC2119 language here?








* Page 33:







Section 3.3 of [RFC7525] recommends to disable TLS/DTLS-level







compression due to attacks, such as CRIME.





Please provide a reference for CRIME -- RFC7525 doesn't seem to have


one, either.








* Page 35:







Since the upload happens on an irregular and unpredictable basis







and due to renumbering and Network Address Translation (NAT) the







DTLS handshake may need to be re-started (ideally using session







resumption, if possible).





Could you please elaborate why you mention "renumbering" as one of such


reasons?








**** Editorial/Nits ****


* Abstract:










via sensor or







controls actuators for use in home automation,





s/sensor/sensors/








* Section 1, pag 3:










UDP is mainly used to carry CoAP messages but other







transports can be utilized, such as SMS or even TCP.





Please add appropriate references.








* Section 1, pag 3:










While the main goal for this document is to protect CoAP messages







using DTLS 1.2 [RFC6347]





Add a comma right after the reference.








* Section 4.1.1.2, page 11:










this might be too limiting and additional functionality is needed, as







shown in Figure 4 and Figure 4,








* Section 4.2, page 13:







In this section, we assume a scenario where constrained devices run







TLS/ DTLS servers





Remove the extra space in "TLS/ DTLS".








* Section 4.2, page 15:







several other eco-system factor





s/factor/factors/








* Section 4.2, page 16:







to establish an shared







key





s/an/a/








* Section 4.2, page 17:







and various position papers submitted to that topic





s/to/on/?








* Section 4.2, page 17:







For a more fine-grained and







dynamic access control





Maybe rephrase as "For a finer-grained and more dynamic access control"?








* Section 4.2, page 17:







authenticate both endpoint





s/endpoint/endpoints/








* Section 4.2, page 18:







CoAP 2.04 Changed





s/

2.04/2.05

/?








* Section 6.1, page 20:







has to be know





s/know/known/








* Section 6.1, page 21:







Whatever process for generating







these initial device credential








* Section 6.1, page 21:







IoT device are assumed to have a software update







mechanism built-in and it will allow updates of low-level device







information, including credentials and configuration parameters.







This document does, however, not mandate a specific software /







firmware update protocol.





s/device/devices/








* Section 6.2, page 21:







The use of pre-shared secrets is one of the most basic techniques for







TLS/DTLS since it is both computational efficient and bandwidth







conserving





s/computational/computationally/?








* Section 6.3, page 24:










namely the server_certificate_type*’





Not sure if e.g. the asterisk was included in error.








* Page 27:







3. Certificates MUST NOT contains multiple names (e.g., more than







one dNSName field).





s/contains/contain/








* Page 33:







For cases where the server constrained





Missing "is".
















Have a good weekend.













Thank you,




Tina