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
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
