Subject: [lp-wan] Barry Leiba's No Objection on draft-ietf-lpwan-coap-static-context-hc-13: (with COMMENT)

From: Barry Leiba via Datatracker <[email-masked]>
Date: Wed, 11 Mar 2020 15:45:23 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-lpwan-coap-static-context-hc-13: 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:
----------------------------------------------------------------------

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

---

From: Ana Minaburo <[email-masked]>
Date: Thu, 19 Mar 2020 11:05:51 +0100

Dear Barry,

Thank you very much for your inputs, we have improved the document in the
sections, correcting our terminology and improving our English (I hope!)
Please see my answers inside your text
Ana

> https://datatracker.ietf.org/doc/draft-ietf-lpwan-coap-static-context-hc/

Ana: Done here is the new text:
CoAP {{rfc7252}} is designed to easily interop with HTTP (Hypertext
Transfer Protocol) and is optimized for REST-based (Representational state
transfer) services. Although CoAP was designed for constrained devices, the
size of a CoAP header still is too large for the constraints of LPWAN (Low
Power Wide Area Networks) and some compression is needed to reduce the
header size.

> sentence also needs work to make it readable.  Can you please try to reword
Ana: Hope the new version is more clear, please feel free to correct us, we
are not native English
 The use of SCHC over the CoAP header uses the same description and
application as the one for IP and UDP explained in the
{{I-D.ietf-lpwan-ipv6-static-context-hc}}. For CoAP, SCHC Rules description
uses the direction information to optimize the compression by reducing the
number of Rules needed to compress headers. The field description may
define both request/response headers and target values in the same Rule,
using the DI (direction indicator) to make the difference. As for other
protocols, when the compressor does not find a correct Rule to compress the
header, 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].

> size is not sent as part of the header, but is defined in the Rule.”
Ana: Yes, we have changed the text to:
New Title: Differences between CoAP and UDP/IP Compression
 *  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.

> example, the Token field can vary from 0 to 8 bytes in length.”

Ana: Thanks, We have verified again all section 3.1. We have cut the
sentences and improve the language.

>    Token Value MUST not be sent as a variable length residue
Ana: Done

We will publish a new version soon, with all your inputs

Ana