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

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 8 Nov 2021 09:03:46 +0000

Dear all

The last call has ended. We did not get much comments and we plan to confirm at the meeting that the document is ready for publication. If there's any objection / issue now is the nick of time for letting us know!

The chairs,

Pascal

> -----Original Message-----
> From: lp-wan <[email-masked]> On Behalf Of Pascal Thubert
> (pthubert)
> Sent: vendredi 22 octobre 2021 8:54
> To: [email-masked]
> Subject: [lp-wan] 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 8 Nov 2021 10:29:53 +0000

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://datatracker.ietf.org/doc/html/draft-ietf-lpwan-schc-yang-data-model, 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

> From: Pascal Thubert (pthubert)
> Subject: WGLC for draft-ietf-lpwan-schc-compound-ack-01
> 
> Dear LPWANers:
>

---

From: <[email-masked]>
Date: Tue, 9 Nov 2021 10:42:13 +0000

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."

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.
- 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?
- Basically, can you write the delta text that should be applied to RFC8724 Ack on Error description to make it work with compound Ack?

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".
- 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.
- Section 1
"application header compression": I think application header is too restrictive. "protocol header" seems more appropriate.

-----Original Message-----
From: lp-wan [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: lundi 8 novembre 2021 11:30
To: [email-masked]
Subject: Re: [lp-wan] WGLC for draft-ietf-lpwan-schc-compound-ack-01

Dear all

A nit:

Do you mean:

Keep safe;

Pascal

> 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

_________________________________________________________________________________________________________________________

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.