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

Martin Duke via Datatracker <noreply@ietf.org> Thu, 16 July 2020 00:22 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Martin Duke via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-lpwan-coap-static-context-hc@ietf.org, lpwan-chairs@ietf.org, lp-wan@ietf.org, Pascal Thubert <pthubert@cisco.com>, pthubert@cisco.com
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Martin Duke <martin.h.duke@gmail.com>
Message-ID: <159485894222.22501.14013450692930941562@ietfa.amsl.com>
Date: Wed, 15 Jul 2020 17:22:22 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/lp-wan/84hZ-gI-FOImdeY0OH0K46FTCw0>
Subject: [lp-wan] Martin Duke's No Objection on draft-ietf-lpwan-coap-static-context-hc-15: (with COMMENT)

Martin Duke 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:
----------------------------------------------------------------------

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

[lp-wan] Martin Duke's No Objection on draft-ietf… Martin Duke via Datatracker