Tuesday, March 8, 2022< ^ >
Room Configuration
Room Occupants

[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