Hello, We have published a new version.
Our comments below. Thanks for your review Author SCHC over Sigfox draft > On Jan 21, 2023, at 6:22 AM, elwynd <[email protected]> wrote: > > Hi, Sergio. > > Thanks. Your changes seem to cover the issues mentioned in the review. > > Regarding RFC 8376, personally I found reading RFC 8376 important for > understanding this draft. I suggest you discuss with your AD whether RFC > 8376 could be added to the list of Informational RFCs that are allowed to be > referenced normatively. > > The changes have introduced a number of nits into the document together with > a couple I missed previously: > > s1, para 1: RFC 8376 doesn't define anything! s/ defined/described/ Done. > > s1, para 3: s/brings/aims to provide/ Done > > s1, para 3: s/as described [RFC8376]/as described in [FC8376]/ Done > > s1, para 3: s/e.g. /e.g., / (all the the other 'e.g.' instnces are OK). Done > > s1, last para: s/supported on previous version of/is applicable to previous > versions of the/ Done > > s3.2, para after list: s/which is mandatory sent/which is mandatorially sent/ Done > > s3.2,, 2nd para after list: Something has gone wrong here... It ends > "Information on how the" Fixed. > > s3.3.1, para 2: s/FCN and window number combination allows to uniquely > identified/The combination of the FCN and the window number uniquely > dentifies/ > Done. > s3.3.1, para 2: s/indicating in case/indicating that/ Done. > > s4: The new Section 4 is missing all its paragraph break whte space > Not sure what this error is. > Cheers, > Elwyn > > > > Sent from my Galaxy > > > -------- Original message -------- > From: Sergio Aguilar Romero <[email protected]> > Date: 21/01/2023 04:13 (GMT+00:00) > To: Elwyn Davies <[email protected]> > Cc: [email protected], [email protected], > [email protected], [email protected] > Subject: Re: [Gen-art] Genart last call review of > draft-ietf-lpwan-schc-over-sigfox-20 > > Hello, > > Thanks for your review. > > We have published a new version of the draft. > > Please find our comments below. > > Best regards, > > Authors of the SCHC over Sigfox draft > >> On Jan 4, 2023, at 6:38 PM, Elwyn Davies via Datatracker <[email protected] >> <mailto:[email protected]>> wrote: >> >> 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 >> <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. > > It is a single profile which contains different F/R modes. A device may > implement one or more F/R modes depending on the application. > > We have added section 4 Fragmentation Rules Examples, providing an example on > how to configure the Rules as a single profile. > > >> The word 'recommended' >> implies that there could be variations. If so how would an >> implementation/user >> know which profile was in use. > > The word RECOMMENDED has been changed to MUST to removed ambiguities. It is > only RECOMMENDED to keep the RulesIDs to minimum, and it is stated what > happens if the recommendation is not follow. Moreover, we added section 4 > Fragmentation Rules Examples which explains an example on how to use the > Rules as a single profile. > > >> 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 >> > > The SCHC over Sigfox Profile is supported in previous version of the > specifications. We have added a sentence at the end of the introduction. > > Note that SCHC is carried as any other application payload from the Sigfox > layer perspective. > > >> 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. > > This information is encoded in the Confirmation Control message, which is > sent when the downlink message (if any) is received by the device. How this > information is encoded in this message is presented in section 5.2 of > [sigfox-spec]. > > Note that [sigfox-spec] is only about the radio protocol between a device and > the Sigfox infrastructure (aka. Base Stations). > Within this protocol are encoded the following information: > In Uplink message > Device ID > Msg Sequence Number > Msg Payload > In Control messages (optional Keepalive or mandatory control message to > acknowledge a Downlink) the payload includes: > Temperature > Battery voltage > > Upon reception of a message from the radio interface, a Sigfox Base Station > computes metadata associated to the received message, that includes: > RSSI > Reception timestamp > > Message data and metadata are then pushed by receiving Base Station(s) to the > Sigfox Cloud that processes them, and, e.g.: > aggregates RSSI information associated to a message according to whether or > not multiple Base Stations did forward the same message, > eventually computes a geolocation for the message (thus adding the device > location property) to the message. > > In the end, the Sigfox Cloud delivers a callback that may contain the whole > message properties (concatenation of elements transported through the radio > interface, but also metadata computed by Base Station(s) and Cloud). If the > SCHC Receiver is fed up with such a callback, then it can receive all that > message properties (not all of them being useful/mandatory). > > >> I take it Message Counter and Message Sequence are >> related in some way. How? > > Message Counter / Sequence Number are clearly related : “Message Counter” is > the name of the field used on the radio interface to encode the Message > Sequence Number. > > >> >> 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!] > > We added a reference to RFC 8376. Also we added a reference to the complete > Sigfox documentation. > > >> >> s2: The reader is also expected to be familiar with the Sigfox terminology. >> > > Added a reference at the end of the section. > > >> 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. >> > > We modified the sentence as follows: The uplink message application payload > size can be up to 12 bytes. > > >> s8.2: I think RFC8376 is normative as the terminology used there is required >> knowledge. >> > > First we moved RFC8376 to normative. > > When checking idnits, we got this error: > ** Downref: Normative reference to an Informational RFC: RFC 8376 > Therefore, we are not sure if RFC8376 can be normative. We move it to > informative to remove this error. > >> Nits/editorial comments: >> >> s1, para 1: s/on top of all/in conjunction with any of/ >> > Done. > >> s1, para 2: s/a great level of/a considerable degree of/ >> > > Done. > >> s1, para 2: s/on top of/in conjunction with/ >> > > Done. > >> s1, para 3: 'worldwide network': This is advertising speak. Try 'a very >> wide >> area network' >> > > Done. > >> s1, para 3: s/recovery of lost messages/including recovery of lost messages/ >> > > Done. > >> s1, para 3: a/fragmentation/reassembly/allowing for fragmentation/reassembly >> of >> messages/ > > Done. > >> >> s1, para 4: s/This set of parameters are also known as/The set of parameters >> forms/ >> > Done. > >> s3, Figure 1: For certainty, it would be useful to show the direction in >> which >> Uplink and Downlink messages travel. >> > > We added arrows indicating uplink and downlink directions. > > >> s3.2, para 1: s/space diversity/spatial diversity/ > > Done. > >> >> s3.3, last para: s/Downlink request flag/A Downlink request flag/ > > Done. > > >> >> 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)/ >> > Done. >> > >> > > _______________________________________________ > lp-wan mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lp-wan
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
