Subject: [Lwip] Barry Leiba's No Objection on draft-ietf-lwig-tcp-constrained-node-networks-11: (with COMMENT)

From: Barry Leiba via Datatracker <[email-masked]>
Date: Wed, 21 Oct 2020 19:57:43 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-lwig-tcp-constrained-node-networks-11: 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-lwig-tcp-constrained-node-networks/

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

Thanks for a useful document.  I just have a few editorial things here:

— Section 1 —

   However, TCP has been
   criticized (often, unfairly) as a protocol for the IoT.  In fact,
   some TCP features are not optimal for IoT scenarios, such as
   relatively long header size, unsuitability for multicast, and always-
   confirmed data delivery.  However, …

Both of these sentences have nit-level problems that make them a bit off.  The
first sounds like the criticism is that TCP is a protocol for IoT (rather than
that it’s not suitable for that usage).  The second has the examples misplaced,
so it look as though they’re examples of IoT scenarios (rather than examples of
TCP features).  And “in fact” has the wrong feel here: it would normally be
used to contradict the previous sentence, not to explain it.  (And two
“however”s in close proximity also feels awkward)  I suggest this fix:

NEW
   TCP has been
   criticized, often unfairly, as a protocol that’s unsuitable for the
   IoT.  It is true that some TCP features, such as its relatively long
   header size, unsuitability for multicast, and always-confirmed data
   delivery, are not optimal for IoT scenarios.  However, …
END

   TCP is also used by non-IETF application-
   layer protocols in the IoT space such as the Message Queue Telemetry
   Transport (MQTT) and its lightweight variants.

It’s “Message Queuing Telemetry Transport”, and an informative reference to
ISO/IEC 20922 <https://www.iso.org/standard/69466.html> wouldn’t be a bad thing.

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Fri, 30 Oct 2020 09:56:46 +0100

Hi Barry,

Thank you very much for your review!

We just submitted revisions -12 and -13, which aim at addressing the
comments received from the IESG and related reviewers:
https://tools.ietf.org/html/draft-ietf-lwig-tcp-constrained-node-networks-13

> https://datatracker.ietf.org/doc/draft-ietf-lwig-tcp-constrained-node-networks/

Thanks for your detailed explanation, and thanks also for your proposed
new text, which definitely reads much better. We have incorporated your
new text in the latest draft update.

> ISO/IEC 20922 <https://www.iso.org/standard/69466.html> wouldn’t be a

Thank you as well. We have made the text change, and we have also added an
informational reference to the MQTT specification, as suggested.

Thanks,

Carles (on behalf of the authors)

---

From: Barry Leiba <[email-masked]>
Date: Fri, 30 Oct 2020 10:11:57 -0400

Thanks, Carles; I appreciate your addressing my comments.

Barry