IETF
LPWAN
lpwan@jabber.ietf.org
Tuesday, March 8, 2022< ^ >
Room Configuration
Room Occupants

GMT+0
[00:24:03] cabo leaves the room
[14:50:43] Pascal Thubert_web_781 joins the room
[14:53:17] Ana Minaburo_web_264 joins the room
[14:58:48] Dominique Barthel_web_530 joins the room
[14:59:09] Laurent Toutain_web_541 joins the room
[15:00:39] Ivan Martinez_web_708 joins the room
[15:01:16] Carles Gomez_web_515 joins the room
[15:02:17] Juan-Carlos Zúñiga_web_707 joins the room
[15:02:59] Éric Vyncke_web_984 joins the room
[15:03:11] Sergio Aguilar_web_767 joins the room
[15:04:27] <Éric Vyncke_web_984> Thank you, I was wondering ;-)
[15:05:53] Alexander Pelov_web_321 joins the room
[15:06:12] <Alexander Pelov_web_321> hi all !
[15:06:15] <Alexander Pelov_web_321> sorry for being late
[15:18:01] Laurent Toutain_web_541 leaves the room
[15:18:05] Laurent Toutain_web_855 joins the room
[15:44:26] <Sergio Aguilar_web_767> the Dev only has one set of rules, the App has one set of Rules per each Dev id
[15:46:05] <Pascal Thubert_web_781> I believe this document updates RFC 8724 and that should be indicated in the RFC tag
---------------
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.
---------------
[15:46:53] <Éric Vyncke_web_984> Because the above text is kind of mis-aligned ;-)
[15:47:25] <Sergio Aguilar_web_767> yes
[15:50:23] <Éric Vyncke_web_984> Correct JZ, update attribute in the rfc tag + text in the abstract & introduction
[15:50:45] <Éric Vyncke_web_984> s/JZ/JCZ/ ;-)
[15:51:12] <Dominique Barthel_web_530> is the feature optional or mandatory in SCHC ?
[16:02:10] Pascal Thubert_web_781 leaves the room
[16:02:10] Éric Vyncke_web_984 leaves the room
[16:02:11] Ana Minaburo_web_264 leaves the room
[16:02:12] Dominique Barthel_web_530 leaves the room
[16:02:24] Sergio Aguilar_web_767 leaves the room
[16:02:44] Juan-Carlos Zúñiga_web_707 leaves the room
[16:02:45] Laurent Toutain_web_855 leaves the room
[16:02:47] Carles Gomez_web_515 leaves the room
[16:02:49] Alexander Pelov_web_321 leaves the room
[16:02:49] Ivan Martinez_web_708 leaves the room
[19:04:23] cabo joins the room