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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Ana,

On Thu, Nov 3, 2022 at 10:27 AM Ana Minaburo <[e-mail]> wrote:

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

This all seems fine. Thanks for working through my comments!

I should note that the README in the Github repo still references
tools.ietf.org - the current diff program is now at
https://www.ietf.org/rfcdiff, so you may want to change that, unless you
never need to update the draft again. 🙂

Best,

Spencer


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