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 yes > it describes the direction the packet is sent from client to server or > from server to client, request/response format headers TE: 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 6 TE: 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. Best, Theresa
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
