Reviewer: Elwyn Davies Review result: Not Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-lpwan-schc-over-sigfox-20 Reviewer: Elwyn Davies Review Date: 2023-01-04 IETF LC End Date: 2022-12-20 IESG Telechat date: 2023-01-05 Summary: Not ready. I notice that major edits have been done to this document since the IESG reviews raised some serious Discuss points. Aside from some serious points about the scope of the profile(s) in this review and whether there are multiple profiles involved, I think that the scope of the changes made deserve working group level review to ensure that the changes are technically accurate. I apologize for the late delivery of this review. I contracted Covid during the Last Call period and it has taken me some time to recover. Major issues: s1, para 4: It should be made explicit whether the document sets out a single set of parameters, etc., forming a single profile or whether variations are available so that more than one profile is possible. The word 'recommended' implies that there could be variations. If so how would an implementation/user know which profile was in use. It has been noted elsewhere in reviews that there are several versions of the Sigfox specification mentioned on the web page which gives access to the [sigfox-spec]. Does this profile apply to all versions of the specification? If not how does a device know which profile is used with which specification? This comment reflects inpart a Comment point raised by Roman Danyliw s3.2: This section states: "Messages sent from the Device to the Network are delivered by the Sigfox network (NGW) to the Network SCHC C/D + F/R through a callback/API with the following information: * Device ID * Message Sequence Number * Message Payload * Message Timestamp * Device Geolocation (optional) * Received Signal Strength Indicator (RSSI) (optional) * Device Temperature (optional) * Device Battery Voltage (optional)" As far as I can see, the [sigfox-spec] makes no mention of how or where the timestamp, geolocation information, device temperature and battery voltage are encoded and the format used. I take it Message Counter and Message Sequence are related in some way. How? Minor issues: Header: More than 5 authors are listed. This may now have been approved. s1: Before embarking on descriptions that refer to elements of the Sigfox network infrastructure, the document should tell the reader where s/he can find a definitive description of the elements. Referring to the relevant section of RFC 8376 would be useful, but a reference to a Sigfox document with an overview of the system would be very useful. The Sigfox Radio Specifications document is at too detailed a level to cover this requirement. [Aside: I found this document very hard work!] s2: The reader is also expected to be familiar with the Sigfox terminology. s3.2, para 1: "The uplink message size is 12 bytes in size.". Firstly: Uplink messages are variable in size depending on the requested payload. The payload can be up to 12 bytes. Secondly: This is the application level size. Six bytes of header are added in the link layer together with authentication if used. Further bytes are added in the physical layer. s8.2: I think RFC8376 is normative as the terminology used there is required knowledge. Nits/editorial comments: s1, para 1: s/on top of all/in conjunction with any of/ s1, para 2: s/a great level of/a considerable degree of/ s1, para 2: s/on top of/in conjunction with/ s1, para 3: 'worldwide network': This is advertising speak. Try 'a very wide area network' s1, para 3: s/recovery of lost messages/including recovery of lost messages/ s1, para 3: a/fragmentation/reassembly/allowing for fragmentation/reassembly of messages/ s1, para 4: s/This set of parameters are also known as/The set of parameters forms/ s3, Figure 1: For certainty, it would be useful to show the direction in which Uplink and Downlink messages travel. s3.2, para 1: s/space diversity/spatial diversity/ s3.3, last para: s/Downlink request flag/A Downlink request flag/ s3.3.1, para 2: s/which is signal by a specific the Fragment Compressed Number (FCN)/which is signalled by a specific value of the Fragment Compressed Number (FCN)/ -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
