Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
I don't think we quite managed to catch all the collatoral damage from my previous discuss points on the -13. In particular, while Sections 5.x no longer attempt to discuss directionality of CoAP Options, there are some in-passing references to them in Section 3.1: - There's a claim that URI-Path (though, spelled as "URI-path") is not present in the response, which is incorrect. - There's a reference to a nonexistent "Content" option as being present only in a response, but the "Content-Format" option is allowed in both requests and responses. (See, e.g., the PUT method for use of Content-Format in a request.) - The "Accept" option is referenced as only being present in requests. This seems to be accurate as far as I can see in RFC 7252, though in light of the near-complete removal of such references from this document, perhaps it should also be removed. While the expanded security considerations do cover several important points, I think it's important to specifically state that the RFC 8724 procedures assume that SCHC is implemented on top of LPWAN technologies that implement security mechanisms. I think we also need to specify that either (a) this assumption remains for the CoAP usage of SCHC, or that (b) CoAP has use cases outside of LPWAN, and when SCHC is used in those non-LPWAN cases, the attacks (such as are now described in the -15) are more readily performed than in the secure LPWAN environment when no other integrity protection mechanism is in place for the compressed packets. As Francesca noted on the -13, we need to acknowledge that there are and will be in the future CoAP options that are not included in this document and provide some indication of how they might be handled. Whether that's to define new compression rules/guidance for them, always send them as full residuals, or some other behavior can be decided in the future on a per-option basis, but we can give some guidance here on how we plan to support extensibility of options. --- The -15 introduced some new text in the Introduction: CoAP is an End-to-End protocol at the application level, so CoAP compression requires to install common Rules between two hosts and IP It's not entirely clear to me that this is true, given that CoAP proxies are a first-class protocol feature. OSCORE is probably fair to describe as end-to-end, but CoAP itself may not be. Also, the new examples in Section 2 are sufficiently hard to follow that I can't be sure the figures and the prose descriptions are internally consistent. (See COMMENT for a few more specifics.)
Thank you for the updates in response to my comments on the -13; they do help. I have a smaller volume of comments this time around :) Abstract References are not allowed in the abstract, so you should probably just write out "RFC 8724". Introduction CoAP [rfc7252] is designed to easily interop with HTTP (Hypertext What does "designed to easily interop with" mean? CoAP and HTTP don't interoperate directly, given that they are different protocols... done. The context is known by both ends before transmission. The way the context is configured, provisioned or exchanged is out of the scope of this document. (editorial) I'd suggest rephrasing to something more like "The SCHC compression scheme assumes as a prerequisite that the static context is known to both endpoints before transmission." CoAP is an End-to-End protocol at the application level, so CoAP compression requires to install common Rules between two hosts and IP Routing may be needed to allow End-to-End communication. Therefore, SCHC compression may apply at two different levels, one to compress IP and UDP as described in [rfc8724] in the LPWAN network and another at the application level. These two compressions may be independent. I think you want to reframe this in terms of the potential for there to be multiple IP (UDP seems perhaps less likely?) entities processing the packet between CoAP entities that process the packet, and note that the IP compression may be removed by an intermediary in situations where configured to do so. The Compression Rules can be set up by two independent entities and are out of the scope of this document. In both cases, SCHC mechanism remains the same. (nit) I don't think "remains the same" is the best wording here; there are clearly going to be differences of some form between compression at the UDP layer and compression at the CoAP layer, even though the overall structure/procedures for compressing/decompressing at those layers are analogous to each other. A Matching Operator (MO) is associated to each header field description. The Rule is selected if all the MOs fit the TVs for all fields of the incoming header. I strongly suggest reiterating that the presence of a header field that does not have a corresponding MO in the Rule means that the Rule does not apply to that packet. After applying the compression there may be some bits to be sent, these values are called Compression Residues. nit: comma splice. Section 2 I think that these examples would benefit from a fair bit more description/discussion text. For example, if SCHC in Figure 1 is supposed to be compressing everything from IPv6 to CoAP, why is SCHC beween LPWAN and IPv6 (vs above IPv6), and why does the full stack still appear at the 'device'? If the Sender and Receiver are to be the device and App, then why is SCHC not apparent at the Receiver (app)? I can't find a consistent way to interpret the text and the figure. (Figures 2 and 3 have both dotted lines and dashed lines. Why are they different? Etc.) Section 3.1 o The CoAP protocol is asymmetric, the headers are different for a request or a response. For example, the URI-path option is nit: comma splice. o Headers in IPv6 and UDP have a fixed size. The size is not sent as part of the Compression Residue, but is defined in the Rule. Some CoAP header fields have variable lengths, so the length is also specified in the Field Description. For example, the Token RFC 8724 uses "Field Descriptor", not "Field Description". Section 5 the description of the Option by using in the Field ID the Option Number built from D-T; in TV, the Option Value; and the Option Length uses section 7.4 of RFC8724. When the Option Length has a wellknown (It looks like the subsections of 7.4 are also important, though we probably don't need to literally say "section 7.4 and subsections".) Section 5.2 I'm still confused why Max-Age, Uri-Host, and Uri-Port are in the same section. We talk about "the duration", but that seems to only apply to Max-Age. Otherwise these options can be sent as a Compression Residue (fixed or variable length). I'm not sure that there's going to be a practical scenario where a fixed-length residue is workable for anay of these three CoAP Options. Section 5.4 As far as I can tell, Proxy-URI and Proxy-Scheme are indeed unidirectional (only sent in requests). It would perhaps be appropriate to codify this restirction in the compression rules, though I can understand if the general desire is to not add an additional layer of restrictions beyond the core CoAP specificiation. Section 6.2 Since an RST message may be sent to inform a server that the client does not require Observe response, a Rule MUST allow the transmission of this message. Is this saying that if you have a rule that allows sending Observe, you MUST also have a rule allowing RST? It might be worth making that more explicit. Section 6.4 The first byte specifies the content of the OSCORE options using flags. The three most significant bits of this byte are reserved and nit: s/options/option/. This specification recommends identifying the OSCORE Option and the fields it contains Conceptually, it discerns up to 4 distinct pieces of information within the OSCORE option: the flag bits, the piv, the I'm not sure what was intended to happen here. Either there's a missing full stop or a wrongly capitalized word, at a start, but perhaps there was also supposed to be some additional rewording to join the sentences together more fluidly. The OSCORE Option shows superimposed these four fields using the format Figure 6, the CoAP OSCORE_kidctxt field includes the size bits s. The rewording went awry here. I think it's supposed to be more like "Figure 6 shows the OSCORE Option format with those four fields superimposed on it. Note that the CoAP OSCORE_kidctxt field includes the size octet s". (Also, I am not sure I've seen the "ctxt" abbreviation anywhere other than this document. Just "ctx" seems much more common in my experience.) Section 7.1 immediately acknowledged by the Device. For this simple scenario, the Rules are described Figure 7. nit: "described in". Section 9 The need for additional English review is particularly pronounced in the new text here. (I am not attempting to note all instances that would benefit from extra attention.) DoS attacks are possible if an intruder can introduce a compressed SCHC corrupted packet onto the link and cause a compression nit: I think this would be "introduce a corrupted SCHC compressed packet". efficiency reduction. However, an intruder having the ability to add Usually I think of "compression efficiency" as relating to the ratio of sizes between compressed and uncompressed form. What seems to be described here is instead the resource efficiency of the entity performing the decompression function, so I'd suggest using a different phrasing, such as "excessive resource consumption at the decompressor". SCHC compression returns variable-length Residues for some CoAP fields. In the compressed header, the length sent is not the original header field length but the length of the Residue. So if a corrupted packet comes to the decompressor with a longer or shorter length than the one in the original header, SCHC decompression will detect an error and drops the packet. I don't think I understand the mechanism being described here. It sounds as if there is supposed to be some error-checking ability between the recovered (uncompressed) text and the original header, but I don't see such a mechanism. The length in the compressed packet is used to interpret the residue and produce the recovered (uncompressed) value, but the original packet is not available for comparison at that time. If the length in the compressed packet is modified, then the decompressor will get desychronized from the bit stream and start trying to parse "random" data as the rest of the packet; that would be expected to usually produce an error eventually, but I'm not convinced that this is the mechanism referred to by "detect an error and drops [sic] the packet". The secdir review of the -15 made some good points and suggestions, including pointing out in the security considerations that the typical compression attacks we worry about aren't an issue here (and why).
I agree with Ben's first 2 DISCUSS points. ********************************************************************** * Note, that I am conducting an experiment when people aspiring to be* * Area Directors get exposed to AD work ("AD shadowing experiment"). * * As a part of this experiment they get to review documents on IESG * * telechats according to IESG Discuss criteria document and their * * comments get relayed pretty much verbatim to relevant editors/WGs. * * As an AD I retain responsibility in defending their position when * * I agree with it. * * Recipients of these reviews are encouraged to reply to me directly * * about perceived successes or failures of this experiment. * ********************************************************************** The following comments were provided by Francesca Palombini <email@example.com>. My comments are marked with [[Alexey:]] below. Francesca would have balloted *DISCUSS* on this document. She wrote: Discuss: Either I am missing something about "unirectional" and "bidirectional" definition (which I read as can either be present in only one direction request/response or both), or the following sections are wrong: section 5.1 - assuming it is Content-Format, the option is bidirectional, it can be set either in a request or response, for example a PUT request can contain a Content-Format section 5.4 - Size1 and Size2 are bidirectional, and can be used both in req and resp (see RFC7959 sect 4) Section 5.5 - ETag is also Bidirectional (see RFC7252 section 126.96.36.199 and 188.8.131.52) There are more options being defined and not specified in the document: https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#option-numbers for example, Hop-Limit is one. There needs to be some discussion about those, or some considerations on those being out of scope.
Francesca also provided the following comments: Comment: Section 4.2 CoAP type field: better to reference the IANA registry rather than this section, as additional Code fields not defined in RFC7252 can be registered. Section 7.4 : s/CONTENT/Content
Thank you for addressing my COMMENTs raised in March 2020 and thank you for also addressing other DISCUSS and COMMENT from the March 2020 IEGS evaluation. Regards -éric
I support Roman's and Benjamin's DISCUSS positions about the security considerations. The Gen-ART reviewer raised concerns about this as well that have not been fully addressed.
I support Ben Kaduk's DISCUSS position. Thank you for addressing my DISCUSS and COMMENT points.
Being new to both CoAP and SCHC, I found parts of this draft extremely tough going. Thanks very much for the examples; I would have been totally lost without them. I trust that my comments here are mostly due to limited understanding, rather than some deeper issue... Sec 1. I cannot parse this sentence at all: "CoAP is an End-to-End protocol at the application level, so CoAP compression requires to install common Rules between two hosts and IP Routing may be needed to allow End-to-End communication." What are you trying to say here? Sec 2. I do not understand the symbolism of these figures. - What are the many parentheses and dashed lines at the bottom of each one? - I take it that the "SCHC" box implies that everything above it is header-compressed, up until it hits another "SCHC?" IIUC SCHC compresses one or two layers in the stack, rather than being a layer below. - Finally, the explanation of dashed boxes vs dotted boxes is at the very end of the section. Please move it to before the first figure. Sec 3. Expand "TV" on first use. Sec 4.5. " 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 Compression Residue." After looking through the example, I think this means that because the Token Length is being repurposed, it is not available to define variable token lengths. Maybe switch the order of the sentences. It seems like the first flows from the second. In addition, for Token Value not to be sent as variable length, that imposes constraints on the rule set, right? It would be good to clarify exactly what a rule set must do to create this outcome. Sec.5. s/these assmetry/this asymmetry
[[ comments ]] [ section 1 ] * "interop" -> "inter-operate" [ section 2 ] * "The host ... do not implement" -> "does not implement" * Figure 2: "ene-to-end" -> "end-to-end" * "and that they do not include" -> "and they do not include" [ section 4.3 ] * "cannot be compressed an the value" -> "cannot be compressed and the value" [ section 5.0 ] * "these assymetry" -> "this asymmetry" [ section 5.3 ] * "are a repeatable options" -> "are repeatable options" [ section 9 ] * "decompression will detect an error and drops the packet" -> "decompression will detect an error and drop the packet"
Thanks for addressing Alexey's and Francesca's earlier DISCUSS positions. Abstract: OLD: This draft defines the way Static Context Header Compression (SCHC) header compression can be applied to the Constrained Application Protocol (CoAP). [...] NEW: This draft defines the way Static Context Header Compression (SCHC) can be applied to the Constrained Application Protocol (CoAP). [...] Generally, "SCHC header compression" everywhere beyond the Abstract seems redundant to me and can be replaced with just "SCHC". Section 1: * The text here introduces several terms with curious capitalization, such as "End-to-End" and "Rules". If they have special meaning, they should be explicitly defined somewhere, otherwise I suggest just leaving them all lowercase. * "... some bits to be sent, these values are ..." -- comma splice; start a new sentence here * "... applied to different protocols, the exact Rules to be used ..." -- same Section 2: * "... defined in [rfc8724] document." -- remove "document" Section 3.1: * "The field Code have as well the same behavior, the 0.0X code format value in the request and Y.ZZ code format in the response." -- I'm afraid I don't understand this. Section 4.3: * "The code field indicates the Request Method used in CoAP, a IANA registry [rfc7252]." -- I can't parse this. Does that mean the code field's possible values are listed in an IANA registry? Which one? Section 4.4: * "... and the Least Significant Bits (LSB) CDA, see section ..." -- the stuff after the comma should be parenthesized instead; there are several instances of this in the document
Thank you to Linda for the OpsDir review.
The TSV-ART review flagged a problem with draft-ietf-lpwan-ipv6-static-context-hc (Thanks Joe) which is a normative dependency but is already in RFC editor state. Ben also already captured this in his ballot. I also think it would be important to address this problem before final publication (of both docs) and the TSV ADs will coordinate with the INT ADs on this. Minor comment: Sec 7.3: " The Outer SCHC Rules (Figure 16) MUST process the OSCORE Options fields. " The example section should probably not have normative language.
This first item is almost a DISCUSS, but as I'm sure it's not a controversial point and just an editorial thing that will get fixed, I'm just putting it down here. — Section 1 — CoAP [rfc7252] is a transfer protocol that implements a subset of HTTP (Hypertext Transfer Protocol) and is optimized for REST-based (Representational state transfer) services. Important: this statement is not true. CoAP is not a subset of HTTP, and nowhere does CoAP claim that. You might instead combine some of these statements from the CoAP spec: CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. One of the main goals of CoAP is to design a generic web protocol for the special requirements of this constrained environment The goal of CoAP is not to blindly compress HTTP, but rather to realize a subset of REST common with HTTP but optimized for M2M applications. However you fix this, please do fix it. — Section 3 — It appears as if a different author wrote this, compared with the earlier text. I’m not calling out every issue, in the interest of review time, but am only citing some examples. In general, it would be good to have someone go through and edit this sections 3 and 3.1 for clarity. If you wait for the RFC Editor staff to do it, we could end up with errors that we miss catching, because they don’t have the technical background in this topic. 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. SCHC Rules description use the direction information to optmize the compression by reducing the number of Rules needed to compress traffic. I’ve tried several times to understand the first sentence, and I can’t. It isn’t parseable, and I don’t know what you’re trying to say. The second sentence also needs work to make it readable. Can you please try to reword these? — Section 3.1 — The title and the first sentence stopped me for a bit: why would you be comparing CoAP with IPv6? You should be clear right up front that you’re talking about differences in compressing CoAP compared with compressing the other protocols, to explain why there’s a difference in how the compression works. Please say that at the start. (Perhaps that’s part of what you tried to say in Section 3, which I didn’t understand?) o In IPv6 and UDP, header fields have a fixed size, defined in the Rule, which is not sent. The Rule is not sent? Or do you mean the size is not sent? I think you want to say something like, “Header fields in IPv6 and UDP have fixed sizes. The size is not sent as part of the header, but is defined in the Rule.” In CoAP, some fields in the header have a variable length, for example the Token size may vary from 0 to 8 bytes, the length is given by a field in the header. Sentences like this are actually multiple sentences glued together, and are hard to read. In this example, I suggest this: “Some CoAP header fields have variable lengths, so the length is also specified in a header field. For example, the Token field can vary from 0 to 8 bytes in length.” — Section 4.5 — Token Value MUST not be sent as a variable length residue Make it “MUST NOT”.
Thanks for addressing my issues.
Thanks for this document. A couple of minor comments: 1. Introduction SCHC is a general mechanism that can be applied to different protocols, the exact Rules to be used depend on the protocol and the application. The section 10 of the [rfc8724] describes the compression scheme for IPv6 and UDP headers. This document targets the CoAP header compression using SCHC. So what does this document actually define? I read it as providing a mix of constraints that apply when encoding some CoAP fields in SDHC rules, and in other cases it provides guidance on how CoAP fields can be encoded in SDHC rules. Is my understanding correct? If so, a bit of text at the end of the introduction might be helpful. Related to this, I note that some of the sub-sections in section 5 make use of RFC 2119 language and others don't. Possibly the document would be more internally consistent if all the sub-sections in section 5 used 2119 language. 2. Applying SCHC to CoAP headers In the second example, Figure 2, ... This use case realizes an End-to- End context initialization between the sender and the receiver and is out-of-scope of this document. ... This document focuses on CoAP compression represented in the dashed boxes in the previous figures. These two comments seem to conflict with each other as to whether the second use case is covered or not? 7.3. Example OSCORE Compression Plaintext can be compressed up to only 1 byte (size of the RuleID). "compressed down" would read better than "compressed up" Thanks, Rob