Skip to main content

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