Hi Greg, Thanks again for reviewing the draft.
We have added a clarification about the fact that In-Data-Packet OAM is a specific case of Hybrid Type I. Notably, "In-Data-Packet OAM" is not equivalent to "Hybrid Type I OAM", and the draft describes a couple of examples of "Hybrid Type I OAM" that is not "In-Data-Packet OAM". Thanks, The authors. On Fri, Sep 26, 2025 at 7:07 PM Greg Mirsky <[email protected]> wrote: > > Hi Giuseppe, > Thank you for highlighting the question about the terminology defined in RFC > 7799 and its application in this draft. In particular, what is the > relationship between the definition of Hybrid Type I measurement methods and > what is defined as In-Data-Packet OAM? Firstly, OAM includes the fault > management and performance monitoring methods and protocols. AFAICS, this > document only provides examples of performance monitoring methods > characterized as In-Data-Packet. Thus, it would be correct to use > In-Data-Packet Performance Monitoring (PM) OAM. Secondly, I support the > addition of a reference to draft-ietf-ippm-on-path-active-measurements. But I > think that the resulting measurements method is characterized as active per > definitions in RFC 7799 because the test packet that is the combination of an > active method and some additional information, e.g., the shim that enables > the Alternate-Marking method, is nothing but a specially constructed test > packet, i.e., an instrument of an active measurement method. And if my > understanding is correct, In-Data-Packet is not a subset of Hybrid Type I > methods but just a renaming of the class of measurement methods defined in > RFC 7799. Since there is no apparent ambiguity in understanding RFC 7799, I > don't see any benefit in renaming Hybrid Type I as In-Data-Packet and suggest > removing it and all related text from the draft. > Please consider my notes above as WG LC comments. > > Regards, > Greg > > On Thu, Sep 25, 2025 at 3:40 AM Giuseppe Fioccola > <[email protected]> wrote: >> >> Hi All, >> I think this is a useful document. However, I have some comments: >> - When referring to Hybrid OAM, I suggest to specify if it is Type I or Type >> II, in order to be more aligned with RFC 7799 terminology. I noticed that >> various examples in the text are simply referred as Hybrid OAM. >> - I would mention the Active OAM variation described in >> draft-ietf-ippm-on-path-active-measurements, that is when Hybrid OAM methods >> are combined with Active OAM tools to perform active on-path measurements. >> According to the definitions in RFC7799, this is still Hybrid Type I. >> - Consequently, I propose to revise the definition of In-Data-Packet OAM and >> specify that it is a subset of Hybrid Type I, where the OAM information is >> carried in the user traffic stream. In this way, it is clear that, any >> application to a specially generated stream can be Hybrid Type I but it is >> not In-Data-Packet OAM. >> - Finally, I suggest to add another classification for the OAM methods, >> depending on whether the method can support on-path (hop-by-hop) or only >> edge-to-edge measurements. >> >> Regards, >> >> Giuseppe >> >> >> -----Original Message----- >> From: Benoît Claise via Datatracker <[email protected]> >> Sent: Tuesday, September 16, 2025 9:47 AM >> To: [email protected]; >> [email protected]; [email protected]; >> [email protected] >> Subject: [OPSAWG]WG Last Call: draft-ietf-opsawg-oam-characterization-12 >> (Ends 2025-09-30) >> >> >> Subject: WG Last Call: draft-ietf-opsawg-oam-characterization-12 (Ends >> 2025-09-30) >> >> This message starts a 2-week WG Last Call for this document. >> >> Abstract: >> As the IETF continues to produce and standardize different >> Operations, Administration, and Maintenance (OAM) protocols and >> technologies, various qualifiers and modifiers are prepended to the >> OAM abbreviation. While, at first glance, the most used appear to be >> well understood, the same qualifier may be interpreted differently in >> different contexts. A case in point is the qualifiers "in-band" and >> "out-of-band" which have their origins in the radio lexicon, and >> which have been extrapolated into other communication networks. This >> document recommends not to use these two terms when referring to OAM. >> >> This document considers some common qualifiers and modifiers that are >> prepended, within the context of packet networks, to the OAM >> abbreviation and lays out guidelines for their use in future IETF >> work. >> >> This document updates [RFC6291] by adding to the guidelines for the >> use of the term "OAM". It does not modify any other part of >> [RFC6291]. >> >> File can be retrieved from: >> https://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-characterization/ >> >> Please review and indicate your support or objection to proceed with the >> publication of this document by replying to this email keeping >> [email protected] in copy. Objections should be motivated and suggestions to >> resolve them are highly appreciated. >> >> Authors, and WG participants in general, are reminded again of the >> Intellectual Property Rights (IPR) disclosure obligations described in BCP >> 79 [1]. Appropriate IPR disclosures required for full conformance with the >> provisions of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of >> any. Sanctions available for application to violators of IETF IPR Policy can >> be found at [3]. >> >> Thank you. >> >> [1] https://datatracker.ietf.org/doc/bcp78/ >> [2] https://datatracker.ietf.org/doc/bcp79/ >> [3] https://datatracker.ietf.org/doc/rfc6701/ >> >> >> >> _______________________________________________ >> OPSAWG mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >> _______________________________________________ >> OPSAWG mailing list -- [email protected] >> To unsubscribe send an email to [email protected] _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
