[lp-wan] Shepherd :review of draft-ietf-lpwan-schc-compound-ack-03.txt

Dear authors:

Please find my shepherd review beliow:

-------------

I believe this document updates RFC 8724 and that should be indicated in the RFC tag

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" updates="8724" submissionType="IETF" xml:lang="en" version="3" ...>

---------------

Abstract / Intro: I believe this only applies to ack-on-error but that is not said in abstract/intro. 

---------------

"
   The window numbered 00, if present in the SCHC Compound ACK, MUST be
   placed between the Rule ID and the C bit to avoid confusion with
   padding bits.
"

I'm not 100% sure about what you mean here. If the window is not fully received, C is 0. 

So I read that it cannot be the last window ack, to ensure that one bit is set later in the W. 

Could you elaborate?

---------------

"
   *  if the last of these SCHC Fragment messages reported missing is
      not an All-1 SCHC Fragment, then the fragment sender MAY either,
      send in addition a SCHC ACK REQ with the W field corresponding to
      the last window, continue the transmission of the remaining
      fragments to be transmitted, or repeat the All-1 fragment to
      confirm that all fragments have been correctly received.
"

Why do you copy that sentence in full?
It seems unchanged, correct? 
But the reader has to check word by word that it is so.

---------------
"
   NEW TEXT: On receiving an All-0 SCHC Fragment:

   *  if the receiver knows of any windows with missing tiles for the
      packet being reassembled (and if network conditions are known to
      be conducive), it MAY return a SCHC Compound ACK for the missing
      fragments, starting from the lowest-numbered window.
"

This is not strictly speaking a replacement but really a new behavior that is intermediate between ack-always and ack-on-error.
e.g., one could use it with 1 window per ack as a ack-when-feel-like-to.
So I believe it should be flagged as a new behavior, before the old/new. 
I'd like to raise the question at the next interim, whether that this addition is clear to all.

---------------

Otherwise all good!

Pascal

> -----Original Message-----
> From: lp-wan <lp-wan-bounces@ietf.org> On Behalf Of Juan Carlos Zuniga
> Sent: jeudi 10 février 2022 1:07
> To: lp-wan@ietf.org
> Subject: [lp-wan] FW: I-D Action: draft-ietf-lpwan-schc-compound-ack-
> 03.txt
> 
> Dear Pascal, Alex,
> 
> As per the Actions from the meeting, we have posted a new revision of the
> document addressing the last comments.
> 
> We (authors) believe this version is ready.
> 
> Best,
> 
> Juan Carlos et al.
> 
> -----Original Message-----
> From: lp-wan <lp-wan-bounces@ietf.org> On Behalf Of internet-
> drafts@ietf.org
> Sent: February 9, 2022 7:03 PM
> To: i-d-announce@ietf.org
> Cc: lp-wan@ietf.org
> Subject: [lp-wan] I-D Action: draft-ietf-lpwan-schc-compound-ack-03.txt
> 
> CAUTION: EXTERNAL EMAIL. Do not click links or open unless you recognize
> the sender and know the content is safe.
> 
> 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 Compound ACK
>         Authors         : Juan Carlos Zúñiga
>                           Carles Gomez
>                           Sergio Aguilar
>                           Laurent Toutain
>                           Sandra Céspedes
>                           Diego Wistuba
>         Filename        : draft-ietf-lpwan-schc-compound-ack-03.txt
>         Pages           : 12
>         Date            : 2022-02-09
> 
> Abstract:
>    The present document describes an extension to the SCHC (Static
>    Context Header Compression and fragmentation) protocol [RFC8724].  It
>    defines a SCHC Compound ACK message format, which is intended to
>    reduce the number of response transmissions (i.e., SCHC ACKs) by
>    accumulating bitmaps of several windows in a single SCHC message
>    (i.e., the SCHC Compound ACK).
> 
>    The message format is generic, and can be used, for instance, by any
>    of the four LWPAN technologies defined in [RFC8376], being Sigfox,
>    LoRaWAN, NB-IoT and IEEE 802.15.4w.
> 
> 
> The IETF datatracker status page for this draft is:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrac
> ker.ietf.org%2Fdoc%2Fdraft-ietf-lpwan-schc-compound-
> ack%2F&amp;data=04%7C01%7Cjuancarlos.zuniga%40sigfox.com%7Cb2e14db273ea44c
> b1d8408d9ec28bcca%7Cfcbc8bb1061e4b949f703ad917b0c8d3%7C0%7C0%7C63780048284
> 2709495%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi
> I6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=leD7D76kWHudanfgM%2BcWHuDxE7TNMQ
> Xqgub0a25L5uw%3D&amp;reserved=0
> 
> There is also an htmlized version available at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrac
> ker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-lpwan-schc-compound-ack-
> 03&amp;data=04%7C01%7Cjuancarlos.zuniga%40sigfox.com%7Cb2e14db273ea44cb1d8
> 408d9ec28bcca%7Cfcbc8bb1061e4b949f703ad917b0c8d3%7C0%7C0%7C637800482842709
> 495%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik
> 1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=y812lquFGbHMhKMJfVecrnHlE%2BELZxUsiU
> 9SBwkzBHA%3D&amp;reserved=0
> 
> A diff from the previous version is available at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf
> .org%2Frfcdiff%3Furl2%3Ddraft-ietf-lpwan-schc-compound-ack-
> 03&amp;data=04%7C01%7Cjuancarlos.zuniga%40sigfox.com%7Cb2e14db273ea44cb1d8
> 408d9ec28bcca%7Cfcbc8bb1061e4b949f703ad917b0c8d3%7C0%7C0%7C637800482842709
> 495%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik
> 1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=GJKblQbssQ8KMswFKosp4%2BC%2FXNk%2FhC
> Y2kxigK3jKubY%3D&amp;reserved=0
> 
> 
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-
> drafts
> 
> 
> _______________________________________________
> lp-wan mailing list
> lp-wan@ietf.org
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf
> .org%2Fmailman%2Flistinfo%2Flp-
> wan&amp;data=04%7C01%7Cjuancarlos.zuniga%40sigfox.com%7Cb2e14db273ea44cb1d
> 8408d9ec28bcca%7Cfcbc8bb1061e4b949f703ad917b0c8d3%7C0%7C0%7C63780048284270
> 9495%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I
> k1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=ESQrlfOff%2Fza1KjfMnUkX0G2djDhD79M3
> RpoSC3sdPU%3D&amp;reserved=0
> Your privacy is important to us. Please see our Privacy
> Notice<https://www.sigfox.com/en/privacy-and-cookies-policy> for further
> details. The information contained in this Message is confidential. If you
> are not the addressee, you may not copy, forward, disclose or use any part
> of it. If you have received this Message in error, please delete it and
> all copies from your system and notify the sender immediately by return
> message. Any use of information contained in this Message not in
> accordance with its intended purpose, any dissemination or disclosure
> (either whole or partial), is prohibited unless expressly authorized.
> Email communication cannot be guaranteed to be timely secure, error or
> virus-free. The sender cannot be held responsible for any alteration,
> errors or omissions, which arise as a result.
> 
> ..........................................................................
> ........................................
> 
> La protection de vos données personnelles est primordiale pour notre
> établissement. Merci de consulter notre notice sur la protection des
> données personnelles <https://www.sigfox.com/en/privacy-and-cookies-
> policy> pour plus d’informations. Ce message et toutes les pièces jointes
> (ci-après le 'Message') sont établis à l'intention exclusive des
> destinataires. Les informations qui y figurent sont confidentielles. Si
> vous n'êtes pas le destinataire de ce Message, il vous est interdit de le
> copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou
> partie. Si vous avez reçu ce Message par erreur, merci de le supprimer de
> votre système, ainsi que toutes ses copies, et de n'en garder aucune trace
> sur quelque support que ce soit. Veuillez également en avertir
> immédiatement l'expéditeur par retour du Message. Toute utilisation de ce
> Message non conforme à sa destination, toute diffusion ou toute
> publication totale ou partielle, est interdite sauf autorisation expresse.
> Il est impossible de garantir que les communications par messagerie
> électronique arrivent en temps utile, soient sécurisées ou dénuées de
> toute erreur ou virus. L'expéditeur ne peut être tenu responsable des
> modifications, erreurs ou omissions qui pourraient en résulter.
> _______________________________________________
> lp-wan mailing list
> lp-wan@ietf.org
> https://www.ietf.org/mailman/listinfo/lp-wan