Hello Wesley:
Many thanks for your review! I place the proposed edits in GitHub here: Wesley Eddy's review · raw-wg/raw-architecture@88d4fd1
Please see below:
Le ven. 20 juin 2025 à 05:13, Wesley Eddy via Datatracker <noreply@xxxxxxxx> a écrit :
Document: draft-ietf-raw-architecture
Title: Reliable and Available Wireless Architecture
Reviewer: Wesley Eddy
Review result: Ready with Nits
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@xxxxxxxx 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.
I removed the dup expansion. Added a ref in 2.1.8 to 3.2. Whanged text in 3.2 as
"
The RAW Architecture is based on an abstract OODA Loop that controls the operation of a Recovery Graph.
The generic concept involves: ...
The generic concept involves: ...
"
Also moved a sentence back in the definition to avoid this repetition effect
- OAM
acronym is defined in 2.1.7, then again in 3.2, and again in 5.2. Again, it's
a bit repetitive.
There will be a rework on the OAM text to address Giuseppe Fioccola's review.
I'll keep the general comment in mind addressing that review. In the meantime I removed the duplicate expansions.
- 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.
Great point!
I moved text to create a section "2.5. DetNet Planes"
Some other very small editorial nits:
- Section 2, "quantic" should probably be "quantum"?
I had other comments saying that the analogy was complicated. I removed it.
The new text says:
"
The recovery graph provides excess bandwidth for the intended traffic over alternate potential paths, and
the use of that bandwidth is optimized dynamically.
the use of that bandwidth is optimized dynamically.
"
- 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.)
Both ways are indeed possible. I changed the section to:
"
2.1.6. LQI
Link-Quality Indication: The link quality indicator (LQI) is an
indication of the quality of the data packets received by the
receiver. It is typically derived from packet error statistics, the
exact method depending on the network stack being used. LQI values
may be exposed to the controller plane for each individual hop or
cumulated along segments. Outgoing LQI values can be calculated from
coherent (demodulated) Packet Error Rates (PER), RSSI and incoming
LQI values.
"
Link-Quality Indication: The link quality indicator (LQI) is an
indication of the quality of the data packets received by the
receiver. It is typically derived from packet error statistics, the
exact method depending on the network stack being used. LQI values
may be exposed to the controller plane for each individual hop or
cumulated along segments. Outgoing LQI values can be calculated from
coherent (demodulated) Packet Error Rates (PER), RSSI and incoming
LQI values.
"
Again, many thanks!
I plan to publish a revision by cut-off date tomorrow.
Pascal
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
