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

[Ana Minaburo <[e-mail]>]

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