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

2020-10-30 Thread Barry Leiba
Thanks, Carles; I appreciate your addressing my comments.

Barry

On Fri, Oct 30, 2020 at 4:57 AM Carles Gomez Montenegro
 wrote:
>
> 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
>
> Please find below our inline responses:
>
>
> > 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, …
>
> 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.
>
> > 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  wouldn’t be a
> > bad thing.
>
> 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)
>

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip


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

2020-10-30 Thread Carles Gomez Montenegro
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

Please find below our inline responses:


> 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, …

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.

> 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  wouldn’t be a
> bad thing.

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)

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip


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

2020-10-21 Thread Barry Leiba via Datatracker
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  wouldn’t be a bad thing.



___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip