Subject: [lp-wan] New version of draft SCHC compression and fragmentation

From: Ana Minaburo <[email-masked]>
Date: Fri, 16 Jun 2017 10:25:24 +0200

Hello LPWANers,

I hope you are all fine!

I want to announce that we have published a new version of the draft SCHC compression 	and fragmentation. We would like to receive your comments and questions.

Thanks
Ana

---

From: Juan Carlos Zuniga <[email-masked]>
Date: Wed, 21 Jun 2017 16:31:36 +0000

Hi Ana, all,

Thanks for addressing the previous comments in this new version.

As mentioned during the call, I have some new minor comments in preparation for the WGLC:

6.2. value-sent CDA
The value-sent action is generally used when the field value is not
known by both Compressor and Decompressor. The value is sent in the
compressed message header. Both Compressor and Decompressor must
know the size of the field, either implicitly (the size is known by
both sides) or explicitly in the compressed header field by
indicating the length. This function is generally used with the
"ignore" MO.
The compressor sends the Target Value stored on the rule in the
compressed header message. The decompressor restores the field value
with the one received from the LPWAN

I believe the second paragraph (starting from "The compressor...") is not needed, as the "actual field value" should be sent, and not the TV. Right? The two paragraphs seems to be contradictory.

6.5. DEViid, APPiid CDA
These functions are used to process respectively the Dev and the App
Interface Identifiers (Deviid and Appiid) of the IPv6 addresses.
Appiid CDA is less common, since current LPWAN technologies frames
contain a single address.
The IID value can be computed from the Device ID present in the Layer
2 header. The computation is specific for each LPWAN technology and
depends on the Device ID size.
In the downstream direction, these CDA are used to determine the L2
addresses used by the LPWAN.

I would suggest changing the last sentences as: "The computation is specific for each LPWAN technology and may depend on the Device ID size.
In the downstream direction, these CDA may be used to determine the L2 addresses used by the LPWAN."

7.7.2. IPv6 source and destination IID
If the DEV or APP IID are based on an LPWAN address, then the IID can
be reconstructed with information coming from the LPWAN header. In
that case, the TV is not set, the MO is set to "ignore" and the CDA
is set to "DEViid" or "APPiid". Note that the LPWAN technology is
generally carrying a single device identifier corresponding to the
DEV. The SCHC C/D may also not be aware of these values.
If the DEV address has a static value that is not derivated from the
EUI-64, then TV contains the value, the MO operator is set to "equal"
and the CDA is set to "not-sent".

Since not all technologies use EUI-64 (e.g. NB-IoT, Sigfox) I would suggest changing the last paragraph as follows: "If the DEV address has a static value that is not derived from an IEEE EUI-64, then TV contains the actual DEV address value, the MO operator is set to "equal" and the CDA is set to "not-sent"."

Best,

Juan Carlos

From: lp-wan [mailto:[email-masked]] On Behalf Of Ana Minaburo
Sent: June 16, 2017 4:25 AM
To: lp-wan <[email-masked]>
Cc: Pascal Thubert (pthubert) <[email-masked]>; Alexander Pelov <[email-masked]>
Subject: [lp-wan] New version of draft SCHC compression and fragmentation

Hello LPWANers,

I hope you are all fine!

Thanks
Ana

_______________________________________________
lp-wan mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lp-wan