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