Skip to main content

IETF Last Call Review of draft-ietf-pim-gaap-18
review-ietf-pim-gaap-18-tsvart-lc-pauly-2026-07-29-00

Request Review of draft-ietf-pim-gaap
Requested revision No specific revision (document currently at 20)
Type IETF Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2026-08-03
Requested 2026-07-13
Authors Dino Farinacci , Mike McBride
I-D last updated 2026-08-17 (Latest revision 2026-08-14)
Completed reviews Rtgdir Early review of -11 by Zheng Zhang (diff)
Intdir Early review of -14 by Sheng Jiang (diff)
Genart IETF Last Call review of -18 by Meral Shirazipour (diff)
Artart IETF Last Call review of -18 by Murray Kucherawy (diff)
Opsdir IETF Last Call review of -18 by Bo Wu (diff)
Rtgdir IETF Last Call review of -18 by Sasha Vainshtein (diff)
Secdir IETF Last Call review of -18 by Tim Hollebeek (diff)
Tsvart IETF Last Call review of -18 by Tommy Pauly (diff)
Assignment Reviewer Tommy Pauly
State Completed
Request IETF Last Call review on draft-ietf-pim-gaap by Transport Area Review Team Assigned
Posted at https://mailarchive.ietf.org/arch/msg/tsv-art/Y5mRKkwOFQ4Un0qzifiKZ246yDU
Reviewed revision 18 (document currently at 20)
Result Ready w/nits
Completed 2026-07-29
review-ietf-pim-gaap-18-tsvart-lc-pauly-2026-07-29-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.

Thanks to the authors for a clear and detailed document. As an experimental
document (where the experiment is clear, with a plan to update and revise
based on experience), I don't see any major concerns.

Some transport-specific aspects that are worth clarification:

- I appreciate the callout in section 7 for UDP usage guidelines, with
fragmentation called out. The document says that fragmentation SHOULD
be avoided on multi-record claim packets, and provides one example, but
could benefit from a stronger recommendation of a size to fit within
(such as 1232 to fit within a 1280 byte IPv6 packet).

- What are the expected scales of number of nodes participating? When
nodes send out periodic claims, I could imagine this having higher levels
of traffic if there is a very high number of nodes. Likely this is
something that needs to be understood via experimentation, but if there
is anything that can be said now about potential scalability concerns
with large numbers of nodes, that would be useful to call out.