Re: [lp-wan] I-D Action: draft-ietf-lpwan-schc-over-sigfox-10.txt

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

Hello Ana, 

Thanks for your review and comments.

We have a new version of the draft. In this case, the text version can be found here:

https://github.com/saguilarDevel/schc-sigfox/blob/test_v6/docs/draft-ieft-lpwan-schc-over-sigfox-09/draft-ietf-lpwan-schc-over-sigfox-11.txt

The diff from version 10 can be found here: 

https://github.com/saguilarDevel/schc-sigfox/commit/4cb5d2b863b3bd02d5165165befe48c4e86f4934

Also please find the responses to the review below.

Please let us know if there is any further comment. 

Best regards,

SCHC over Sigfox Authors



> On Jun 17, 2022, at 4:11 PM, Ana Minaburo <[e-mail]> wrote:
> 
> Hello Sergio,
> 
> Thanks for this new version, I was just finishing my review over the previous one.
> I've seen they are relevant for this new version too.
> 
> See below,
> Ana
> 
> - Abstract and Introduction say the same thing, you may change one or the other.
> 

Done.

> - Terminology.
> It will be more helpful to add the terms you use as: 
>    *  RG does not exist in RFC8724 and the RGW (Radio Gateway) is mention in section architecture but not terminology.

We changed RG for RGW.

>    * UL and DL, RFC8724 call them Uplink and Downlink.

We modify UL to Uplink and DL to Downlink, except in Figures were DL is used to save space.

>    
> - Section 3. SCHC over Sigfox
> In the first paragraph you talk about the predictability of the data flows. Can you explain better which information is predictable? and how do you manage the flows? 
> 

We have remove “the predictability of data flows” to “previous knowledge of traffic flows” as explained in RFC8724 in the introductions. 


> - Section 3.1 Network Architecture.
> In the figure 1, explain what is the meaning of '$' and '~' and the '.' in the other side? 

We have added to Figure 1 a Legend explaining the symbols.

> The Sigfox BS does not talks SCHC, how it manage to forward packets?

Sigfox BS forwards the payload sent by the Sigfox device to the Sigfox Network (NGW), as part of the Sigfox protocol. This is actually an internal functionality of the Sigfox Network, as all messages from all devices are sent from the Sigfox BS to the Sigfox Network, independently of the content of the packets or their payload.


>  
>   * You talk about the device sending application flows... but RFC8724 talks about compression and fragmenting packets and not flows, so how this affects the behaviour.

We have changed flow to packets as in RFC8724, which are compressed and/or fragmented.

>   * Can you explain what is the associated metadata used in SCHC for Sigfox?

The metadata used in SCHC over Sigfox, as our understanding of metadata, may be referenced to the information that is interchanged between Sigfox Network and Network SCHC. This information is presented in section 3.2 Uplink.

>   * How are you managing the broadcast to the Application Servers?

This is part of the Sigfox Protocol, and it is out of the scope of the SCHC over Sigfox profile. The Sigfox Network is the one in charge of sending the messages to the application servers via the Sigfox Callbacks or the Sigfox API. The application should clearly state how it manages the data from/to the Sigfox network.

> 
> -Section 3.2 Uplink put sigles (UL)

Done.

>  
> -Section 3.3 Downlink
>  * RFC8724 gives an overview of this transmission in Appendix F. As you are using it, please give a better explanation of the problem.

We have already added information regarding Appendix F in section 3.6.2.

Moreover, we have text to further clarify section 3.3.

>  * You talk about a request flag, Could you explain where in the SCHC header these flag takes place?

The downlink request flag is part of the Sigfox Headers and how the Sigfox protocol operates, and is not part of the SCHC Headers, nor SCHC protocol. We have added the phrase: "The downlink request flag is part of the Sigfox protocol headers."

>  * How do the device or the App know that the DL is triggered?

The Sigfox Network communicates with the App via API calls. This communication uses a JSON file which contains the downlink request flag status. This way the App knows that the Sigfox Device is waiting for a DL message.

We have text related at the end of this section.

>  
> -Section 3.5 SCHC Rules
>   * You say keep the number of rules to the minimum possible. But as you are not using DTag and you have 3 bits for RuleID. Does this length (3bits) is enough to have multiple flows?

A three bit Rule ID field allows us to interleave at most eight SCHC transmissions for the same device (depending on the configuration) if the application clearly states how the Rule IDs should be selected.

> 
> - Section3.6.1.1
>  * You are missing Inactivity Timer

We have added the Inactivity Timer.

>  * RCS is not used !  Are you expecting a reliable connection with zero errors?
>    In this case are you expecting to send the Checksum?
>    Section 8.2.3 of RFC 8724 says MUST be defined in profiles

Sigfox provides a CRC check at the L2 layer for each SCHC Fragment. As each SCHC Fragment is only delivered to the Network SCHC after the Sigfox CRC is correct, the complete SCHC Packet integrity is considered to be correct.

This is explained in section 3.6.1.3.

> 
> - Section 3.6.1.2
>   * Timer are Application dependent, but we are expecting to have the complete Annex F defined in these documents, could you give some application values?

We have added recommend values to all modes.

>   * RCS to 3 bits, how much error your channel has? Experience has show that 3-bit RCS has a double-edge sword.

This is to carry the number of tiles of the last window. We are only using the number of tiles of last window, as the integrity of each SCHC Fragment is guarantee by the Sigfox protocol. This is explained in section 3.6.1.3.

> 
> - Sections 3.6.1.3 and 3.6.1.4
>   * Timers are missing

We have added Timer to all sections with the recommended values.

> 
> 
> -DTag not used
>   * As we have discussed, you decided to apply the possibility to add more Rules in order to keep DTag=0. And in this situation how are you sure the Rule is free to be used? How many Rules can you really add since you are defining RuleId with 3 bits length?

it is the job of the application to clearly define how a Rule ID should be selected and when it can assume that a Rule ID is free (this may be after completing or aborting a SCHC transmission, for example).

> 
> -Section 3.6.2 
>  * How do you request a downlink? Please explain

You request a downlink using a the downlink request flag of the Sigfox protocol as explained in section 3.3.

>  * Give timer values for some applications

We have provided some recommended timer values.

> 
> -Section 3.7.1.1 
>  * What is a Regular or irregular SCHC Fragment?

Regular SCHC fragment as defined in RFC8724 and adapted for this profile.

>  
> - Section 3.7.1.3 - 3.7.2.5
>  * What is the meaning of the  apostrophe in the figures?

The b’ is used to indicate the use of bits values after the ‘. This is used to be similar as in RFC9011.


> 
> 
> On Fri, Jun 17, 2022 at 2:56 PM Sergio Aguilar Romero <[e-mail] <mailto:[e-mail]>> wrote:
> Hello everyone, chairs,
> 
> We have uploaded the new version of the SCHC over Sigfox draft.
> 
> We have added previous comments from the Shepard review and reorganize the fragmentation modes into two section.
> 
> We believe the document is ready for WG Last Call.
> 
> Best regards,
> 
> Authors SCHC over Sigfox draft  
> 
> > On Jun 17, 2022, at 2:51 PM, [e-mail] <mailto:[e-mail]> wrote:
> > 
> > 
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > This draft is a work item of the IPv6 over Low Power Wide-Area Networks WG of the IETF.
> > 
> >        Title           : SCHC over Sigfox LPWAN
> >        Authors         : Juan Carlos Zúñiga
> >                          Carles Gomez
> >                          Sergio Aguilar
> >                          Laurent Toutain
> >                          Sandra Cespedes
> >                          Diego Wistuba
> >                          Julien Boite
> >       Filename        : draft-ietf-lpwan-schc-over-sigfox-10.txt
> >       Pages           : 35
> >       Date            : 2022-06-17
> > 
> > Abstract:
> >   The Generic Framework for Static Context Header Compression and
> >   Fragmentation (SCHC) specification describes two mechanisms: i) an
> >   application header compression scheme, and ii) a frame fragmentation
> >   and loss recovery functionality.  SCHC offers a great level of
> >   flexibility that can be tailored for different Low Power Wide Area
> >   Network (LPWAN) technologies.
> > 
> >   The present document provides the optimal parameters and modes of
> >   operation when SCHC is implemented over a Sigfox LPWAN.  This set of
> >   parameters are also known as a "SCHC over Sigfox profile."
> > 
> > 
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-lpwan-schc-over-sigfox/ <https://datatracker.ietf.org/doc/draft-ietf-lpwan-schc-over-sigfox/>
> > 
> > There is also an htmlized version available at:
> > https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-schc-over-sigfox-10 <https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-schc-over-sigfox-10>
> > 
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-lpwan-schc-over-sigfox-10 <https://www.ietf.org/rfcdiff?url2=draft-ietf-lpwan-schc-over-sigfox-10>
> > 
> > 
> > Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
> > 
> > 
> > _______________________________________________
> > lp-wan mailing list
> > [e-mail] <mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/lp-wan <https://www.ietf.org/mailman/listinfo/lp-wan>
> 
> _______________________________________________
> lp-wan mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/lp-wan <https://www.ietf.org/mailman/listinfo/lp-wan>