Indeed: merci Jean-Michel Based on Sergio's quick reaction, I have placed this I-D on the agenda of the next IESG telechat. Regards -éric On 20/12/2022, 23:47, "lp-wan on behalf of Sergio Aguilar Romero" <lp-wan-bounces@xxxxxxxx <mailto:lp-wan-bounces@xxxxxxxx> on behalf of sergio.aguilar.romero@xxxxxxx <mailto:sergio.aguilar.romero@xxxxxxx>> wrote: Hello, Thanks for your review. We have published a new version (-18) of the draft. Please find our responses to your comments below. Please let us know anything. Cheers, Authors of the SCHC over Sigfox draft > On Dec 19, 2022, at 10:41 AM, Jean-Michel Combes via Datatracker <noreply@xxxxxxxx <mailto:noreply@xxxxxxxx>> wrote: > > Reviewer: Jean-Michel Combes > Review result: On the Right Track > > 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/ <https://datatracker.ietf.org/group/intdir/about/> > <https://datatracker.ietf.org/group/intdir/about/> <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. > We have added the text at the end of section 12. > 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 > ... > We have modified the “recommended” to “RECOMMENDED” and added when not following is acceptable. > 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? > Thanks, we have fixed the minor issues and fixed a couple more. > Hope that helps. > > Merry Christmas! > > Best regards, > > JMC. > > > _______________________________________________ lp-wan mailing list lp-wan@xxxxxxxx <mailto:lp-wan@xxxxxxxx> https://www.ietf.org/mailman/listinfo/lp-wan <https://www.ietf.org/mailman/listinfo/lp-wan> -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
