Static Context Header Compression over Narrowband Internet of Things
draft-ietf-lpwan-schc-over-nbiot-15

# Internet AD comments for {draft-ietf-lpwan-schc-over-nbiot-12}
CC @ekline

Update/2022.10.17: please also see the feedback from the IoT-DIR review.

## Comments

### S5.3

* What exactly is meant here?

                                                     ...  The IPv6 and
  IPv4 deployment may force to get more rules to deal with each case.

  Does this just mean that dual-stack deployments require more rules than
  either IPv6-only or IPv4-only deployments?

### Appendix B

* "16000 bytes"

  Is this 16000 correct?  Or should it be 1600?

## Nits

### S5.4.2

* "COULD" is not in the 8174 list of meaningfully capitalized words.  Even
  attempting to interpret as a "MAY" doesn't really apply in this wording.

  Suggestion: lowercase is fine.

### Appendix A.2

* Perhaps: s/octets aligned/octet-aligned/

### Appendix A.3

* "HARQ" isn't defined until Appendix B.  Consider fully expanding the
  initialism here.

No comments beyond what has already been pointed out by Rob and Roman.

Thank you to Barry Lieba for the SECDIR review.

Lacking the background on why we are making suggestions to another SDO who didn’t solicit our feedback, I share Rob Wilton’s curiosity on why this is a proposed standard status document.

** Editorial. This document refers to itself as an “I-D” in a number of places.  When published as an RFC, it will not be an I-D anymore.  Please replace “I-D” with document or something similar to save future search-and-replace for the RFC Editor.

** Section 5.2.1.  Typo. s/section Section 5.1/Section 5.1/.  Multiple places.

** Section 5.4.2.
   Also, the ACK-on-Error mode COULD be desirable to keep track of all
   the SCHC packets delivered.  

“COULD” is being used like it is an RFC2119 key word.  It is not.  Should this an “SHOULD”?

Firstly, thank you to the authors for writing this -- I found it fascinating.

I'd also like to thank Sarah Banks for the helpful/insightful OpsDir review; there is now a liaison statement related to this topic, and Lars has a (somewhat) related DISCUSS position.

It's really nice when the OpsDir process works well.

Thanks again to both the authors and Sarah,
W

Thanks for working on this specification. (This has a good description of 3GPP system and networking) I have looked into transport related issues and I haven't any serious or obvious one. Please resolve the TSVART reviewer's comments and it has some good observations. Thanks Spencer Dawkins for his review.

I actually kind of agree with other AD's observation regarding why in IETF we are doing it and if this is the correct RFC state. However, I am also wondering if this issues have been discussed in the working group and if there is consensus in the working group to actually process with this publication as standard track. As this document has came this far in the process I assume an affirmative answer and it is worth discussing the working group's view on these points.

# GEN AD review of draft-ietf-lpwan-schc-over-nbiot-12

CC @larseggert

## Comments

### Section 5, paragraph 4
```
     This I-D identifies the use cases of SCHC over the NB-IoT
     architecture.
```
I-D -> document

### Section 5.2, paragraph 1
```
     This section consists of IETF suggestions to the 3GPP.
```
See above on not giving suggestions to other SDOs via documents.

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term `natively`; alternatives might be `built-in`, `fundamental`,
   `ingrained`, `intrinsic`, `original`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Duplicate references

Duplicate informative references to:
`https://www.3gpp.org/ftp/Specs/archive/36_series/36.321/36321-d20.zip`.

### Grammar/style

#### Section 3, paragraph 20
```
istics in terms of bandwidths, acknowledgments, and layer-2 reliability and s
                               ^^^^^^^^^^^^^^^
```
Do not mix variants of the same word ("acknowledgment" and "acknowledgement")
within a single text. (Also elsewhere.)

#### Section 5, paragraph 2
```
 radio transmission where, see section Section 5.1, the Dev-UE and the RGW-eN
                               ^^^^^^^^^^^^^^^
```
Possible typo: you repeated a word.


#### Section 5.2, paragraph 4
```
The same principles as for the section Section 5.1 apply here as well. Becaus
                               ^^^^^^^^^^^^^^^
```
Possible typo: you repeated a word.

#### Section 5.2, paragraph 5
```
ce compared to the radio link, section Section 5.1, is the physical placing o
                               ^^^^^^^^^^^^^^^
```
Possible typo: you repeated a word.

#### Section 5.2.1, paragraph 2
```
 IPv6 and IPv4 deployment may force to get more rules to deal with each case
                                    ^^^^^^
```
Did you mean "getting"? Or maybe you should add a pronoun? In active voice,
"force" + "to" takes an object, usually a pronoun.

#### Section 5.3, paragraph 7
```
 if needed, including reliability. Hence the packet size is limited by the M
                                   ^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Hence".

#### Section 5.3, paragraph 11
```
C fragmentation parameters see section Section 5.4.2. 5.4. SCHC over Non-IP
                               ^^^^^^^^^^^^^^^
```
Possible typo: you repeated a word.

#### Section 5.4.1, paragraph 11
```
gmentation mode is in use, and section Section 5.3 defines the RuleID size.
                               ^^^^^^^^^^^^^^^
```
Possible typo: you repeated a word.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

Please respond to Spencer Dawkins's editorial comments in the TSVART review (and thanks to him for that review).

Hi,

Thanks for this document.

Like, Sarah in her OPSDIR review, I also questioned whether standards track is really the right category for this document rather than informational, particularly because it seems somewhat unclear whether 3GPP will make use of it. But perhaps it needs to be standard track for 3GPP to consider it in the first place?

Regards,
Rob

Also, thank you to Sarah for the OPSDIR review.