Ballot for draft-ietf-lpwan-schc-over-sigfox
Yes
No Objection
Note: This ballot was opened for revision 18 and is now closed.
# Internet AD comments for {doc-rev} CC @ekline * I support Lars' DISCUSS topic. I think things pencil out okay, but the bulleted text format makes it nontrivial to see which bullets contribute to the header and which bullets are additional text pertaining to the mode described in the given section. ## Nits ### S3.1 * s/which then forward/which then forwards/, I suspect ### S3.2 * Suggest moving Figure 2 after its discussion paragraph. As currently placed, it mislead me into thinking that Figure 2 was an explanatory depiction of the L2 word size (which of course it's not =). ### S3.6.1.2 * s/can be increase when/can be increased when/ ### S3.6.1.5 * s/be comprised of less than/comprise fewer than/ or s/be comprised of less than/be composed of fewer than/
Thanks for a good shepherd writeup. I support Lars's DISCUSS position. Similarly, I would like to confirm that the naming of seven authors (exceeding the RFC Editor guidance of five) is necessary here. General: * Since this document is specifically about SCHC over Sigfox, shouldn't [sigfox-spec] be normative? Abstract: * You don't need to give the SCHC RFC number twice. Sections 3.5.1.3.1, 3.5.1.3.2, 3.5.1.4: * When might an implementer do something other than what this SHOULD says? Or ought this be a MUST? Section 3.5.2: * Same issue with the first SHOULD in this section. (The second one is fine.)
I support the DISCUSSes of Lars and Roman. I too was confused by some security aspects. One sigfox spec said it uses AES128 in CBC mode, while another said AES128 in CTR mode.
Thank you for addressing my DISCUSS feedback. ** This document’s stated goal per Section 1 is to “describe the recommended parameters, settings, and modes of operation to be used when SCHC is implemented over a Sigfox LPWAN. The cited reference for “Sigfox” is: [sigfox-spec] Sigfox, "Sigfox Radio Specifications", <https://build.sigfox.com/sigfox-device-radio- specifications>. Visiting that URL shows that the Sigfox Radio specification is versioned. There is a v1.6/March 2022, v1.5/Feb 2020 and v1.4/Nov 2019. Does this SCHC profile apply to all of these versions? And future versions that will pointed to from this URL? The text should be cleared on applicability.
Like Alvaro, and others, I support Lars' DISCUSS position. I'd also like to thank Bo for the OpsDir review ( https://datatracker.ietf.org/doc/review-ietf-lpwan-schc-over-sigfox-18-opsdir-lc-wu-2022-12-24/ ), and the authors for working well together to address these; I think that they improved the document. Thanks all!
Thanks for working on this specification. Thanks to Colin Perkins for the TSVART review. I am also supporting Lars's discuss. I regret on not getting explanations for more than 5 authors in this specification. I noticed that the introduction section says "This document describes the recommended parameters, settings, and modes of operation", I believe this specification, with the use of normative language "MUST" and likewise, is more than recommending. I would just remove the word "recommended" from the specific sentence.
[I support Roman's DISCUSS.]
Thanks for the work on this document. I to support both Roman and Lars's discussion points.
# GEN AD review of draft-ietf-lpwan-schc-over-sigfox-18 CC @larseggert ## Comments ### Section 3.6.1.3.2, paragraph 8 ``` * WINDOW_SIZE: 7 (with a maximum value of FCN=0b110) ``` 0b110 is of course six - so are zero windows disallowed and the encoding is off by one? (Same comment for other encoded window sizes in the document.) ### Too many authors The document has seven authors, which exceeds the recommended author limit. Has the sponsoring AD agreed that this is appropriate? ## Nits All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. ### Typos #### Section 3.6.1.3.1, paragraph 11 ``` - The maximum SCHC Packet size is of 340 bytes. - --- ``` #### Section 4.2, paragraph 19 ``` - |<-Compoud ACK,W=0,1, C=0--| Bitmap W=0:1010110 + |<-Compound ACK,W=0,1, C=0--| Bitmap W=0:1010110 + + ``` #### Section 4.2, paragraph 19 ``` - |<-Compoud ACK,W=1,C=1 ----| C=1 + |<-Compound ACK,W=1,C=1 ----| C=1 + + ``` ### "Authors' Addresses", paragraph 6 ``` Unabiz - Sigfox is now a Unabiz technology ``` Is that really the name of the organization? ### URLs These URLs in the document can probably be converted to HTTPS: * http://www.sigfox.com/ * http://www.ietf.org/internet-drafts/draft-ietf-lpwan-schc-compound-ack-09.txt ### Grammar/style #### Section 1, paragraph 4 ``` sing a provisioning protocol, by out of band means, or by pre-provisioning th ^^^^^^^^^^^ ``` Did you mean "out-of-band"? #### Section 3.3, paragraph 1 ``` ty. For this reason, when SCHC bi-directional services are used (e.g., Ack-on ^^^^^^^^^^^^^^ ``` This word is normally spelled as one. #### Section 3.3, paragraph 1 ``` All-1. The FCN is the tile index in an specific window. FCN and window numb ^^ ``` Use "a" instead of "an" if the following word doesn't start with a vowel sound, e.g. "a sentence", "a university". #### Section 3.6.1.3.1, paragraph 3 ``` six - so are zero windows disallowed and the encoding is off by one? (Same c ^^^^ ``` Use a comma before "and" if it connects two independent clauses (unless they are closely connected and short). #### Section 3.7.2.2, paragraph 5 ``` ll-1 message Fragment Header contains a RCS of 4 bits to complete the two-byt ^ ``` Use "an" instead of "a" if the following word starts with a vowel sound, e.g. "an article", "an hour". #### Section 3.7.2.3, paragraph 4 ``` er-Abort message header size is of 2 byte, with no padding bits. For the All- ^^^^ ``` Possible agreement error. The noun "byte" seems to be countable. #### Section 3.7.2.3, paragraph 4 ``` he Sender-Abort message MUST be of 2 byte (only header with no padding). This ^^^^ ``` Possible agreement error. The noun "byte" seems to be countable. #### Section 3.7.3.2, paragraph 2 ``` --------+ | 6 bits | 2 bits | 1 bit | 7 bit | 8 bit | 40 bits | next L2 W ^^^ ``` Possible agreement error. The noun "bit" seems to be countable. #### Section 3.7.3.3, paragraph 4 ``` er-Abort message header size is of 2 byte, with no padding bits. For the All- ^^^^ ``` Possible agreement error. The noun "byte" seems to be countable. #### Section 3.7.3.3, paragraph 5 ``` he Sender-Abort message MUST be of 2 byte (only header with no padding). This ^^^^ ``` Possible agreement error. The noun "byte" seems to be countable. ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT]. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments [IRT]: https://github.com/larseggert/ietf-reviewtool