Skip to main content

IETF Last Call Review of draft-ietf-raw-architecture-25
review-ietf-raw-architecture-25-tsvart-lc-eddy-2025-06-19-00

Request Review of draft-ietf-raw-architecture
Requested revision No specific revision (document currently at 27)
Type IETF Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2025-06-24
Requested 2025-06-10
Authors Pascal Thubert
I-D last updated 2025-07-10 (Latest revision 2025-07-07)
Completed reviews Rtgdir Early review of -21 by Acee Lindem (diff)
Genart IETF Last Call review of -25 by Behcet Sarikaya (diff)
Tsvart IETF Last Call review of -25 by Wesley Eddy (diff)
Secdir IETF Last Call review of -25 by Rich Salz (diff)
Opsdir IETF Last Call review of -25 by Giuseppe Fioccola (diff)
Intdir Telechat review of -25 by Brian Haberman (diff)
Iotdir Telechat review of -25 by Dave Thaler (diff)
Assignment Reviewer Wesley Eddy
State Completed
Request IETF Last Call review on draft-ietf-raw-architecture by Transport Area Review Team Assigned
Posted at https://mailarchive.ietf.org/arch/msg/tsv-art/whjwgagQmtX2CG8BA_hRRNc7-X0
Reviewed revision 25 (document currently at 27)
Result Ready w/nits
Completed 2025-06-19
review-ietf-raw-architecture-25-tsvart-lc-eddy-2025-06-19-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.

This is an interesting document; I liked reading it, and like the approach.

There are some small nits that could be considered to improve readability (I
don't consider any of these to be critical or to have technical implications,
just editorial): - OODA is explained in 2.1.8, but then the acronym is also
defined in 3.2, and again defined and further explained in 5.2.  It seems a bit
repetitive, and these separate mentions are not referencing one another. - OAM
acronym is defined in 2.1.7, then again in 3.2, and again in 5.2.  Again, it's
a bit repetitive. - Different logical planes are mentioned starting in earlier
sections, but it didn't seem to me like they were well explained until Section
4.1 and finally in 4.3 the concepts started to "click".  I didn't fully grasp
the importance or value in distinguishing all these different planes
(controller, network, operational, and data planes with some seeming like
standard networking concepts, some coming specifically from DetNet, and others
extended by RAW), but also didn't think it did any harm.  It just doesn't seem
like these are laid out well early enough.

Some other very small editorial nits:
- Section 2, "quantic" should probably be "quantum"?
- Section 2.1.6 - the LQI definition is a little confusing; LQI is a metric on
specific links, but carried in messages and collected over paths, so it's not
quite clear to an unfamiliar reader how this is supposed to be understood to be
working (e.g. conveyed separately somehow for each link, or integrated somehow
across all links in the path, etc.)