Skip to main content

Static Context Header Compression (SCHC) Compound Acknowledgement (ACK)
draft-ietf-lpwan-schc-compound-ack-17

Note: This ballot was opened for revision 13 and is now closed.

Éric Vyncke
Yes
Comment (2023-03-09 for -13) Not sent
Two quick notes:
- feel free to defer or ask me to postpone to April telechat (but 16th of March telechat is 'light')
- more than 5 authors, but, as indicated in the shepherd write-up, there is a Ph.D. and the associated academia
Erik Kline
No Objection
Francesca Palombini
No Objection
John Scudder
No Objection
Comment (2023-03-13 for -14) Sent
Thanks for this document, in particular I appreciated the care you took to accommodate non-experts in the Introduction. I have a few minor comments you may want to consider.

1. In Section 3.2 you write,

“The following Section 8.4.3 (and its subsections) replaces the complete sections 8.4.2 (and its subsections) of RFC 8724.”

I assume this must be a typo, and what you actually mean is that it replaces 8.4.3, right? 

2. In 8.4.3 you have,

"if the last tile is carried in a Regular SCHC Fragment or an All-1 SCHC Fragment Section 8.4.3.1), and"

You seem to have lost the "(see " that was present in the original text, i.e. I think what it should read is,

"if the last tile is carried in a Regular SCHC Fragment or an All-1 SCHC Fragment Section (see 8.4.3.1), and"

3. In 8.4.3.2 you write,

"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 tiles, starting from the lowest-numbered window."

I leave it to your discretion and that of others who know this field better than I do, however "(and if network conditions are known to be conducive)" seems pretty vague on the face of it -- maybe an implementor who is skilled in the field would say "ah yes, I know exactly what to do with this", but to me it's uninformative. If it's possible to make this more descriptive and ideally more prescriptive, that would be great.
Murray Kucherawy
No Objection
Comment (2023-03-16 for -14) Sent
"draft-ietf-lpwan-schc-yang-data-model" is now RFC 9363.  Given the text in Section 5, shouldn't this document update that one?
Paul Wouters
No Objection
Comment (2023-03-15 for -14) Sent
Some small comments:

In section 8.4.3. ACK-on-Error Mode, there are a bunch of MUST requirements. If one of these fails, what will happen? Is there a chance of causing an ACK-on-Error reply, which then might cause an ACK-on-Error storm between two nodes?

There is a similar issue with lots of MUST clauses further on. Perhaps it would be useful to have add a sentence somewhere reminding implementers that error handling is defined in https://www.rfc-editor.org/rfc/rfc8724.html#section-7.2   (which mostly states "MUST drop packet", so avoids error storms, answering my own comment above :)
Roman Danyliw
No Objection
Comment (2023-03-14 for -14) Not sent
Thank you to Brian Weis for the SECDIR review.

Per id-nits:
  -- The draft header indicates that this document updates RFC8724, but the
     abstract doesn't seem to directly say this.  It does mention RFC8724
     though, so this could be OK.
Warren Kumari
No Objection
Comment (2023-03-15 for -14) Sent
Thank you to the authors for writing this, and also to Tianran Zhou for the OpsDir review (https://datatracker.ietf.org/doc/review-ietf-lpwan-schc-compound-ack-12-opsdir-lc-zhou-2023-03-02/) 

I'm not completely sure that the added text ("The receiver can suspect if the sender does not support the SCHC Compound ACK, if the sender does not resend any tiles from windows that are not the first one in the SCHC Compound ACK and more ACKs are needed.") fully addresses the OpsDir concern - yes, it can suspect this, but it seems like it would be helpful to provide a suggestion as to what a receiver should do if it suspect this.... I'm leaving this as NoObj because I think that a: the authors will add something and if not, b: implementors will be able to figure it out.
Zaheduzzaman Sarker
No Objection
Comment (2023-03-15 for -14) Sent
Thanks for working on this specification. Thanks to Wesley Eddy for his TSVART view. @Authors please address his comments.
Alvaro Retana Former IESG member
No Objection
No Objection (2023-03-14 for -14) Sent
Andrew Alston Former IESG member
No Objection
No Objection (for -14) Not sent

                            
Robert Wilton Former IESG member
No Objection
No Objection (2023-03-16 for -14) Sent
There is probably also some cosmetic cleanup of the YANG module that might help (although the RFC editor will normally also check this).

I've run it through "pyang -f yang --yang-line-length 69 ietf-lpwan-schc-compound-ack@2022-12-02.yang > ietf-lpwan-schc-compound-ack@2023-03-16.yang" to fix the spacing and also manually added some blank lines to the top level module description.  I'll attach this as an email response to my ballot position for you to use if you wish.

Thanks,
Rob