[Last-Call] Tsvart last call review of draft-ietf-lpwan-schc-over-nbiot-12

[Spencer Dawkins via Datatracker <[e-mail]>]

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
[e-mail] 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.

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?

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.

Under terminology:

It would be helpful to include DoNAS and NAS in the Terminology section.

“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.

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.

I couldn’t parse

“In case SCHC is not standardized as a mandatory capability.”

without guessing.

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.”

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?

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”?

(Is that defined in [TS36322]?)

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.

For the same reason, you might consider adding the acronyms in the subsection
titles (A.1, A.2, A.3) to the Terminology section.

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)