Reviewer: Theresa Enghardt Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-lpwan-coap-static-context-hc-?? Reviewer: Theresa Enghardt Review Date: 2020-02-10 IETF LC End Date: 2020-02-20 IESG Telechat date: Not scheduled for a telechat Summary: Thanks for this work. This document is clear in the problem to be solved, the challenges, and how to address these challenges. I think the details and examples will help implementers tremendously. However, some parts would benefit from more explanation to make the document easier to understand. Moreover, the authors should double-check whether the document contains all the normative language that is needed, and they need to revisit the security considerations. Major issues: Section 9, Security considerations I find it difficult to believe that compressing CoAP headers in addition to UDP/IP does not add any new security considerations and does not modify the existing ones. As an application-layer protocol, the information contained in CoAP might be more sensitive than the information in the UDP and IP headers, thus, its security considerations should be carefully examined. For example, does compression improve security by making it more difficult for an observer to parse the packet, as the observer does not have the context? Does compression make the existing security problems better or worse if you compress the CoAP header as well? Do the possible threats mentioned in RFC 7252 still apply if headers are compressed? Might compressing the CoAP headers affect computational resources, like an attacker sending forged packets, if the protocol has variable length fields and multiple occurences of the same field? 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. Section 1 "CoAP [rfc7252] is an implementation of the REST architecture for constrained devices." - From a protocol perspective, maybe "REST architecture" could be phrased more accurately, like saying that CoAP is a web transfer protocol that implements a subset of HTTP and is optimized for REST-based services? Also, please expand REST on first use. "[…] the field description composing the Rules […]" - At this point, Rules have not yet been introduced. The paragraph that describes how SCHC works was difficult to understand as a reader not yet familiar with SCHC. For example, I was confused for a while why a rule matches an entire packet and not just one header field, as I was missing the big picture. Maybe here a top-down approach would help, e.g., something like: "SCHC compresses and decompresses headers based on shared contexts between devices. Each context consists of multiple rules. Each rule can match header fields and specific values or ranges of values. If a rule matches, the matched header fields are substituted by the rule ID and optionally some residual bits. Thus, different rules may correspond to different types of packets that a device expects to send or receive." Additionally, perhaps the text should describe what match operations and what header compression/decompression operations are possible, as the document refers to these operations later in the text. Alternatively, the document could refer to specific sections of draft-ietf-lpwan-ipv6-static-context-hc where these operations are explained. "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? As the abstract emphasizes that CoAP is different from UDP and IPv6, I was expecting the Introduction to have some content on this. Later I saw that Section 3 lists differences and resulting challenges, and then the document explains how to address these challenges. But I think it makes sense to briefly mention this already in the Introduction, e.g., by saying that SCHC is a general concept that can be applied to different protocols, the exact rules to be used depend on the protocol and perhaps the application, and that CoAP differs from UDP and IPv6 in some aspects, see Section 3. Section 2 While the heading of this section is "SCHC Compression Process", it does not seem to describe the compression process, but instead this section seems to focus on the architecture or deployment schemes of where SCHC is applied, i.e., on what headers. Please consider changing the section heading to better reflect the content, e.g., to something like "Architecture for applying SCHC to CoAP" or just "Applying SCHC to CoAP". "In this case, SCHC C/D (Static Context Header Compression Compressor/Decompressor) is performed at the device and at the LPWAN boundary." - As someone not familir with LPWAN, to me it came as a surprise that SCHC can not just be performed at the device, but apparently also somewhere in the network. Would this be at a router or some kind of gateway? Is there a reference for this? Perhaps it's worth briefly stating and explaining this at the beginning of this section or maybe already in Section 1. Section 3 and following: Please check that you have all the normative language you need in there to make sure you separate what is needed for SCHC to function correctly from any suggestions how one could optimize their rule tables for a specific deployment/application. Section 3 "CoAP differs from IPv6 and UDP protocols on the following aspects" - As this section does not just describe differences, but also points to how to deal with them, perhaps it's a good idea to reflect this in both this introducing sentence. Also, the section heading could be more explicit about the contents, e.g., "Differences between CoAP and UDP/IP". "IPv6 and UDP are symmetrical protocols. The same fields are found in the request and in the response" - IPv6 and UDP do not have requests and responses, but packets and datagrams. Maybe instead you could say that there are the same header fields in all packets/datagrams or "in a CoAP request and response". "A CoAP request is intrinsically different from a response." - What exactly does "intrinsically different" mean here? The examples give an idea, but I think it's good to say explicitly what the difference is, e.g., that there's different header fields in CoAP requests/responses. "[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? "The same behavior can be applied to the CoAP Code field 0.0X code Format is found in the request and Y.ZZ code format in the answer." - Broken sentence and hard to parse. Maybe rephrase? "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? "In IPv6 and UDP, header fields have a fixed size and it is not sent." - What does "it" refer to here? The size? "More systematically, the CoAP options are described using the Type-Length-Value." - Maybe refer to it as the "Type-Length-Value encoding scheme" or "format". "[I-D.ietf-lpwan-ipv6-static-context-hc] offers the possibility to define a function for the Field Length in the Field Description." - I think it makes sense to add a sentence stating explicitly how this fact relates to your document, e.g., that you use this possibility for CoAP. "The MSB MO can be applied to reduce the information carried on LPWANs." - "MSB MO" has not been defined or mentioned before in the document. Perhaps it makes sense to either introduce it in Section 1, if you choose to add a description of the match operations that exist, or you could add a reference. "CoAP also obeys the client/server paradigm and the compression ratio can be different if the request is issued from an LPWAN device or from a non LPWAN device." - The overall point of the paragraph is not clear from this sentence. What is the relationship between client/server and LPWAN/non-LPWAN, as they are mentioned in the same sentence? Is it that compression can be optimized based what kind of device sends the data? Should the point regarding the proxy placed before the compressor also be mentioned in Section 2, which talks about different deployment schemes? "If no valid Rule was found, then the packet MUST be sent uncompressed using the RuleID dedicated to this purpose and the Compression Residue is the complete header of the packet. See section 6 of [I-D.ietf-lpwan-ipv6-static-context-hc]." - Is this a different between CoAP and UDP/IP? It is part of the list of differences between CoAP and UDP/IP, but it seems different from the other list items. Section 4.2 "In any case, a rule MUST be defined to carry RST to a client." -> This says that you MUST NOT assume that a server only sends ACK, right? Should this MUST apply to RST in general, i.e., also apply to carrying RST to a server? Section 4.4 "In case where the Device is a client, the size of the Message ID field may be too large regarding the number of messages sent." - "too large" sounds like it doesn't work, but it's just inefficient, right? Maybe this should be rephrased to directly say that the field is 16 bit, but if a client sends less messages, it would need less bits. "The client SHOULD use only small Message ID values, for instance 4 bit long." - Maybe rephrase "4 bit long" to say "Message IDs that can be encoded using only 4 bits". This part refers to MSB and LSB CDA, but neither has been introduced before in the document. 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. Section 5.2 "Otherwise these options SHOULD be sent as a residue (fixed or variable length)." - Well if you can't compress it, you don't have any other choice than to send it as residue, right? So is this a SHOULD or do you want to simply say "these options can be sent as a residue"? Section 5.3 Here the document starts giving examples for rules and contexts, which is a good idea, but the first example is difficult to follow. Maybe it's a good idea to briefly describe the rule that is shown in Figure 2 and the URI that it would match, and maybe it's worth showing the alternative without regrouping to make clear why a 2 bit residue would be needed without regrouping. In general, it might be worth adding a reference to draft-ietf-lpwan-ipv6-static-context-hc, where Section 7.1 uses a similar table for showing rules and provides more explanation of the table fields. Section 5.3.1 "and the unit is set to bytes." - Is this a SHOULD or a MUST? Section 5.3.2 "[…] send a compression residue with a length of 0 to indicate that this Uri-Path is empty. This adds 4 bits to the compression residue." - This appears to be contradictory: Either you send 0 bits of compression residue or 4 bits. Section 5.5 "These fields are unidirectional." - For other unidirectional fields, the document says that it "MUST NOT be set to bidirectional". Does it need to add this restriction here, too? Section 6 The heading is not really clear, please change. What "Other RFCs" is this about - Extensions to CoAP? More CoAP fields, features, or options? Section 6.4 "This draft recommends to implement a parser that is able to identify the OSCORE Option and the fields it contains." - Why is a parser needed and how does such a parser interact with the SCHC rule matching? Is this parser something that already exists in SCHC or is this something additional, meaning you can't compress OSCORE using SCHC as it exists? How does this section relate to Section 7.2, which discusses OSCORE in detail? Should there be a reference to Section 7.2 here? Section 7.3 "The SCHC Rules for the Inner Compression include all fields that are already present in a regular CoAP message, what is important is their order and the definition of only those CoAP fields are into Plaintext, Figure 11." - This sentence is hard to parse. Maybe split into two sentences. For compressing the response, it is not obvious why the compression residue produces a misalignment which changes the hexcode. I would assume that the padding would just added after the residue. Why is this shifted instead? Does this come from the OSCORE spec? If so, it's worth saying so explicitly. Figure 14 contains Options "0xd8080904636c69656e74" but in the above "Protected message" (for the request) the substring is "d7080904636c69656e74" - This might be a copy-paste-error. "The SCHC context would need to be reestablished" - This reads like there might be some kind of protocol exchange to establish a context, while the earlier text gave the impression that a SCHC context is pre-configured on the device. Does this simply mean that the SCHC context would need to change, e.g., by adjusting the compression rules to mask less bits? Nits/Editorial: Please expand SCHC on first use. Section 1 "The context is said static" - Perhaps rephrase to "called" static? or just cross the "said"? Please check consistency: "Rules" or "rules"? Section 2 "focused on the inner header" → "focuses"? Section 3 "CoAP differs from IPv6 and UDP protocols " - strike "protocols" from this sentence "For instance, if a client sends only CON request" -> "requests"? "The SCHC compression-decompression process never modifies the Values it only reduces their sizes." - missing comma "If no valid Rule was found" -> "is found" Section 4.2 "CoAP Protocol" -> "CoAP" or "The CoAP Protocol"? Section 4.4 "The client will generate Message ID" -> "a Message ID"? "Message IDs"? Section 6.4 "This draft" will no longer be a good way to refer to the document once the document becomes an RFC, so maybe change it to "This document" or "specification". -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
