Hi Laurent,
Thanks for the new revision, which
greatly improves the document.
However, I have a few comments on your
new text:
In the text at the beginning of Section
3, you added text to give more context, which is a great idea.
However, I'm not sure about the first
sentence:
"SCHC with CoAP will be used exactly
the same way as it is applied in any protocol as IP or UDP with
the difference that the fields description needs to be defined
based on both headers and target values of the request and the
responses."
To me the last part of this sentence
sounds like for CoAP you have to define a rule to match both a
request and a reply packet, so you would have to match two packets
(in a single rule?). Is this really the case? I thought a single
rule always matches one packet, but maybe I misunderstood. In any
case, could you rephrase this to make it more clear, please?
Also, I saw some typos and grammar
errors in Section 3:
s/optmize/optimize/
s/To performs/To perform/
s/TV might be use/TV might be used/
s/Resulting in a smaller compression
residue./This results in a smaller compression residue./
Some more nits in Section 7.3:
s/TheSCHC/The SCHC/
s/alreadypresent/already present/
s/in section Section 4/in Section 4/
Regarding the Security Considerations, thanks for discussing this
in your interim meeting and for adding text.
I'll leave the judgment of whether any security aspects are still
missing etc. to the Secdir reviewer and/or ADs.
Regarding the text you added:
On 05.03.20 23:50, Laurent Toutain
wrote:
For the security section after
discussion in the intermin meeting, we propose to add this:
This document does not have any more Security
consideration than the ones already raised on
{{rfc8724}}. Variable length residues may be used to
compress URI elements. They cannot produce a packet
expansion either on the LPWAN network or in the Internet
network after decompression. The length send is not used
to indicate the information that should be reconstructed
at the other end, but on the contrary the information
sent as a Residue. Therefore, if a length is set to a
high value, but the number of bits on the SCHC packet is
smaller, the packet must be dropped by the decompressor.
Overall, I find this paragraph difficult to follow.
What is the relationship between the first sentence and the rest
of the paragraph?
First you say there are not more Security Considerations, then you
say that there are?
Please add a sentence that provides a context for your
statements. Is this a consideration that implementations need to
be aware of in case variable residues are used? Or is this a
suggestion to use variable length residues to make something
more/less secure?
What is a packet expansion? I haven't seen this term in the rest
of the document. Is it a problem if they (the variable length
residues or the URI elements?) cannot produce a packet expanision?
This sentence is hard to parse and seems gramatically broken: "The
length send is not used to indicate the information that should be
reconstructed at the other end, but on the contrary the
information sent as a Residue."
OSCORE compression is also based on the same
compression method described in {{rfc8427}}. The size of
the Initialisation Vector residue size must be
considered carefully. A too large value has a impact on
the compression efficiency and a too small value will
force the device to renew its key more often. This
operation may be long and energy consuming.
"This operation may be long and energy consuming." - Which
operation? The previous sentence talks about the size of an
initialization vector, not about an operation.
Thanks,
Theresa
