Subject: [lp-wan] review of draft-ietf-lpwan-schc-over-nbiot-03

From: Ivaylo Petrov <[email-masked]>
Date: Sat, 8 Aug 2020 23:23:04 +0200

Dear all,

This is my review of draft-ietf-lpwan-schc-over-nbiot-03. I believe with a
few clarifications and additions and some editorial changes it will be
ready for WGLC.

== Comments

* Sec 2 does not use the default terminology section template that
references RFC2119 and RFC8174.
* I think the recommendation for IETF documents is to use IETF terminology
wherever possible, whereas in this one 3gpp one is used. For example user
equipment is used instead of end device
* I would have expected RFC8724 to be  a normative reference
* Security considerations section appears to be rather short. Please
consider adding more information at the very least referencing RFC8724
together with the 3gpp reference, but probably also mentioning possible
outcomes of misconfigurations, are there other elements that need to be
properly configured to ensure proper functioning - firewalls, API rate
limiters, etc.

== Nits and editorial changes

* In sec 1
  - unusual reference formatting that could bring confusion in:
    The Static Context Header Compression (SCHC) {RFC8724} defines a
  - s/(LPWAN) networks defined in [RFC8376]/(LPWAN) networks as
   defined in [RFC8376].
  - s/bring Internet connectivity to the node within/bring
Internet connectivity to the nodes within/
  - In the same paragraph it seems that the header compression is used to
bring IP connectivity to all NB-IoT nodes. I thought there are modes that
support IP connectivity even now and without SCHC. If I have misunderstood
the statement, maybe it needs to be clarified.
* In sec 2 I could not find a definition of PLMN
* In sec 3
  - fig 1 has &nbsp; in the txt version of the document, which I believe
should not be there.
  - s/SMS without combined attach for NB-IoT only UEs/SMS without combined
attachment for NB-IoT only UEs/
* In sec 4
  - There is a reference to a terminal that is not clear - is the end
device what was meant?
  - s/backwards compatible/backward compatible/
 * In sec 5.1
  - it is said "reliability, segmentation and concatenation". Consider
defining what exactly is meant here.
  - s/constrains/constraints/
  - s/User Plane is comprised by Packet Data Convergence/User Plane is
comprised of Packet Data Convergence/
* I think on a few occasions utilizing should be replaced by using
* Sec 5.2.1
  - s/The same principles than for user plane transmissions applies here as
well./The same principles as for user plane transmissions apply here as
well.
* Sec 5.3.1 and elsewhere
  - s/in similar fashion/in a similar fashion/ or similarly

* Sec 5.3.2

  - "The number of rules in a context are defined by the network operator in
these scenarios." appears to imply that operators need to know the traffic.
Is that strictly necessary? Could they in the future have a way to be
discovered?
  - I could not understand. Maybe it could be rephrased
    For devices acting as gateways of other devices

   several rules that match the diversity of devices and protocols used
   by the devices associated to the gateway.

  - in the text above s/associated to/ associated with/
  - s/Meanwhile than simpler/Meanwhile simpler/
* Sec 5.3.3
  - s/In the other hand/On the other hand/
  - s/multiple parameters the of/multiple parameters of/
  - s/take in account/take into account/
* Sec 6
  - s/network does not has information/network does not have information/
* Sec 6.1
  - s/Sevices/Services/
  - s/a API/an API/
* Sec 6.2.2
  - s/Even when the transmissions content are/Even when the content of the
transmissions are/
  - s/number of transmission/number of transmissions/
* Sec 6.2.3
  - s/set prior the/set prior to the/
  - s/be follow when/be followed when/
* Sec 6.2.4 - how was 1358 calculated?
* Sec 6.3 is not clear to me
  - and to replace

Nevertheless additional

   considerations for more complex cases are mentioned in the next

   subsection to be taken in account.

by

Nevertheless additional

   considerations for more complex cases are mentioned in the next

   subsection.

- s/ be taken in account/ be taken into account/
6.3.1 I don't understand the meaning of this sentence and why 1b - do we
fragment everything over 1 byte?

In some cases, it is even desirable to keep

   track of all the SCHC packets delivered, in that case, the

   fragmentation function could be active for all packets transmitted by

   the applications (SCHC MAX_PACKET_SIZE == 1 Byte)

- s/Depending of/Depending on/

- s/identifyed/identified

- s/packets as {RFC8724} allows it/packets as allowed by {RFC8724}/

+ the formatting of the reference is strange.

* Sec 6.3.2

- s/two configuration/two configurations/

- s/the best the transfer block/best the transfer block/

  - could you explain where the following claim comes from

*   The Header size*

*   needs to be multiple of 4 and the Tiles can keep a fix value of 4 or*

*   8 bits to avoid the need of padding.*

- s/configuration may ne used/configuration may be used/

- s/minise/minimize/

Best regards,
Ivaylo