Reviewer: Henk Birkholz
Review result: Ready with Nits
I am the assigned IoT Directorate reviewer for
I-D.ietf-tsvwg-udp-options-dplpmtud-15 as part of the IoT Directorate's effort
to provide feedback to IoT-related IETF documents before being processed by the
IESG. Document authors, document editors, WG chairs, and area directors should
treat these comments just like any other WG comments.
Summary: This documents specifies how UDP fragmentation can be avoided or
better steered in the Internet, automatically, using a probing mechanism that
is enabled, by an upper layer protocol or by a UDP transport service. The
activity to avoid UDP fragmentation is called Datagram Packetization Layer Path
MTU Discovery (DPLPMTUD). The base concept of DPLPMTUD is specified in RFC 8899
and combined with the "soft control plane" transport options for UDP
illustrated in I-D.ietf-tsvwg-udp-options, thereby concertizing how UDP
fragmentation avoidance works on a "packatization-layer" (PL, see RFC 4821). In
general, the documents applies UDP guidelines from RFC 8085.
The document highlights when to use probe packets with or without application
data and the potential benefits of reducing the need to send additional UDP
datagrams during DPLPMTUD. The documentation is clear and useful for design
considerations in constrained node environments. The examples in Section 6 are
especially helpful to steer corresponding design decisions.
I've not checked the change log.
Nits:
* The Figure is not labeled and referenced in the text (but there's also just
one Figure). * This has already been highlighted, but sometimes phrasing almost
implies normative language, which might make document a tad bit challenging for
implementers to act on; two examples:
* the use of "ought to"
* phrasing, such as "padded to the required probe size"
* The four-byte (maybe avoid the term octet nowadays) token seems to act as a
nonce, but current phrasing (including SecConSec) is already pretty clear how
that works without an explicit reference to nonces.
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
