Re: [lp-wan] Shepherd review of draft-ietf-lpwan-schc-over-nbiot-09.txt

["Pascal Thubert (pthubert)" <[e-mail]>]

A few more nits:

25) You need a IANA section, if only to say that there is no IANA action on the draft

26) a piece of fig 6 appears slightmy shifted
|    |(1)| `-----\(2)'-\

    What are (1) and (2)?

Keep safe;

Pascal

> -----Original Message-----
> From: Pascal Thubert (pthubert)
> Sent: mercredi 29 juin 2022 13:48
> To: [e-mail]
> Cc: lp-wan <[e-mail]>
> Subject: Shepherd review of draft-ietf-lpwan-schc-over-nbiot-09.txt
> 
> Dear authors and all:
> 
> Many thanks for this great document!
> 
> I find it well-written and very informative, though a few sentences should be
> re-edited. In particular, the drawings in section 4.2 are just great.
> 
> In prep for publication please find my review for draft-ietf-lpwan-schc-over-
> nbiot-09, can you please consider the following suggestions and publish a
> version 10:
> 
> 1) Terminology: missing  Requirements Language (BCP 14) - please add, see
> example in the Yang model draft.
> 
> 2) Terminology: define PLMN; also NGW-SGW is defined but the figure uses NGW-
> CSGW: please align.
> 
> 3) References: make but RFC 8724, RFC 8376, RFC 2119, and RFC 8174 normative
> references; and move all other references to the informative reference
> section - unless this document cannot be implemented without details
> specified the reference.
> 
> 4) References: typo in the title of TR33203. Also add references to OMA and
> OneM2M
> 
> 5) "The signaling data uses a different path with specific protocols". The
> use of "data" while understandable could be misleading since we usually
> associate with user data as opposed to signaling data; so maybe saying
> signaling without saying data is more readable, or "control signaling" as you
> do elsewhere in the document? Also, is it the same signaling as in the
> previous sentence or is this one not in band? I got confused.
> 
> 6) "The maximum recommended 3GPP MTU size is 1358 Bytes." Should we make that
> the IPv6 MTU for the link that SCHC provides in the UE? Should we say that
> the IPv6 min MTU of 1280 is always to be used in SCHC over NB IOT links like
> 6LoWPAN does?
> 
> 7) "The SCHC functionalities can only be used over the radio transmission
> between the Dev-UE and the RGW-eNB. ". Do you mean: "In one form of
> deployment, the SCHC functionalities may be used over the radio transmission
> between the Dev-UE and the RGW-eNB only"? Note that though I try and have a
> feeling of what you mean to say, I cannot really parse the rest of the
> paragraph. Please consider rewriting the whole paragraph for clarity;
> possibly indicating where the SCHC GW is positioned. Please add references to
> the next sections where the cases are discussed in more details (like say
> "more in ..." or "see .. for more").
> 
> 8) section " 4.1.  Use of SCHC over the Radio link ". I understand that the
> constraints of the radio link apply even if the SCHC GW is located further
> down in the core, correct? So most of the text in that section is generic.
> 
> 9) "However, given the case in the future, SCHC fragmentation may be used.  "
> does not parse either.
> 
> 10) " The Appendix gives more details". This formulation or similar is used
> without a link to the section in the appendix where the additional
> information is given. A forward link would be useful.
> 
> 11) " 4.2.1.  SCHC Entities Placing" title is half informative. Maybe add "
> in the SCHC over NAS case" or something?
> 
> 12)  In this scenario, SCHC may reside in the Non-Access Stratum (NAS)
> protocol layer.  "
> why "may" ? I thought the whole section 5.2 is a about this? So it just does
> not may do, correct?
> 
> 13) " Because the NAS protocol already uses RoHC it can adapt SCHC for header
> compression too. ". Please rephrase. Who is it? what adaptation is needed? Or
> do you mean use/adopt?
> 
> 14) " SCHC for IoT applications MUST be considered to improve the device's ".
> This seems to indicate what 3GPP MUST do. Certainly you mean something else?
> Please rephrase.
> 
> 15) "SCHC Context initialization RRC (Radio Resource Control)". Aren't you
> missing a ":" sign? The whole item is unreadable without it, true for all the
> next listed items.
> 
> 16) "Implying that" -> "This implies"; " might use provision sets": Might?
> What if not?
> 
> 17) " The minimum physical" -> "The smallest physical" otherwise you have
> different minimum values.
> 
> 18) Since a TB of 88bits has very little room for SCHC, is that room enough
> to ensure that " SCHC overhead should not exceed the available number of
> effective bits of the smallest physical TB available "? How should we read
> that "should" written in lowercase? Do you mean that it is preferable? Is it
> a MUST? What happens if not?
> 
> 
> 19) 4.2.2. applied to 4.1 and 4.2 so it is weirdly placed. Maybe it should be
> 4.3? also the title seems to be missing "cases" in the end. Note my remark on
> 4.1.1 where the same is mostly true as well.
> 
> 20) 4.3.2, same comment on the listed items that we're missing ":" though in
> some cases there is a "."
> 
> 21) "capillarity gateway" -> "capillary gateway"
> 
> 22) " mode is even desirable ": what do you mean by "even" ?
> 
> 23) " is recommended": lowercase? Also a formulation like " WINDOW_SIZE is
> recommended to be 2^N-1. " (multiple cases) feels strange. Whazt about " a
> WINDOW_SIZE of 2^N-1 is RECOMMENDED. "
> 
> 24) "Table 10.5.163a in {3GPP-TS_24.088}": Link failure, probably an issue
> with the source markup.
> 
> 
> 
> Voila! Many thanks for the appendices as well, they are really useful. Please
> make sure they remain in the final version.
> 
> Keep safe;
> 
> Pascal (shepherd hat on)
> 
>