Dear Malisa,
Sorry for our delay. We want to thank you for your review. We are publishing version 13 with all the IESG review inputs.
We have corrected the nits you bring out.
We have corrected the nits you bring out.
See our answers below.
Ana & Edgar
On Mon, Oct 17, 2022 at 7:24 PM Mališa Vučinić via Datatracker <noreply@xxxxxxxx> wrote:
Reviewer: Mališa Vučinić
Review result: Ready with Nits
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?
[Ana] Yes, the PDCP layer and the NAS protocol may use any header compression protocol to reduce the IP overhead.
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?
[Ana] The LPWAN WG is working on the draft-pelov-lpwan-architecture, where we are planning to define how the Rule information is managed.
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?
[Ana] No, you have not missed anything. I changed it to:
The packets handled by 3GPP networks are byte-aligned. Thus, to use the smallest TB, the maximum SCHC header size is 12 bits.
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
[Ana] Done
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.
[Ana] change to:
The IoT devices communicate with small data transfer and use the Power Save Mode and the Idle Mode DRX, which govern how often the device wakes up, stays up, and is reachable. The use of the different modes allows the battery to last ten years.
Mališa
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
