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

[Ana Minaburo <[e-mail]>]

Hello,
You will find the text version before submission

Ana

On Sat, Jul 9, 2022 at 11:36 PM Ana Minaburo <[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]> 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
>
>
>