Hi,

I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

The draft is an attempt to harmonise use of OAM terminology, with a focus on common ambiguous terms such as in-band and out-of-band. As it stands, both of these terms would be deprecated (no future use) by the document, with more specific language bing proposed instead.  Other terminology is proposed with the noble aim to make future documents clearer in their use of language around OAM.

While noble, the document is a hard read. I found myself repeatedly looking back to check the earlier definitions of new terms. I wonder whether the document tries to do too much, and to prescribe too many terms.

I have to say at this time due to the lack of clarity and its complexity the document is Not Ready to move to the IESG, but I note the WGLC has completed before me writing this, so that position has already been established.

It’s not clear where the proposed new terminology has come from, or who was consulted.  I check by searching on the data tracker (*). There are 27 current “oam” I-Ds, 9 of with are WG-adopted, and 55 RFCs, around 13 of which have been published in the last two years. Some review of these would be prudent, if this hasn’t happened already.

I would also agree with soliciting feedback from groups such as detnet, ippm, maprg and others where definitions of and use of OAM methods are common.  Do the proposed terms meet their needs? Do they seem intuitive?

I have read a few OAM documents. I don’t necessarily feel confused by them, e.g, RFC 9634. Perhaps a simpler first step here is to publish a shorter draft deprecating “in-band” and “out-of-band”, which can be genuinely ambiguous, requiring clarity in new drafts without prescribing exactly how, as there is a lot of variety in use cases.  Which is what is said at the start of 2.1.  So long as the drafts are clear, is it a problem?

Other comments:

2.1 
Non-path-congruent or path-incongruent?
In many cases, you just won’t know if they are congruent or not, due to certain load balancing methods.
In-band can include OAM inserted on path.
In-Packet OAM *can* be Non-path-congruent, can’t it?  Consider OAM data in a v6 DO.
On forwarding treatment, v6 EHs can cause different treatment when packets get punted to the slow path (another type of path!)
I don’t understand the Combined OAM part.

3.
The phrase “dedicated OAM packets” is used, but we should call this “dedicated packet OAM” if following the document?
What’s an atomic OAM packet?
What’s explicit OAM?
“Compound OAM” seems unnecessary, just use the combinations?

5.
“En/de-capsulating” is a bad term as it may be insertion, or modification, not adding / removing a header.
A transparent node should also not drop any OAM.

Tim

(*) https://datatracker.ietf.org/doc/search?name=OAM&sort=&rfcs=on&activedrafts=on&by=group&group=