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

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

Hello Ana

All good please publish!
Note that I did not receive Edgard’s responses on the call for IPR and the call to be on front page.
Could you please sync with him?

Keep safe;

Pascal


From: Ana Minaburo <[e-mail]>
Sent: samedi 9 juillet 2022 23:38
To: Pascal Thubert (pthubert) <[e-mail]>
Cc: [e-mail]; lp-wan <[e-mail]>
Subject: Re: Shepherd review of draft-ietf-lpwan-schc-over-nbiot-09.txt

Hello,
You will find the text version before submission

Ana

On Sat, Jul 9, 2022 at 11:36 PM Ana Minaburo <[e-mail]<mailto:[e-mail]>> wrote:
Hello Pascal,

We are almost there, thank you for your inputs just some comments and I push the draft-11 before on Monday afternoon.
See my comments below

Ana

On Thu, Jun 30, 2022 at 1:43 PM Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>> wrote:
A few more nits:

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

Ana: Done, thanks

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

    What are (1) and (2)?
Ana: The second PDU is larger than 1600 bytes, so here the RLC will segment the PDU. So (1) and (2) are both segments.

Keep safe;

Pascal

> -----Original Message-----
> From: Pascal Thubert (pthubert)
> Sent: mercredi 29 juin 2022 13:48
> To: [e-mail]<mailto:[e-mail]>
> Cc: lp-wan <[e-mail]<mailto:[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.
>
Ana: done, this is new feature for md.

> 2) Terminology: define PLMN; also NGW-SGW is defined but the figure uses NGW-
> CSGW: please align.
Ana: Done
>
> 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.
>
Ana: Done

> 4) References: typo in the title of TR33203. Also add references to OMA and
> OneM2M
Ana: Done
>
> 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.
>
Ana: Done, I deleted data
> 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?
>
Ana: The use of a bigger MTU will produce some inefficiencies, the 1358 bytes is only a recommendation, you can use a bigger one, but you may increase the overhead.

> 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").
>
Ana change to:
  Over the radio transmission, see section Section 5.1.  The Dev-UE and the RGW-eNB
   may use the SCHC functionalities.  Alternatively, the packets
   transmitted over the path can use SCHC.  When the transmissions go
   over the NGW-MME or NGW-SCEF, the NGW-CSGN uses the SCHC entity.
   See sections Section 5.2 and Section 5.4.  The functions need to be standardized
   by 3GPP.

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.
Ana: No, this text is not generic. The problem is that it depends where you put SCHC the protocol stack is different, that's why we create the use-cases. In the case of the Radio link, SCHC may be located in the PDCP layer so you get MAC/RLC/PDCP/PDU. When you are in the NAS, SCHC is in the NAS/RRC and your packet is MAC/RLC/RLC data. And when you are E2E your packet is MAC/RLC/SCHC packet.

9) "However, given the case in the future, SCHC fragmentation may be used.  " does not parse either.
Ana: Change

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.
Ana: I've put all the cross references

11) " 4.2.1.  SCHC Entities Placing" title is half informative. Maybe add " in the SCHC over NAS case" or something?
Ana: I correct the carriage returned the points...

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?
Ana: Yes, I 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?

Ana: Done

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.
Ana: Done

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.
Ana: Yes, done

16) "Implying that" -> "This implies"; " might use provision sets": Might? What if not?
Ana: The network operator must define the rules, of not SCHC is not used. I have change the text:
The network operator in these scenarios defines the number of rules
   in a context.  The network operator must be aware of the IP traffic
   the device will carry.  Implying that the network operator might use
   provision sets of rules compatible with the device's use case.  For
   devices acting as gateways to other devices, several rules may match
   the diversity of devices and protocols used by the devices associated
   with the gateway.  Meanwhile, simpler devices (for example, an
   electricity meter) may have a predetermined set of fixed rules and
   parameters.  Additionally, deploying IPv6 addresses may force
   different rules to deal with each case.

17) " The minimum physical" -> "The smallest physical" otherwise you have different minimum values.
Ana: ok, done

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?
Ana:  There is not a big problem here because RLC layer will do segmentation, is only the most optimal.

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.
Ana: done

20) 4.3.2, same comment on the listed items that we're missing ":" though in some cases there is a "."
Ana: Done
21) "capillarity gateway" -> "capillary gateway"
Ana: Done

22) " mode is even desirable ": what do you mean by "even" ?
Ana: change even by could be
"... the ACK-on-Error mode could be desirable to keep track of all
   the SCHC packets delivered. ..."

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. "
Ana: Done

24) "Table 10.5.163a in {3GPP-TS_24.088}": Link failure, probably an issue with the source markup.
Ana: Done, I correct the link