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

2023-01-21 Thread elwynd 
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 
 Date: 21/01/2023  04:13  (GMT+00:00) To: Elwyn 
Davies  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  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, geolo

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

2023-01-20 Thread Sergio Aguilar Romero 
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  
> 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
> 
> .
> 
> 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

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

2023-01-06 Thread Eric Vyncke (evyncke) 
Hello Elwyn,

Let me chime in as the responsible AD for the LPWAN WG.

First, "better late than never" ;-) I.e., thank you very much for your review. 
All reviews always help to improve the quality of the IETF work.

About the review major issues, I do not intend to request another WG Last Call 
as the changes in the document have not heavily changed the technical aspects. 
Please also note that the larger than 5 authors count is explained in the 
shepherd's write-up and has been approved by me: there is a Ph.D. student and 
his associated academia, which usually leads to a more lenient approach to the 
authors count (else it is indeed a valid observation).

Also, the LPWAN charter contains “The Working Group will focus on enabling IPv6 
connectivity over the following selection of Low-Power Wide-Area technologies: 
SIGFOX, LoRa, WI-SUN and NB-IOT. These technologies will be used as the 
baseline technologies for future work.”. I.e., it is not the role of the IETF 
to review the Sigfox specifications in details (about the points about 
geolocation and other fields), but is limited to specify SCHC over Sigfox.

I will let the authors reply to your other points as they look valid. Thanks 
again.

Regards

-éric


On 05/01/2023, 01:38, "Elwyn Davies via Datatracker" mailto:nore...@ietf.org>> 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


 
.


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

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

2023-01-04 Thread Elwyn Davies via Datatracker 
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

.

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)/



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art