Re: [lp-wan] I-D Action: draft-ietf-lpwan-coap-static-context-hc-08.txt

[<[e-mail]>]

Hello Laurent, all,

Last time, I hadn't gone through the OSCORE section.
I took the time to review it, and since –08 was issued in the meantime, I reviewed the OSCORE section of that one.
Here are my comments :
- section 6.5 OSCORE: "Their size SHOULD be reduced using the MSB matching operator". I'm not sure exactly the size of what you want to reduce here. Each of the 4 OSCORE  fields listed above? As described later in the document, you also suggest using equal+not-sent for the flags, for example.
- section 7.1 Figure 5: the "CoAP version" line in the table is duplicated. The MO for the Uri-Pathshows "equal 1"
- section 7.1 : "with a least the 9 most significant bits" —> you mean "7  most signifiant bits"?
- section 7.1 Figure 6. Quite hard to understand. I suggest you draw horizontal lines in the POST packet drawings, as well as vertical lines so that byte alignement shows. The code should be 0.02 instead of 0.01 on both sides, and TKL should be 0 on both sides.
- section 7.2 Figure 7: The current legend is confusing. I suggest "A CoAP message is broken into an OSCORE outer header and plaintext".
- section 7.2 Figure 8: the bottom box shows "Encrypted Inner Header and Payload". This is not quite true, there is the authentication tag as well.
- section 7.3 : "An example is given with a GET Request and its consequent CONTENT Response". Please mention "from a device-based CoAP client to a cloud-based CoAP server". This becomes important when we look at rules with the directional field descriptors.
- section 7.3 Figure 15: the option should be 0xd808…., it seems to me.
- section 7.3 Figure 20: the uplink CoAP Code Target Value should be 1 (GET). The dw CoAP Code TV shows a list, but the MO is equal. From the example, which seems to have one bit of residue for the code, it seems you want match-mapping/mapping-sent.

I also have a few nits and proposed text improvements, I'll submit a Pull Request on GitHub.
Best regards

Dominique

De : Laurent Toutain <[e-mail]<mailto:[e-mail]>>
Date : Sunday 12 May 2019 19:11
À : Dominique Barthel <[e-mail]<mailto:[e-mail]>>
Cc : "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Objet : Re: [lp-wan] I-D Action: draft-ietf-lpwan-coap-static-context-hc-06.txt



On Fri, May 3, 2019 at 6:34 PM <[e-mail]<mailto:[e-mail]>> wrote:
Dear authors,

I've read draft-ietf-lpwan-coap-static-context-hc-06 .

thank you very much Dominique,

Here are a few comments so far. I haven't seriously read OSCORE and
examples yet.
Overall, you are not using MUST and SHOULD. Is this intended because of
the informational status?

yes, rule gives a lot of flexibility and the compression mechanism depends of the
usage. The goal of the document is to explain how to apply compression to CoAP
protocol.

Thanks for the correction, this document is in the standard track not informational.



Technical
- I did not understand the last paragraph of 4.5 CoAP Token fields.

In SCHC when you don't know the field size at the rule creation, you can define the field as variable.
For instance :
FID.                    FL MO.     CDA
CoAP.URI-path. var ignore value-sent

in that case, the var keyword in the Field Length will make the compression send the length (in byte)
before the value of the field.

A CoAP Token has almost the same behavior as a URI-path, but the length and the value are stored
at 2 differents place in the CoAP Header.

The paragraph says that instead of var function to describe the length, a tkl function must be used. The
tlk function indicates that the length is stored in the CoAP TKL field. The receiver must use this value
to determine the value sent on the radio.


- I did not understand the first sentence of 5.3.1, Variable length
Uri-Path and Uri-Query. Do you mean "not" known?

yep, changed.

Also, I think the
following sentence no longer applies "and the LSB CDA must not carry any
value."

yes, that a remain of an older version of SCHC rule, suppressed in the draft


- 6.3 No-Response: "If the value is not known, ...". I guess you mean the
opposite.

right, not has been removed

- 6.4 Time Scale: "If the value is not known, ...". I guess you mean the
opposite.



idem

Editorial
- Section 1 Introduction: "The context is said static since the field
description composing the Rules and the context are not learned during the
packet exchanges but are previously defined." Context used twice, sentence
needs rewriting.

suppressed context: old reference.


- many more English writing nits, I will do a Pull Request on GitHub.

we did the merge.

Best regards
Dominique

Le 05/02/19 15:00, « lp-wan on behalf of [e-mail]<mailto:[e-mail]> »
<[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> a écrit :

>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>This draft is a work item of the IPv6 over Low Power Wide-Area Networks
>WG of the IETF.
>
>        Title           : LPWAN Static Context Header Compression (SCHC)
>for CoAP
>        Authors         : Ana Minaburo
>                          Laurent Toutain
>                          Ricardo Andreasen
>       Filename        : draft-ietf-lpwan-coap-static-context-hc-06.txt
>       Pages           : 29
>       Date            : 2019-02-05
>
>Abstract:
>   This draft defines the way SCHC header compression can be applied to
>   CoAP headers.  The CoAP header structure differs from IPv6 and UDP
>   protocols since CoAP
>   use a flexible header with a variable number of options themselves of
>   a variable length.  The CoAP protocol is asymmetric in its format
>   messages, the format of the header packet in the request messages is
>   different than in the response messages.  Most of the compression
>   mechanisms have been introduced in
>   [I-D.ietf-lpwan-ipv6-static-context-hc], this document explains how
>   to use the SCHC compression for CoAP.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-lpwan-coap-static-context-hc/
>
>There are also htmlized versions available at:
>https://tools.ietf.org/html/draft-ietf-lpwan-coap-static-context-hc-06
>https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-coap-static-context
>-hc-06
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-ietf-lpwan-coap-static-context-hc-
>06
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>_______________________________________________
>lp-wan mailing list
>[e-mail]<mailto:[e-mail]>
>https://www.ietf.org/mailman/listinfo/lp-wan


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.