Dear Ana,
Thank you for the responses to my comments and for the improvements to the document.
Please find responses to some of your points and some suggestions inline:
On 25.02.20 23:26, Ana Minaburo wrote:
Minor issues:
Abstract
To make the abstract more self-contained, I suggest adding a brief description
of what SCHC is, then stating explicitly that so far SCHC has been defined for
UDP and IPv6, and this document defines it for CoAP. Then the abstract can keep
the two examples of how CoAP presents some unique challenges for using SCHC,
but it should clearly say that these are examples, as Section 3 later lists
more differences. Finally, perhaps it's worth making the last sentence more
concrete to say how the document addresses these challenges. Maybe something
like: The document gives guidance on how to apply SCHC to flexible headers and
how to leverage the asymmetry for more efficient compression rules.
Ana: Thanks for this input, the new version of the abstract is:
"This draft defines the way SCHC (Static Context Header Compression) header compression can be applied to CoAP protocol. SCHC is a header compression mechanism adapted for constrained devices. SCHC uses a static description of the header to reduce the redundancy and the size of the information in the header. While the RFC8724 describes the SCHC compression and fragmentation framework, and its application for IPv6/UDP headers, this document applies the use of SCHC for CoAP headers. The CoAP header structure differs from IPv6 and UDP one since CoAP uses a flexible header with a variable number of options, themselves of variable length. The CoAP protocol messages format is asymmetric: the request messages have a header format different from the one in the response messages. This specification gives guidance on how to apply SCHC to flexible headers and how to leverage the asymmetry for more efficient compression Rules."
TE: Thanks, this makes the abstract much more self-contained. Some suggested nits here:
"can be applied to CoAP protocol" --> "can be applied to the CoAP protocol"
"While the RFC8724 describes" --> "While RFC8724 describes"
"differs from IPv6 and UDP one" --> "differs from IPv6 and UDP" or "differs from the IPv6 and UDP one"
"The context(s) is(are) known by both ends before transmission." - As someone
not yet familiar with SCHC, it would be really helpful to have one or two
sentences here explaining how this usually works. Are the contexts typically
configured on the devices when installing the application? Are contexts
exchanged out of band and/or using some kind of protocol exchange?
Ana: The way the context is configured or exchanged is out of the scope of this document because we are trying to explain the problem of CoAP header compression.TE: I see. Could you briefly point this out in the document, i.e., say "The way the context is configured or exchanged is out of the scope for this document", please?
"[I-D.ietf-lpwan-ipv6-static-context-hc] defines the use of a message direction
(DI) in the Field Description, which allows a single Rule to process message
headers differently depending of the direction." - I think here it makes sense
to say how this point relates to the point before, that CoAP is asymmetric. Is
this in conflict, so it makes SCHC more difficult to use for CoAP? Or does this
just mean that the SCHC rules have to be different for CoAP?
Ana: It is not a conflict neither more difficult nor different, as SCHC includes the DI in the Rule the CoAP asymmetric problem is solved. Because the value in DI will be used to define which fields are in which direction in the same Rule. So instead of describing two Rules, one for each direction, we only have to define one Rule for both directions, paying attention to give the correct field description.TE: Thanks for the explanation. Maybe here it's worth rephrasing "which allows a single Rule to process message headers differently depending of the direction" to make this more explicit.
"The direction allows splitting in two parts the possible values for each
direction in the same Rule." - Sentence is hard to parse. What does "the
direction" refer to here - a part of the rule? the direction the packet is sent?
Ana: Direction is the Request or Response format (up, down, bidirectional). Yes is part of the Rule and yesit describes the direction the packet is sent from client to server or from server to client, request/response format headersTE: I see. Suggested new phrasing:
"The direction allows splitting the range of values in two parts, one for each direction, and allows the same rule to handle traffic in both directions."
"In IPv6 and UDP, header fields have a fixed size and it is not sent." - What
does "it" refer to here? The size?
Ana: Yes, each field in the header has a length in bits or bytes; when a field in the header format has a fixed length, you know it, and it has been defined in the protocol document.Example: The IPv6 version is 4-bit length and the value is 6, so in SCHC field description this field will have a size of 4 bits and the target value will be 6TE: I see. Suggested new phrasing:
"In IPv6 and UDP, header fields have a fixed size, which is not sent."
Section 4.5
"Token Value size cannot be defined directly in the rule in the Field Length
(FL). Instead, a specific function designated as "TKL" MUST be used and length
does not have to be sent with the residue. During the decompression, this
function returns the value contained in the Token Length field." - Why can the
Token Value size (is this the length of this header field?) not be defined
directly? And what is this specific function "TKL" supposed to do? Is there a
reference for it? From this sentence, it's also not clear why length does have
to be sent.
Ana: Token is defined through two CoAP fields, Token-Length in the mandatory header and Token-Value directly following the mandatory CoAP header.Token Length is processed as any protocol field. If the value does not change, the size can be stored in the TV and elided during the transmission. Otherwise, it will have to be sent in the compression residue.Token Value MUST not be sent as a variable-length residue to avoid ambiguity with Token Length. Therefore, Token Length value MUST be used to define the size of the residue.A specific function designated as "TKL" MUST be used in the Rule. During the decompression, this function returns the value contained in the Token Length field.TE: Makes sense. I suggest adding this explanation to the document.
I'm looking forward to the next revision.
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.
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.
Best,
Theresa
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
