Hi Tai, Thank you for considering my comments, the revisions made is OK to me.
Best regards Chongfeng China Telecom From: Tal Mizrahi Date: 2025-09-10 19:52 To: Chongfeng Xie CC: Benoit Claise; opsawg; [email protected] Subject: [OPSAWG]Re: draft-ietf-opsawg-oam-characterization-09 - review Hi Chongfeng, Many thanks for the thorough review. Please see inline, marked [TM]. On Fri, Aug 8, 2025 at 9:19 AM Chongfeng Xie <[email protected]> wrote: > > > > Hi authors, > > I have reviewed the draft version -09, and have the following suggestions, > > 1) The title of section 3.1 needs to be changed. > This draft says that: In-Packet OAM is a specific case of Hybrid OAM, so > there is the case of Hybrid OAM that are not In-Packet OAM, we call it > "Hybrid OAM，non In-Packet OAM > Here, so the first criteria will four types: > > -Passive OAM > -Active OAM > -Hybrid OAM，In-Packet OAM： “Hybrid OAM”in which OAM-related information is > piggybacked onto data packets. > -Hybrid OAM，non In-Packet OAM： "Hybrid OAM" in which user packets are not > modified by the protocol. > > Also, I think the title of section 3.1 is not rigorous from semantic > perspective, the Hybrid, and In-Packet OAM should not stand side by side, > since In-Packet OAM is a specific case of Hybrid OAM. I think it should be > changed [TM] Following your comment, the title of section 3.1 has been updated in version 11: https://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-characterization/11/ The term "In-Packet OAM" was updated to "In-Data-Packet OAM" following comments from other members of the working group, and we believe it is clearer now. > > 2) In addition, regarding the expression approach, I suggest adding a table > in Section 3.4 > The table can list all the possible combinations of the three criterias, with > the maximum number of combinations being 4 * 2 * 2=16. However, considering > various impossible combinations, such as: Non-Path-Congruent OAM, by nature, > cannot be Equal-Forwarding-Treatment, the number of combinations can be > reduced (an example is give below, which currently has 10 types). With such a > table, a new OAM can be easily classified into the corresponding types. I > think such a table should be the part of the guidline, textual expression > alone sometimes is not intuitive and increases the difficulty of > understanding. > > [TM] Indeed, we had a similar discussion about two months ago: https://mailarchive.ietf.org/arch/msg/opsawg/YkKiYIyR5uIDhaUdI01yiUBWzCY/ The outcome of the discussion was that rather than describing (or illustrating) all the possible combinations of the three categories, it would be clearer to present a set of examples, and that is exactly what we currently have in Section 3.4. Therefore, we believe that it would be best to keep the current description and examples in Section 3.4. > I hope the suggestions above are useful for improving the draft. > > Best regards > Chongfeng Please let us know if there are any further comments. Thanks, The authors. > > > From: Benoit Claise > Date: 2025-07-24 01:29 > To: opsawg; [email protected] > Subject: [OPSAWG]draft-ietf-opsawg-oam-characterization-09 - review > Tal, Carlos, Adrian, > > As document shepherd, I provided my feedback on the version 07 to the list > Now looking at the diff between version 7 and 9. > > The draft continues to improve and you addressed my points. Thanks > > Just to prove I read the draft (at least the diffs), one nit: > A few example => A few examples > > Regards, Benoit > _______________________________________________ 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]
