Hi Tim, Thanks for the comments, and thanks for some further offline discussion.
We believe the current version of the draft addresses these comments: https://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-characterization/11/ Please let us know if there are any remaining comments about this version. Please see my responses below, marked [TM]. On Thu, Sep 4, 2025 at 6:46 PM Tim Chown <tim.ch...@jisc.ac.uk> wrote: > > Hi, > > > > Here is my review of -10. I would still like to see some tweaks (sorry) not > least due to the divergence from 7799 which I think is counter intuitive as > is. > > > > ----- snip ---- > > > > I have re-reviewed the latest version of the OAM Characterisation draft, > draft-ietf-opsawg-oam-characterization-10. > > > > The draft seeks to simplify and clarify descriptors used for different types > of OAM-related traffic, not least due to the archaic use of in-band and > out-of-band terminology, which this document effectively deprecates. > > > > I consider it a good improvement on the earlier version I reviewed for > ops-dir, but still have non-trivial Nits with the document that I would like > to see addressed before it is advanced further. I appreciate that the > document has been discussed for some time, but I feel these relatively small > changes to make would improve the text and future use of the guidance. > > > > General comments: > > > > The document is well written. > > > > The definition of Hybrid still doesn’t sit well with me, I think because of > the divergence from what is written in RFC7799, which states Hybrid is - > quite intuitively - a blend of Active and Passive, but this document changes > that. Hence my comments further below. > > > > The document recommends avoiding the use of in-band and out-of-band. Perhaps > it should go further and deprecate their use in future documents? (This is > not a strong view, and I’m fine if this isn’t done, but it might be worth > doing for emphasis.) > > > > Specific comments: > > > > Abstract: > > > > Add at the end of para 1: > > “This document recommends they no longer be used when referring to OAM.” [TM] The abstract was updated with a slightly reworded sentence. > > so the abstract makes this feature of the document very clear. The abstract > says nothing on this as is. > > > > Section 3.1: > > > > The “Hybrid” term as used here is NOT consistent with RFC 7799. Hence, I > would rewrite the definition to be in line with it: > > > > Hybrid OAM: > > Use a combination of active and passive methods which may > include augmentation or modification of a single data stream of interest, or > the coordinated use of multiple streams, e.g., an active OAM stream alongside > an unmodified data stream. (This is in line with Section 3.8 of RFC7799.) [TM] The Hybrid OAM definition was updated along the lines you suggested. > > > > I would then rename In-Data-Packet OAM to Modified-Data-Packet OAM (it avoids > the use of “in”, as per “in-band” and does exactly what it says on the tin), > as a sub type of Hybrid. [TM] We have had many discussions about this term, and In-Data-Packet OAM seemed like the most reasonable compromise, so it would be preferable not to change it. > > > > Modified-Data-Packet OAM: > > OAM-related information is carried in the packets that also > carry the data traffic, e.g., where OAM-related bits may be added or > rewritten along the path. This is a specific case of Hybrid OAM. It was > sometimes referred to as “in-band”. [TM] This definition was slightly reworded based on your comment. However, please note that "OAM-related bits may be added or rewritten along the path" is not necessarily the general case. IOAM is an example in which this is true, and it is presented in this section (the third example). So it seems like the current (updated) text makes sense. > > > > Then for the examples in this section: > > Examples 1-4 are fine (with In- rewritten to Modified-) > > Example 5 clarify the active packets here are not ‘probe’ packets but rather > carry data about observed (passive) network characteristics (loss). [TM] A clarification was added to the example. > > Example 6 is exactly why the Hybrid OAM terms needs to be as I’ve rewritten > it above, as per 7799. > > > > Section 3.2: > > > > I think this needs to say for Path-Congruent that: > > “The OAM information is guaranteed to follow…” > > and for Non-Path-Congruent OAM: > > “The OAM information does not necessarily follow…” > > because it might not. It’s about certainty, and the possibility/likelihood > of incongruent traffic. [TM] The definition of "Non-Path-Congruent OAM" was slightly reworded along these lines. It does not seem necessary to update "Path-Congruent". Similarly, "Different-Forwarding-Treatment OAM" was also updated. > > > > If you look at the IP Ping example in 3.4, you already say “is not > guaranteed” there. Same principle. > > > > I’d delete the last sentence of the penultimate paragraph and “A further > concept” as that’s covered below in 3.3 [TM] Agreed. > > > > Section 3.3: > > > > Same thing here > > Equal: > > “The OAM packets are guaranteed to receive the same…” > > and for Different: > > “The OAM packets may receive different...” > > (adding guaranteed and may) [TM] Right, as noted above, "Different-Forwarding-Treatment OAM" definition was reworded. > > > > Appendix A: > > Delete the first sentence, as the doc doesn’t discuss in-band examples > directly anymore. [TM] This sentence was reworded. > > > > ---- snip ---- > > > > Best wishes, > > Tim Thanks, The authors. _______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
