Dear Pascal,
thanks for the great work.
Regards,
Corinna
Am 19.02.25 um 17:52 schrieb Pascal
Thubert:
Hello Don
Many thanks for your review and comments!
You may check the changes I made to address this in Diff: draft-ietf-raw-technologies-14.txt - draft-ietf-raw-technologies-15.txt
in more details:
Le mer. 19 févr. 2025 à 06:52, Donald Eastlake <d3e3e3@xxxxxxxxx> a écrit :
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.
The summary of the review is Ready with Nits.
Security
--------
Section 1 says that Security is out of scope for this draft. The Security Considerations section, in its entirety, is as follows:
"Most RAW technologies integrate some authentication or encryption mechanisms that were defined outside the IETF."
Perhaps that is adequate for this document; however, I would recommend that some material from the last paragraph of Section 1 be added to the above. Perhaps something like the following sentence:
"The IETF specifications referenced herein each provide their own Security Considerations, and the lower layer technologies used provide their own security at Layer-2."
Adding this would more than double the size of the Security Considerations. :-)
Doubled it is : )Big Nits
--------
Section 4: This section states that IEEE Std 802.11-2012 and IEEE Std 802.11-2016 "introduce" support for various features. This is wrong. These are merely 802.11 standard complete roll-ups, each derived from the previous roll-up by incorporating the 802.11 standard amendments adopted since that previous roll-up. Significant features were "introduced" by such amendments to 802.11.
Proposed change to includes like in " IEEE Std 802.11-2012 includes support for TSN time synchronization based on IEEE 802.1AS over 802.11 Timing Measurement protocol. IEEE Std 802.11-2016 additionally includes an extension to the 802.1AS operation over 802.11 for Fine Timing Measurement (FTM),"
Section 4.3.1/4.3.2.2: References to 802.11be as being in the future, or being "expected" to include or introduce features, are out of date. I believe 802.11be received final approval as a standard in September 2024. See https://grouper.ieee.org/groups/802/11/Reports/802.11_Timelines.htm
Sure. Added 2021 for ax and 2024 for be.
Smaller Nits
------------
Title: Should add "(RAW)" after "Reliable and Available Wireless".
doneAbstract: The word "browses" in the first line sounds strange. I suggest replacing it with "surveys".
doneSection 1: Same problem with "browses".
doneSection 3:
"which enables to use the" -> "which enables using the"
done
"listener enables to always maintain them" -> "listener enables always maintaining them"
doneSection 4:
General: Lots of features are listed in Section 4 but there should be some statement that there are many, many, many more in the 802.11 standard. After all, we are talking about thousands of pages. (802.11-2020 is 4,377 pages long.)
General: Sees like somewhere you might mention 802.11 frame fragmentation. On a very noisy link, you don't want to transmit for too long as the probability of an error would be very high and the unicast link level acknowledgement would force retransmission of a large frame. By fragmenting, each transmission is shorter and the link level retransmission applies to each fragment which is a smaller amount to retransmit. Then there is the whole TXOP (transmission opportunity) feature...
Initial part of Section 4: I consider "Wi-Fi 6", "Wi-Fi 7", and "Wi-Fi 8" to be marketing designations. Actual technical features of IEEE Std 802.11 have specific technical feature names and almost always correspond to a particular amendment. But it may be impractical to change at this point.
Agreed. Rereader Dave's text, I find that the use of Wi-Fi generations reads well, though.
I changed the below:"Leveraging IEEE Std 802.11, the Wi-Fi Alliance [WFA] (WFA) delivered
Wi-Fi 6, 7, and now 8 with more capabilities to schedule and deliver
frames in due time at fast rates. Still, as any radio technology,
Wi-Fi is sensitive to frame loss, which can only be combatted with
the maximum use of diversity, in space, time, channel, and even
technology.
In parallel, the Avnu Alliance [Avnu], which focuses on applications
of TSN for real time data, formed a workgroup for uses case with TSN
capabilities over wireless, leveraging both 3GPP and IEEE Std 802.11
standards.
To achieve the latter, the reliability must be handled at an upper
layer that can select Wi-Fi and other wired or wireless technologies
for parallel transmissions. This is where RAW comes into play.
This section surveys 802.11 features that are most relevant to RAW,
noting that there are a great many more in the specification, some of
which possibly of interest as well for a RAW solution. For instance,
frame fragmentation reduces the impact of a very transient
transmission loss, both on latency and energy consumption."
Section 4.1:
The paragraph on the Wi-Fi Alliance reads like marketing. There should be some sort of reference for the WFA. If nothing else, the https://www.wi-fi.org/ URL.
There should also be a reference for the Avnu Alliance. Perhaps https://avnu.org/
done above, in section 4 introSection 4.2.1.4: Temporal references generally do not age well. I suggest that both occurrences of "new" be deleted from this section.
makes sense
Section 4.3.2.2: It is an interesting question whether 802.11be permits sending the same frame more or less simultaneously over multiple links in MLO operation. See my presentation
https://mentor.ieee.org/802.11/dcn/24/11-24-1705-01-00bn-frer-for-802-11bn.pptx
Too bad you did not contribute to RAW earlier. This presentation is very much in line with our work there. Note that we experimented frame overhearing on 802.15.4 whereby a receiver C is aware of a transmission from A to B of a frame with the same r tag as one it is supposed to receive at some other scheduled time, and it may use the overheard copy. See, e.g., draft-thubert-bier-replication-elimination-03
Section 5.1, last sentence: "integrated to other standards" -> "integrated with other standards"
done
Section 5.2: "be combined to OFDM" -> "be combined with OFDM"
doneSection 5.2.1: "enables to meet industrial" -> "enables meeting industrial"
doneSection 5.2.1.2:
"allows to deliver a packet" -> "allows delivering a packet"
"in fact associated to a Track." -> "in fact associated with a Track."
"the transmit bundle associated to the Track" -> "the transmit bundle associated with the Track"
all done
I did only a light review of Sections 5, 6, 7, 10, and 11.
Sure, this is already very helpful.
Again, many thanks!
Pascal
Thanks,
Donald
===============================
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
2386 Panoramic Circle, Apopka, FL 32703 USA
d3e3e3@xxxxxxxxx
--
Pascal
-- ****************************************************** PD Dr. rer. nat. habil. Corinna Schmitt Head of Secure Communication Systems (SeCoSys) Research Institute CODE Universität der Bundeswehr München Werner-Heisenberg-Weg 39 85577 Neubiberg, Germany Mobile: +49 (0)1514 4821490 Email: corinna.schmitt@xxxxxxxx https://www.unibw.de/code https://www.corinna-schmitt.de
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
