Hi Benoit, We believe that the current version addresses these issues: https://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-characterization/12/
Please see inline, marked [TM]. On Wed, Sep 10, 2025 at 7:48 PM ben...@everything-ops.net <ben...@everything-ops.net> wrote: > > Dear all, > > Great series of comments by Tim. > I don't want to reply for Tim here, but I believe that draft v11 is now > clearly. > > Three minor observations on my side > > - An example of "Hybrid OAM" that is also "In-Data-Packet OAM", is > an IOAM [RFC9197] trace option that is incorporated into data > packets. According to [RFC9197], IOAM '...records OAM information > within the packet while the packet traverses a particular network > domain. The term "in situ" refers to the fact that the OAM data > is added to the data packets rather than being sent within packets > specifically dedicated to OAM.' > > I would extend the first IOAM acronym, to stress the "in situ" qualifier, > otherwise the reference to "in situ" comes out of nowhere, unless you know > RFC9197. > Since this document is about terminology, this seems important. [TM] Fixed. > Should this draft also mention something such as : the "In situ" qualifier > should not be reused, if possible, and is not advised by this document? Or > this is going to far? > > Note: I saw this note, in the appendix. Is this sufficient? > > In-Data-Packet OAM was in some cases referred to as "in-band". > Initially, "In situ OAM" [RFC9197] was also referred to as "In-band > OAM", but was renamed due to the overloaded meaning of "In-band OAM". > Further, [RFC9232] also intertwines the terms "in-band" with "in > situ", though [I-D.song-opsawg-ifit-framework] settled on using "in > Situ". Other similar uses, including [P4-INT-2.1] and > [I-D.kumar-ippm-ifa], still use variations of "in-band", "in band", > or "inband". > [TM] Yes, it seems that the text in the appendix is sufficient in this context. > - > Appendix A. Examples of the Use of the Term In-Band > > This appendix provides a few examples of the use of the term "in- > band". These are intended to highlight the varying interpretations > of the term across different contexts. > > Do you want to say: These are intended to highlight the varying > interpretations > of the term across different contexts, which led to the guidelines in this > document. > [TM] Fixed > - nits > measurment > [TM] Fixed. > > Regards, Benoit (Doc. Shepherd) Thanks, The authors. > > 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
