Dear Spencer,
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.
See our comments below.
Ana & Edgar
On Thu, Oct 20, 2022 at 3:01 AM Spencer Dawkins via Datatracker <noreply@xxxxxxxx> wrote:
Reviewer: Spencer Dawkins
Review result: Ready with Nits
This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.
When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@xxxxxxxx if you reply to or forward this review.
This is a dense document, and that's probably unavoidable. I had a couple of
technical questions, but most of what follows is about readability (including
some sentences I couldn't parse). I could reasonably have marked this "ready
with nits" - it's very close.
Best wishes as you move this document forward.
One general nit:
I imagine the RFC Editor will suggest expanding the acronyms in the title.
[Ana] Done
One point of confusion:
I understand why some of the sections in this standards-track document are
tagged as “informational”, but I’m confused why Section 5.4 is tagged as
“normative”. Aren’t all of the sections in a standards-track document assumed
to be normative?
[Ana] the document has three parts:
- two informational about how 3GPP could use SCHC for their 'internal' network- one standard 'end to end' how any application developer must use SCHC *over* the 3GPP public service (i.e., 3GPP network is fully unaware of SCHC use)
We have modified the structure of the document to see if this is more clear, see please version-13.
One observation:
As other reviewers have noted, this document is extremely acronym-dense, and I
don’t think you can fix that (certainly not in a reasonable amount of time).
Rather than ask for the impossible, I’d suggest adding a list at the beginning
of the document that describes the structure of the document (something like an
expanded table of contents), and calls attention to the very helpful
Appendices, that people might not realize they should read as background.
[Ana] It is a very good input to define the structure of the document, this will also help to understand the informative/normative parts.
We have add references to the appendix, and we have modified the structure of the document, hoping this could simplify the lecture. We have improve the terminology list too.
See please the link with version-13
Under terminology:
It would be helpful to include DoNAS and NAS in the Terminology section.
[Ana] Done
“L2. Layer-2.”
isn’t enlightening. I don’t have any objection to using “l2” or “layer 2” in
this specification, but it’s probably better if you have a more useful
definition for the terms.
[Ana] Yes, and in the NB-IoT architecture the layer 2 includes the PDCP, RLC and MAC layers, so I've changed the terminology description of L2 to:
* L2. Layer-2 includes MAC, RLC and PDCP layers see {{AppendixA}}.
I've modified the definition on terminology too.
Under Section 5:
Is the concern about fragmentation in
“The recommended 3GPP MTU size is 1358 bytes. The radio network protocols limit
the packet sizes over the air, including radio protocol overhead, to 1600
bytes. However, the recommended 3GPP MTU is smaller to avoid fragmentation in
the network backbone due to the payload encryption size (multiple of 16) and
the additional core transport overhead handling.”
alleviated by RLC segmentation, as mentioned in 5.3? If so, it might be useful
to have a forward pointer to 5.3.
[Ana] Done
I couldn’t parse
“In case SCHC is not standardized as a mandatory capability.”
without guessing.
[Ana] yes, it is obvious, I delete the sentence.
I couldn’t parse
“And third use case, over the SCHC over Non-IP Data Delivery (NIDD) connection
or at least up to the operator network edge, see Section 5.4.”
[Ana] changed to:
“And third, over the SCHC over Non-IP Data Delivery (NIDD) connection
or at least up to the operator network edge, see Section 5.4.”
without guessing.
In
“A non-IP transmission refers to other layer-2 transport.”,
I wasn’t sure what “other” meant. Could you give an example of an alternative
layer-2 transport?
[Ana]other layer-2 transport different from NB-IoT as Sigfox or LoRaWAN
Under Section 5.3:
Would it be helpful to provide a reference for “SCHC header compression” in
“If 3GPP incorporates SCHC, it is recommended that these scenarios use SCHC
header compression capability to optimize the data transmission”?
[Ana] Done
(Is that defined in [TS36322]?)
[Ana] Yes, the TS36322 describes RLC layer, and part of the appendix information has been taken from this document, the other documents used for the appendix were the TS36323 for Packet Data Convergence Protocol (PDCP) and TR36321 for Medium Access Control protocol (MAC)
In Appendix A:
As a 3GPP neophyte (and someone who rarely ventures outside SA technical
working groups), I appreciate very much that you included this material in the
draft. It’s very useful to someone on the outside of the technology. I’d
suggest a couple of minor changes that would make it more useful
In each of the subsections (A.1, A.2, A.3), could you include an appropriate
reference early in the Subsection? I see that you’ve got those references in
5.1, but anyone who wants to start with the background that Appendix A
provides, won’t see them unless they start searching.
[Ana] Done
For the same reason, you might consider adding the acronyms in the subsection
titles (A.1, A.2, A.3) to the Terminology section.
[Ana] Done
In Appendix B:
I’m not sure “somehow particular” is the right phrase in
“The Access Stratum (AS) protocol stack used by DoNAS is somehow particular.
Since the security associations are not established yet in the radio network,
to reduce the protocol overhead, PDCP (Packet Data Convergence Protocol) is
bypassed until AS security is activated. RLC (Radio Link Control protocol) uses
by default the AM mode, but depending on the network's features and the
terminal, it may change to other modes by the network operator.”
Is the point that the AS protocol stack changes after AS security is activated?
(That’s not a suggestion for replacement text)
[Ana] yes, it is very specific to this kind of transmission because we go from control plane to data plane.
I changed the text to:
The Access Stratum (AS) protocol stack used by DoNAS is specific because the radio network still needs to establish the security associations and reduce the protocol overhead, so the PDCP (Packet Data Convergence Protocol) is bypassed until AS security is activated. RLC (Radio Link Control protocol) uses, by default, the AM mode, but depending on the network's features and the terminal, it may change to other modes by the network operator.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
