Re: [lp-wan] WGLC for draft-ietf-lpwan-schc-compound-ack-01

[Juan Carlos Zuniga <[e-mail]>]

Hello Dominique, all,

Happy New Year!

Thanks a lot for the very useful and detailed review. We have addressed your comments in https://www.ietf.org/archive/id/draft-ietf-lpwan-schc-compound-ack-02.html

Some details below:

> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: November 9, 2021 4:42 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: RE: WGLC for draft-ietf-lpwan-schc-compound-ack-01
>
> CAUTION: EXTERNAL EMAIL. Do not click links or open unless you recognize
> the sender and know the content is safe.
>
> Hello all,
>
> I reviewed draft-ietf-lpwan-schc-compound-ack-01.
> My main feedback is that section 3.1 should be explained better, in more
> details, see below.
> A few minor comments follow.
> Best regards
>
> Dominique
>
> ====
>
> 1) The whole normative content of the draft is currently contained in 9 lines
> of text, which look incomplete to me
>   " 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. If padding is needed for the SCHC Compound ACK,
>   padding bits MUST be 0 to make subsequent window numbers and bitmaps
>   distinguishable.
>   Each different SCHC LPWAN technology profile MUST specify how the
>   SCHC Compound ACK is different from the Receiver-Abort message.
>   The SCHC Compound ACK MAY use a Compressed Bitmap, and bitmap fields
>   MAY be of variable size."
[JCZ] We have made several editions to clarify the normative text and make it compatible with RFC 8724 (see below).

>
> I have a lot of questions that are left unanswered by these 9 lines
> - if the bitmaps can be compressed, and therefore of variable length, how do
> you tell where is the end of the bitmap and the beginning of the subsequent
> W? Don't you need a leading 0 in/before the W field to do that?
> - or do I understand that padding may be used between the bitmaps and the
> subsequent W? ("If padding is needed for the SCHC Compound ACK, padding
> bits MUST be 0 to make subsequent window numbers and bitmaps
> distinguishable". Please specify if padding is used at most once (at the end of
> the message) or in-between the W+bitmaps groups.
[JCZ] We have clarified the use of the compressed bitmap (only in the last window) as well as the padding.

> - if a SCHC fragment sender gets a compound ACK with invalid W's (like
> duplicate W values or, W values that is has not even sent yet), shall it discard
> the compound message as a whole or the individual offending bitmap(s),
> shall it reset?
[JCZ] Indeed, this is a good catch. We have added explanatory text.

> - Basically, can you write the delta text that should be applied to RFC8724 Ack
> on Error description to make it work with compound Ack?
[JCZ] A section adding this delta text has been added.
>
>
> 2) Minor comments
> - Section 3
> "When the ACK-on-Error mode is used for uplink fragmentation, SCHC
> Compound ACKs MAY be used in the downlink responses."
> I think you don't want normative language here. This sentence overlaps with
> one in 3.1, but is not identical. ("In case SCHC fragment losses are found in
> any of the windows of the SCHC Packet (C=0), the SCHC Compound ACK MAY
> be used.") The sentence here seems to imply that the compound ACK should
> not be used for uplink response, the one in 3.1 doesn't.
> Here, you probably want to write something like "compound ack was
> designed to be used for uplink fragmentation, in order to save on the
> downlinks".
[JCZ] Agree. The text has been corrected.

> - Figure 2: I'd rather use "w1, ..., wi  with w1<w2<...<wi" instead of "x, ...,
> x+i". Your notation makes me think you are somehow doing delta encoding,
> which is not the case.
[JCZ] Done

> - Section 1
> "application header compression": I think application header is too
> restrictive. "protocol header" seems more appropriate.
[JCZ] Done

Thanks!

Juan Carlos et al.

>
> -----Original Message-----
> From: lp-wan [mailto:[e-mail]] On Behalf Of Pascal Thubert
> (pthubert)
> Sent: lundi 8 novembre 2021 11:30
> To: [e-mail]
> Subject: Re: [lp-wan] WGLC for draft-ietf-lpwan-schc-compound-ack-01
>
> Dear all
>
> I believe that the doc is almost ready for publication.
>
> A nit:
>
>    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.
>
> Do you mean:
>
>    The window number for the first window MUST be placed between the
> Rule
>    ID and the C bit to avoid confusion with padding bits when the window
>    numbered 00 is present.
>
> What about Annex D of RFC 8724.
> I see that the draft provides a data model but no annex D complement.
> Yet the draft indicates that there's a need to express for each technology:
> - info about bitmap compression
> - how the SCHC Compound ACK is different from the Receiver-Abort
> message.
>
> I believe an annex would be of order.
>
> We need to sync the data model part in the draft with the
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatr
> acker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-lpwan-schc-yang-data-
> model&amp;data=04%7C01%7Cjuancarlos.zuniga%40sigfox.com%7Cbf727f2
> 565e44057953408d9a36d9f5b%7Cfcbc8bb1061e4b949f703ad917b0c8d3%7C
> 0%7C0%7C637720513482847069%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000
> &amp;sdata=1rjt93CO70ObE6%2FoEIThBnM6Iv41ouZgKGz1CDIbflI%3D&amp
> ;reserved=0, which already includes things like:
>
> identity bitmap-compound-ack {
>        base bitmap-format-base-type;
>        description
>          "Compound Ack.";
>      }
>
> I would make sense that the data model in this draft should be removed and
> all centralized in the data model draft since that one will be published
> afterwards.
>
> Keep safe;
>
> Pascal
>
> > -----Original Message-----
> > From: Pascal Thubert (pthubert)
> > Sent: vendredi 22 octobre 2021 8:54
> > To: [e-mail]
> > Subject: WGLC for draft-ietf-lpwan-schc-compound-ack-01
> >
> > Dear LPWANers:
> >
> > This starts the WGLC for draft-ietf-lpwan-schc-compound-ack-01. The
> > call will end in 2 weeks on November 5th.
> >
> > We expect to discuss the draft and the comments at IETF 112. LPWAN
> > will meet at 14:30-15:30 on Tuesday (Session II).
> >
> > Please provide comments as soon as possible so we can start on the ML
> > prior to the meeting.
> >
> > Keep safe;
> >
> > Pascal
>
> _______________________________________________
> lp-wan mailing list
> [e-mail]
> 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%7Cbf727f256
> 5e44057953408d9a36d9f5b%7Cfcbc8bb1061e4b949f703ad917b0c8d3%7C0%
> 7C0%7C637720513482857066%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&a
> mp;sdata=0Zgclab3BafBTeWOku1oNA09GhtVXOwZtFNxoxNRlyA%3D&amp;r
> eserved=0
>
> ________________________________________________________________
> _________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites
> ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez
> le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les
> messages electroniques etant susceptibles d'alteration, Orange decline toute
> responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be distributed,
> used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.

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.