Re: [Iot-directorate] Iotdir telechat review of draft-ietf-lpwan-schc-over-lorawan-10

["Eric Vyncke (evyncke)" <[e-mail]>]

Thank you very much for the review.

I will use it when balloting on this document

-éric

-----Original Message-----
From: JADHAV Rahul via Datatracker <[e-mail]>
Reply-To: JADHAV Rahul <[e-mail]>
Date: Sunday, 20 September 2020 at 20:45
To: "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Iotdir telechat review of draft-ietf-lpwan-schc-over-lorawan-10
Resent-From: <[e-mail]>
Resent-To: <[e-mail]>, <[e-mail]>, Pascal Thubert <[e-mail]>, <[e-mail]>, Eric Vyncke <[e-mail]>, <[e-mail]>, Dominique Barthel <[e-mail]>, <[e-mail]>
Resent-Date: Sunday, 20 September 2020 at 20:45

    Reviewer: JADHAV Rahul
    Review result: Ready with Issues

    Dear authors of schc-over-lorawan,

    Thank you for this work.
    Following is my review handled as part of IoT-DIR review process:

    Section 4:
    [RJ] The architecture shows "Join Server" but the section has no explanation
    for it.

    Section 4:
    "The Network Gateway (NGW) is the interconnection node between the Radio
    Gateway and the Internet." [RJ] It is mentioned that NGW is the gateway to the
    Internet but the SCHC C/D and F/R is handled on the LoRaWAN application server.
    How would the compressed packets be sent out to the Internet from NGW? [RJ] In
    the last para of the section it is mentioned that "(SCHC gateway) acts as the
    first-hop IP router for the device. This means that the NGW is not the
    interconnection node between the RGW and the Internet.

    Section 4:
    [RJ] The terms used in the architecture figure 3 and the document are
    different/confusing. For e.g., the figure mentions Application Server which is
    referred to as SCHC Gateway in the overall document. The figure mentions
    Network Server but is referred to as Network Gateway (NGW) in the overall
    document. As a reader, I wanted to use this architecture diagram as a ref but
    the terms mentioned in the diagram are different from those used in the draft
    elsewhere.

    Section 4.1:
    "The lower the downlink latency, the higher the power consumption."
    [RJ] I didn't understand why lower latency could result in higher power
    consumption. I think the intention was to use either downlink frequency or
    listen periodicity as a driver for higher power consumption.

    Section 4.3/4.4:
    [RJ] The terms "frames" and "messages" are used interchangeably. Would be
    better to use a fixed term, or else clarify these terms in the document.

    Section 4.6:
    [RJ] FRMPayload is not defined anywhere.

    Section 5.1:
    [RJ] I believe the term "fragmented datagram" should be used in place of
    "fragmentation datagram" in the whole of this para.

    Section 5.1:
    "It uses another FPort for data downlink and its associated SCHC control
    uplinks, named FPortDown in this document." [RJ] Just for my understanding, the
    FPortUp and FPortDown are disjoint sets i.e., an FPort part of FPortUp set
    cannot be part of the FPortDown set. Is this correct? If yes, can we make it
    explicit in the document?

    Section 5.2:
    "RuleID = 22 (8-bit) for which SCHC compression was not possible..."
    [RJ] I believe RuleID = 22 is provisioned for LoRaWAN messages which are sent
    uncompressed i.e., if a device wants to send an uncompressed IPv6 then it can
    use this RuleID. Is this correct? If yes, can we state this sample use-case for
    RuleID=22?

    Section 5.3:
    "There is a small probability of IID collision in a LoRaWAN network, if such
    event occurs the IID can be changed by rekeying the device on L2 level (ie:
    trigger a LoRaWAN join)." [RJ] As I understand, IID collision can be detected
    only by the Network Gateway. How would the Network Gateway initiate a LoRaWAN
    join? Section 4.4 defines that only the end device can initiate a JoinRequest
    frame.

    Section 5.6.1:
    Please provide a reference to Section 8.2.4 in RFC 8724 for DTag.

    Section 5.6.2:
    The term Tile is not defined in the document nor is there a ref to RFC 8724.
    Better to redefine it here or at least have a ref to RFC 8724.

    Section 5.6.3:
    The term "applicative uplink" is used in this and subsequent sections. Are you
    referring to the application uplink? Not sure of what applicative means in the
    context?

    Section 5.6.3.5.1:
    "LoRaWAN layer will respect the regulation if required."
    I believe the local spectrum regulation is what is referred here, but am not
    sure.

    Section 6: Security Considerations
    The section mentions the use of IID for privacy protection and the use of
    AES-128 encryption for payload encryption. However, it is not clear to me as to
    how the replay protection can be handled i.e. if an attacker replays the data
    sent by any other node previously, how can it be protected? I believe this is
    handled as part of the LoRaWAN mac layer?

    Minor Nits:

    Section 3:

    Known information are part of the "context".
    Known information is of the "context".

    This component called SCHC...
    This component is called SCHC...

    ...the RG is called a Gateway...
    ...the RGW is called a Gateway...

    Section 4:

    SCHC C/D and F/R are LoRaWAN Application Server;
    SCHC C/D and F/R are handled by LoRaWAN Application Server;

    Section 4.4:
    ...contains (amongst other fields) the major network's settings...
    ...contains (amongst other fields) the network's major settings...

    Section 4.7:
    ...a packet send over LoRaWAN radio link...
    ...a packet sent over LoRaWAN radio link...

    Section 5.2:
    In order to improve interoperability RECOMMENDED fragmentation....
    In order to improve interoperability, RECOMMENDED fragmentation....

    Section 5.6.2:
    In that case the device is the fragmentation transmitter, and the SCHC gateway
    the fragmentation receiver. In that case, the device is the fragment
    transmitter, and the SCHC gateway is the fragment receiver.

    Section 5.6.3.1: Figure title
    "including LoraWAN FPort"
    "including LoRaWAN FPort"

    Section 6: Section Title
    Security considerations
    Security Considerations