Hi Tim, Thank you for various review rounds and for confirming that the changes are satisfactory.
For the Modified-Data-Packet, I also tend to agree with the position expressed by Tal but for a distinct reason: “modified” may be (mis)interpreted as if the integrity of any enclosed (user) data will be impacted when OAM data is also carried in such packets, while that should not be the case. As I’m there, @authors: is there any reason why you removed this text from the abstract? OLD (-10): This document updates RFC 6291 by adding to the guidelines for the use of the term "OAM". It does not modify any other part of RFC 6291. (sorry if I missed where this was discussed) Cheers, Med De : Tim Chown <[email protected]> Envoyé : jeudi 11 septembre 2025 12:53 À : [email protected]; Tal Mizrahi <[email protected]> Cc : Carlos Pignataro <[email protected]>; [email protected]; [email protected]; Ops Area WG <[email protected]>; BOUCADAIR Mohamed INNOV/NET <[email protected]> Objet : Re: [OPS-DIR]Re: [OPSAWG]Re: Opsdir last call review of draft-ietf-opsawg-oam-characterization-04 Hi, I’m generally happy with the updates now in -11, thanks Tal. I’ve responded previously on the specific edits. To recap, the only ‘nit’ I have is the choice of term of In-Data-Packet, which as mentioned by Benoit below does have a history of being conflated with In-band, hence my personal preference for Modified-Data-Packet. But if the consensus is stay as is, fine. Otherwise, it’s good to go. I think the iterations have now made it a useful, more concise document, and the clearer emphasis on deprecating use of (or at least recommending against the use of) in-band and out-of-band is welcome. Best wishes, Tim On 10/09/2025, 17:48, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> 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. 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". - 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. - nits measurment Regards, Benoit (Doc. Shepherd) 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 <[email protected]><mailto:[email protected]> 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. ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
