Hi, Pascal et al.,
as a contributor to this work, I have a proposal for the OAM terminology. Top-posting from the discussion below and adding my note tagged GIM>>:
The main issue, from an OPSDIR point of view, is section 2.6 on OAM variations.
Considering the ongoing discussion on draft-ietf-opsawg-oam-characterization,
it might be better to avoid general OAM definitions here. I suggest to consider
RFC 7799 and RFC 9551 for reference and include only the terms useful in the
context of this document. I would simply refer to the definitions of RFC 9551
for In-band OAM and Out-of-band OAM. In addition, I would omit new terms, e.g.
Limited OAM or Upstream OAM, which are not used in the rest of the document
and, if needed, could be taken into account for
draft-ietf-opsawg-oam-characterization.
Done.
The OAM section is gone. Replaced by
"
RAW reuses terminology defined for Operations, Administration, and
Maintenance (OAM) protocols in Section 1.1 of the "Framework of OAM
for DetNet" [DetNet-OAM] and "Active and Passive Metrics and Methods
(with Hybrid Types In-Between" [RFC7799]. The reader is encouraged
to consider the Guidelines for Characterizing "OAM"
[I-D.ietf-opsawg-oam-characterization] to fully understand the
semantics of the terms Active, Passive, Hybrid, and In-Packet OAM,
and usage guideline of the terms In-Band and Out-of-Band OAM that are
defined in [DetNet-OAM] but .
"
at the very beginning of the terminology section. I retained "residence time" that I moved in another section, and a discussion on low layers information that also moved..
GIM>> I find that in-packet OAM is used in only in Figure 11. In fact, according to RFC 7799, protocols that combine passive and active methods of performance measurement are classified as Hybrid (e.g., IOAM and Alternate Marking). Thus, I propose changing s/in-packet OAM/Hybrid OAM/. As a result, there is no apparent need to reference I-D.ietf-opsawg-oam-characterization as RFC 7799 is the earlier authoritative source defining active, passive, and hybrid OAM measurement methods. Hence, the proposed text that replaces the OAM section can be updted as follows:
NEW TEXT:
RAW reuses terminology defined for Operations, Administration, and
Maintenance (OAM) protocols in Section 1.1 of the "Framework of OAM
for DetNet" [DetNet-OAM] and "Active and Passive Metrics and Methods
(with Hybrid Types In-Between)" [RFC7799].
There's a nit may be fixed:
- s/In-Between"/In-Between)"/
Regards,
Greg
On Mon, Jul 7, 2025 at 7:50 AM Pascal Thubert <pascal.thubert@xxxxxxxxx> wrote:
_______________________________________________Dear allMany thanks Giuseppe for your review, and Med and Benoit for your contributions.I published a version with only this review in, see Diff: draft-ietf-raw-architecture-26.txt - draft-ietf-raw-architecture-27.txtBased on that, I did some revamping, please see below:Le mar. 24 juin 2025 à 13:18, Giuseppe Fioccola via Datatracker <noreply@xxxxxxxx> a écrit :Document: draft-ietf-raw-architecture
Title: Reliable and Available Wireless Architecture
Reviewer: Giuseppe Fioccola
Review result: Has Issues
This document introduces the Reliable and Available Wireless (RAW)
Architecture. It leverages and extends RFC 8655 to adapt to the challenges that
affect the wireless medium. I think that the document is valuable and almost
ready for publication, but I have some comments.
The main issue, from an OPSDIR point of view, is section 2.6 on OAM variations.
Considering the ongoing discussion on draft-ietf-opsawg-oam-characterization,
it might be better to avoid general OAM definitions here. I suggest to consider
RFC 7799 and RFC 9551 for reference and include only the terms useful in the
context of this document. I would simply refer to the definitions of RFC 9551
for In-band OAM and Out-of-band OAM. In addition, I would omit new terms, e.g.
Limited OAM or Upstream OAM, which are not used in the rest of the document
and, if needed, could be taken into account for
draft-ietf-opsawg-oam-characterization.Done.The OAM section is gone. Replaced by"
RAW reuses terminology defined for Operations, Administration, and
Maintenance (OAM) protocols in Section 1.1 of the "Framework of OAM
for DetNet" [DetNet-OAM] and "Active and Passive Metrics and Methods
(with Hybrid Types In-Between" [RFC7799]. The reader is encouraged
to consider the Guidelines for Characterizing "OAM"
[I-D.ietf-opsawg-oam-characterization] to fully understand the
semantics of the terms Active, Passive, Hybrid, and In-Packet OAM,
and usage guideline of the terms In-Band and Out-of-Band OAM that are
defined in [DetNet-OAM] but ."at the very beginning of the terminology section. I retained "residence time" that I moved in another section, and a discussion on low layers information that also moved..
I also found few nits for your consideration:
- Some acronyms in section 2 are well known (e.g. FEC, OAM, SNR, Uplink,
Downlink, Downstream, Upstream,...) and can be simply explained within the
text.Pros and Cons. For wireless people I'd not even expand those terms. But this is an architecture document, to be used as a reference for hopefully a bunch of upcoming specifications. I trust that a quick/direct access to the needed terms is welcome in that case.- I suggest to move section 3.2 on "The RAW problem" earlier in the
document, perhaps after the Introduction.Done. I had to extract text and move things around to maintain a logical order. This is why I processed this review individually, to we can observe the result on the diff tools and decide whether it was a good idea - and roll back if not.- Some Figures can be improved since
are not very clear, e.g. Figure 1, Figure 4, Figure 8 and Figure 10.Done already for other reviews with similar comments.Many thanks again, Giuseppe, and sorry it took a bit of time.Pascal--Pascal
detnet mailing list -- detnet@xxxxxxxx
To unsubscribe send an email to detnet-leave@xxxxxxxx
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
