Theresa, thanks for your review. Authors, thanks for your responses. I entered
a No Objection ballot pointing out the remaining issues with the security
considerations.
Alissa
> On Mar 9, 2020, at 11:26 PM, Theresa Enghardt <i...@tenghardt.net> wrote:
>
> 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
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
