Hi, I am an assigned INT directorate reviewer for draft-ietf-lpwan-schc-over-sigfox. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see https://datatracker.ietf.org/group/intdir/about/ . Based on my review, if I was on the IESG I would ballot this document as DISCUSS. I have the following DISCUSS level issue: - Security considerations (1) RFC8724 says, in Section 12, "As explained in Section 5, SCHC is expected to be implemented on top of LPWAN technologies, which are expected to implement security measures." (2) The text in this document describes the implemented security measures (i.e., radio protocol security, firewall) Based on this, except if I miss something and/or some text is added about security mechanisms provided within Sigfox LPWAN, IMHO, the following text should be added at the end of the section: "The previously described security mechanisms don't guarantee an E2E security between the Device SCHC C/D + F/R and the Network SCHC C/D + F/R: potential security threats described in [RFC8724] are applicable to the profile specified in this document." Maybe, to check with the Security Area review/ADs. The following are other issues I found with this document that SHOULD be corrected before publication: - 3.5. SCHC Rules "For this reason, it is recommended to keep the number of rules that are defined for a specific device to the minimum possible." I am puzzled with this sentence ... I don't know how to understand it: is it just an advice? is it a strong recommendation (e.g., RECOMMENDED)? If so, why not to set-up a maximum size? Maybe I missed something ... The following are minor issues (typos, misspelling, minor text improvements) with the document: - many locations s/Rule ID/RuleID - 3.1. Network Architecture "The Network SCHC C/D + F/R shares the same set of rules as the Dev SCHC C/D + F/R." s/the Dev/the Device - 4.1. Uplink No-ACK Examples "Last packet fragment is marked with the FCN = All-1 (1111)." "1111" in binary => "15" in decimal So, why "31" in the figures 31 and 32? Hope that helps. Merry Christmas! Best regards, JMC.