Skip to main content

Last Call Review of draft-ietf-lamps-rfc4210bis-14
review-ietf-lamps-rfc4210bis-14-tsvart-lc-perkins-2024-10-18-00

Request Review of draft-ietf-lamps-rfc4210bis
Requested revision No specific revision (document currently at 18)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2024-10-23
Requested 2024-10-09
Authors Hendrik Brockhaus , David von Oheimb , Mike Ounsworth , John Gray
I-D last updated 2024-10-18
Completed reviews Tsvart Last Call review of -14 by Colin Perkins (diff)
Genart Last Call review of -14 by Linda Dunbar (diff)
Secdir Last Call review of -14 by Scott G. Kelly (diff)
Opsdir Last Call review of -14 by Ran Chen (diff)
Assignment Reviewer Colin Perkins
State Completed
Request Last Call review on draft-ietf-lamps-rfc4210bis by Transport Area Review Team Assigned
Posted at https://mailarchive.ietf.org/arch/msg/tsv-art/PwCOu9xW_wdlwqk_KCjHdHr5mQ0
Reviewed revision 14 (document currently at 18)
Result Ready w/issues
Completed 2024-10-18
review-ietf-lamps-rfc4210bis-14-tsvart-lc-perkins-2024-10-18-00
This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

As noted at the end of Section 3.1.3, while this draft describes the message
syntax, the transfer protocols for conveying the messages in various
environments are specified separately. This seems reasonable but it would be
appropriate for the draft to either state, or to reference if described
elsewhere, the requirements for such transfer protocols. Some messages appear
to be quite large, so the transport presumably must provide reliable delivery,
support arbitrarily sized messages, handle fragmentation if the message is
larger than the path MTU, etc., and not all transport protocols provide these
services. There are presumably also requirements relating to security of the
transfer.

Section 5.3.22 discusses the use of polling to determine the status of an
outstanding response. The polling mechanism provides a checkAfter field to
indicate a time to wait before polling the resource again. It would be helpful
to provide, or reference, some guidance on setting that checkAfter value. It’s
unclear whether the polling interval should be set in some manner that depends
on the network conditions or server load, and so might need to be adaptive on
very short timescales, or if the interval is based on a person taking action to
provision a certificate with a much longer polling interval. The former might
interact poorly with the behaviour of the transfer protocol, and may need to be
set with care based on the chosen transport; the latter is perhaps less
dependent on the transport.

Overall, this seems broadly ready to progress from a transport perspective, but
would benefit from clarifications as noted above.

Colin