Re: [lp-wan] Tsvart last call review of draft-ietf-lpwan-schc-over-nbiot-12

[Ana Minaburo <[e-mail]>]

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.
https://github.com/lp-wan/SCHC-NBIoT/blob/master/draft-ietf-lpwan-schc-over-nbiot-13.md

See our comments below.

Ana & Edgar

On Thu, Oct 20, 2022 at 3:01 AM Spencer Dawkins via Datatracker <
[e-mail]> 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
> [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.
>
[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.