Thank you Tal for addressing my comments! Regards,
Giuseppe -----Original Message----- From: Tal Mizrahi <[email protected]> Sent: Monday, October 20, 2025 10:35 AM To: Giuseppe Fioccola <[email protected]> Cc: Benoît Claise <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: [OPSAWG]WG Last Call: draft-ietf-opsawg-oam-characterization-12 (Ends 2025-09-30) Hi Giuseppe, Many thanks for these comments. We believe these comments are addressed in the new version: https://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-characterization/13 Please let us know if there are any remaining issues. Please see the replies below, marked [TM]. On Thu, Sep 25, 2025 at 1:40 PM 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. [TM] Updated in the current version. > - 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. [TM] One of the examples of Hybrid Type I was extended to include the case where an active stream with IOAM is used while passively observing a stream of interest. > - 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. [TM] A note was added to clarify that In-Data-Packet OAM is a specific case of Hybrid Type I. > - 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. [TM] This is an interesting distinction that is relevant for example in draft-ietf-ippm-on-path-active-measurements, but not necessarily required in the current document. Indeed, there may be more aspects by which OAM can be classified further, but the current scope is focused on three main aspects as described in the document. > > Regards, > > Giuseppe Thanks, The authors. > > > -----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-characterizatio > n/ > > 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]
