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@ietf.org 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)