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/s1, para 3: s/brings/aims to
provide/s1, para 3: s/as described [RFC8376]/as described in [FC8376]/s1, para
3: s/e.g. /e.g., / (all the the other 'e.g.' instnces are OK).s1, last para:
s/supported on previous version of/is applicable to previous versions of
the/s3.2, para after list: s/which is mandatory sent/which is mandatorially
sent/s3.2,, 2nd para after list: Something has gone wrong here... It ends
"Information on how the"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/s3.3.1, para 2: s/indicating in case/indicating that/s4: The
new Section 4 is missing all its paragraph break whte spaceCheers,ElwynSent
from my Galaxy
-------- Original message --------From: Sergio Aguilar Romero
<sergio.aguilar.rom...@upc.edu> Date: 21/01/2023 04:13 (GMT+00:00) To: Elwyn
Davies <elw...@dial.pipex.com> Cc: gen-art@ietf.org,
draft-ietf-lpwan-schc-over-sigfox....@ietf.org, last-c...@ietf.org,
lp-...@ietf.org 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 draftOn Jan 4, 2023, at 6:38 PM, Elwyn
Davies via Datatracker <nore...@ietf.org> wrote:Reviewer: Elwyn DaviesReview
result: Not ReadyI am the assigned Gen-ART reviewer for this draft. The General
AreaReview Team (Gen-ART) reviews all IETF documents being processedby the IESG
for the IETF Chair. Please treat these comments justlike 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-20Reviewer: Elwyn DaviesReview Date:
2023-01-04IETF LC End Date: 2022-12-20IESG Telechat date: 2023-01-05Summary:Not
ready. I notice that major edits have been done to this document since theIESG
reviews raised some serious Discuss points. Aside from some seriouspoints
about the scope of the profile(s) in this review and whether there aremultiple
profiles involved, I think that the scope of the changes made deserveworking
group level review to ensure that the changes are technically accurate.I
apologize for the late delivery of this review. I contracted Covid duringthe
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 singleset of
parameters, etc., forming a single profile or whether variations areavailable
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/userknow 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 thatthere are several versions
of the Sigfox specification mentioned on the webpage which gives access to the
[sigfox-spec]. Does this profile apply to allversions of the specification?
If not how does a device know which profile isused with which specification?
This comment reflects inpart a Comment pointraised by Roman DanyliwThe 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 thetimestamp, geolocation information, device temperature and battery
voltage areencoded 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
messageDevice IDMsg Sequence NumberMsg PayloadIn Control messages (optional
Keepalive or mandatory control message to acknowledge a Downlink) the payload
includes:TemperatureBattery voltage Upon reception of a message from the radio
interface, a Sigfox Base Station computes metadata associated to the received
message, that includes:RSSIReception 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
arerelated 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 Sigfoxnetwork infrastructure, the
document should tell the reader where s/he can finda definitive description of
the elements. Referring to the relevant section ofRFC 8376 would be useful,
but a reference to a Sigfox document with anoverview of the system would be
very useful. The Sigfox Radio Specificationsdocument is at too detailed a
level to cover this requirement. [Aside: I foundthis 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:
Uplinkmessages are variable in size depending on the requested payload. The
payloadcan be up to 12 bytes. Secondly: This is the application level size.
Six bytesof 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
requiredknowledge.First we moved RFC8376 to normative. When checking idnits, we
got this error: ** Downref: Normative reference to an Informational RFC: RFC
8376Therefore, 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 widearea 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 ofmessages/Done.s1, para 4: s/This set of
parameters are also known as/The set of parametersforms/Done.s3, Figure 1: For
certainty, it would be useful to show the direction in whichUplink 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.
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
