Subject: [lp-wan] Place of the position value for CoAP options (SCHC)

From: Philippe Clavier <[email-masked]>
Date: Mon, 10 Apr 2017 16:23:44 +0000

Dear all,

I am currently working on an implementation for SCHC of IPv6/UDP/CoAP over LoRaWAN following the drafts "draft-ietf-lpwan-ipv6-static-context-hc-02" and "draft-ietf-lpwan-coap-static-context-hc-01".

While working on the implementation it occurred to me that it might be good to consider taking the position value added in the Matching Operator for the CoAP options and put it directly in the Field ID. My main reason for thinking this comes from the way the compressor/decompressor I have implemented works and how  this change simplifies  the coding.

There are two main reasons why the code gets more complicated and these are the following:

In the implementation made in a LoPy, the rules are stored in dictionaries (Python) and there cannot be two keys with the same name in a dictionary (this is the same thing for objects in Javascript), so for a start the FID of repeatable options must have different names.

The other reason is that if the FID is the same for repeatable options, once the Matching Operator has been matched for that field in a rule, each position for that option must also be treated in a different way and this adds complexity to the processes of compression/decompression. While, on the other hand, if each FID is different for repeatable options these fields can be treated as completely different fields with no relation to other appearances of the same option and no extra operations should be carried out.

Finally, I also get the feeling that it gives a clearer conceptions for the use of the position value.

Regards,

Philippe Clavier

---

From: Laurent Toutain <[email-masked]>
Date: Wed, 12 Apr 2017 15:45:21 +0200

Hi Philippe,

Thank you for this proposal, I like it. It simplifies two things in the
current proposal:
- MO has just a single value argument
- it will be easier to locate a rule entry when there is multiple instances
of it. This "field id value"  becomes a key.

Laurent

On Mon, Apr 10, 2017 at 6:23 PM, Philippe Clavier <[email-masked]>
wrote:

> Dear all,
>
>
> I am currently working on an implementation for SCHC of IPv6/UDP/CoAP over
> LoRaWAN following the drafts "draft-ietf-lpwan-ipv6-static-context-hc-02"
> and "draft-ietf-lpwan-coap-static-context-hc-01".
>
>
> While working on the implementation it occurred to me that it might be
> good to consider taking the position value added in the Matching Operator
> for the CoAP options and put it directly in the Field ID. My main reason
> for thinking this comes from the way the compressor/decompressor I have
> implemented works and how  this change simplifies  the coding.
>
>
> In the implementation made in a LoPy, the rules are stored in dictionaries
> (Python) and there cannot be two keys with the same name in a dictionary
> (this is the same thing for objects in Javascript), so for a start the FID
> of repeatable options must have different names.
>
> The other reason is that if the FID is the same for repeatable options,
> once the Matching Operator has been matched for that field in a rule, each
> position for that option must also be treated in a different way and this
> adds complexity to the processes of compression/decompression. While, on
> the other hand, if each FID is different for repeatable options these
> fields can be treated as completely different fields with no relation to
> other appearances of the same option and no extra operations should be
> carried out.
>
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan
>
>