Re: [lp-wan] [Gen-art] Genart last call review of draft-ietf-lpwan-schc-over-sigfox-20

[Sergio Aguilar Romero <[e-mail]>]

Hello Elwyn,

Hope you are doing well.

Do you have further comments on this draft? 

We see Not Ready here:https://datatracker.ietf.org/doc/review-ietf-lpwan-schc-over-sigfox-20-genart-lc-davies-2023-01-04/ <https://datatracker.ietf.org/doc/review-ietf-lpwan-schc-over-sigfox-20-genart-lc-davies-2023-01-04/>

We are not sure if there is anything missing, as no further issues were raised.

Please, let us know if any action is required by our side.

Thanks,

Authors SCHC over Sigfox draft


> On Jan 24, 2023, at 12:06 AM, Sergio Aguilar Romero <[e-mail]> wrote:
> 
> 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 <[e-mail] <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>> 
>> Date: 21/01/2023 04:13 (GMT+00:00) 
>> To: Elwyn Davies <[e-mail] <mailto:[e-mail]>> 
>> Cc: [e-mail] <mailto:[e-mail]>, [e-mail] <mailto:[e-mail]>, [e-mail] <mailto:[e-mail]>, [e-mail] <mailto:[e-mail]>
>> 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 <[e-mail] <mailto:[e-mail]>> 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
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/lp-wan