Last Call Review of draft-ietf-lpwan-schc-over-nbiot-12
review-ietf-lpwan-schc-over-nbiot-12-iotdir-lc-vucinic-2022-10-17-00
Request | Review of | draft-ietf-lpwan-schc-over-nbiot |
---|---|---|
Requested revision | No specific revision (document currently at 15) | |
Type | Last Call Review | |
Team | Internet of Things Directorate (iotdir) | |
Deadline | 2022-10-20 | |
Requested | 2022-10-03 | |
Requested by | Éric Vyncke | |
Authors | Edgar Ramos , Ana Minaburo | |
I-D last updated | 2022-10-17 | |
Completed reviews |
Tsvart Last Call review of -12
by Spencer Dawkins
(diff)
Secdir Last Call review of -12 by Barry Leiba (diff) Opsdir Last Call review of -12 by Sarah Banks (diff) Iotdir Last Call review of -12 by Mališa Vučinić (diff) Dnsdir Telechat review of -12 by Johan Stenstam (diff) |
|
Comments |
Sorry for the short-term notice... (I was on holidays ;-) ). Suggest to have a review by someone having a good mobile/3GPP background. The deadline can be past the last-call deadline (7th of October) but should really be before the final IESG telechat review (i.e., probably on the 20th of October). Thanks, -éric |
|
Assignment | Reviewer | Mališa Vučinić |
State | Completed | |
Request | Last Call review on draft-ietf-lpwan-schc-over-nbiot by Internet of Things Directorate Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/iot-directorate/DWakbNncgSta1BwDNAnPYztLWKU | |
Reviewed revision | 12 (document currently at 15) | |
Result | Ready w/nits | |
Completed | 2022-10-17 |
review-ietf-lpwan-schc-over-nbiot-12-iotdir-lc-vucinic-2022-10-17-00
Hello, I have reviewed draft-ietf-lpwanschc-over-nbiot-12 as part of the IoT directorate. The draft specifies a SCHC profile for NB-IoT in three use cases: 1) SCHC over the Radio link; 2) SCHC over the No-Access Stratum; 3) SCHC over Non-IP Data Delivery. I find the draft well-written and Ready with Nits. I have some questions to the authors in the following, mainly for my better understanding of the specification. Questions: =========================== Section 5.2.1: "Because the NAS protocol already uses ROHC [RFC5795], it can also adapt SCHC for header compression." - From the sentence above, I am under the impression that ROHC and SCHC can and should work concurrently? Is this what you meant? Section 5.3: "The network operator in these scenarios defines the number of rules. For this, the network operator must know the IP traffic the device will carry.” - I wonder how feasible is this requirement from the operational perspective. I understand that you assume that the IoT application on Dev UE rarely changes and that the traffic is predictable by the IoT service provider. But service provider is different from the network operator where you need to set these rules. My question is how would the setting of SCHC rules here work in case the network operator is not the IoT service provider? Section 5.3: "SCHC overhead SHOULD NOT exceed the available number of effective bits of the smallest physical TB available to optimize the transmission. (...) Thus, to use the smallest TB, the maximum SCHC header size is 12 bits." - I find the normative wording here convoluted, mainly because of the long explanation that follows it only to get to the point that max SCHC header size should be 12 bits. Why don’t you simply say “The maximum SCHC header size SHOULD be 12 bits.”? Am I missing something here? Nits: =========================== Section 5: "In case SCHC is not standardized as a mandatory capability. It will not be used when a terminal or network does not support it." - Replace dot with comma Section 5.4.2: "The IoT devices communicate with small data transfer and have a battery life of 10 years." - This is an overly generalized statement, please rephrase. Mališa