[lp-wan] Robert Wilton's No Objection on draft-ietf-lpwan-coap-static-context-hc-15: (with COMMENT)

[Robert Wilton via Datatracker <[e-mail]>]

Robert Wilton has entered the following ballot position for
draft-ietf-lpwan-coap-static-context-hc-15: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lpwan-coap-static-context-hc/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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