Hi Carles,
Thanks a lot for the update. The version -02 indeed reads better from my point
of view. Also making this document informational is IMHO appropriate.
I still have one comment on Section 4.7. "TCP options":
A TCP implementation needs to support options 0, 1 and 2 [RFC793]. A
TCP implementation for a constrained device that uses a single-MSS
TCP receive or transmit window size may not benefit from supporting
the following TCP options: Window scale [RFC1323], TCP Timestamps
[RFC1323], Selective Acknowledgements (SACK) and SACK-Permitted
[RFC2018]. Other TCP options should not be used, in keeping with the
principle of lightweight operation.
Other TCP options should not be supported by a constrained device, in
keeping with the principle of lightweight implementation and
operation.
I think the last two sentences are still not perfect even if the RFC 2119
language is now removed. This sort of statement can easily get outdated, since
there continues to be innovation on TCP extensions and they typically use
options. I think a more future-proof wording would be something of the form
"At the time of publication, lightweight TCP implementations on constrained
devices do not have to use other TCP options."
As a side note, the inconsistency regarding the TFO option still exist in this
wording. And the last two sentences also have quite a bit of repetition. In
addition, it is not clear to me whether the different wording ("use" vs.
"support") in the last two sentences is intentional. For some TCP options, it
is up to the active opener to decide whether to send the option, and it could
refrain from doing so by default even if the option is actually "supported"
(i.e., implemented in the stack). This may be a reasonable TCP stack
configuration in some deployment scenarios, e.g., if window scale is not needed
for sensor data but would help for firmware updates.
Thanks
Michael
_______________________________________________
Lwip mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lwip
