Last Call Review of draft-ietf-lpwan-coap-static-context-hc-12
review-ietf-lpwan-coap-static-context-hc-12-genart-lc-enghardt-2020-02-10-00

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".