Hi Eric, Thanks for the comments.
An updated version has been posted: https://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-characterization/16 > ### Section 3.2 > > Should the "In-Data-Packet OAM" definition include some text about fragmented > packets ? I.e., the OAM part is probably only in one fragment but we could > also > envision the OAM part repeated in all fragments. Should there be text around > this ? The fragments could also follow a non-congruent path with the OAM > fragment. While In-Data-Packet OAM is indeed affected by fragmentation, we believe that it does not require text in this document. For example, RFC 9341 (Alternate Marking), which is cited in the current document as an example of In-Data-Packet OAM, has a section (Section 6 of RFC9341) about fragmentation and how it affects the method. While this is an important property of the protocol, it does not necessarily affect the term "In-Data-Packet OAM", and indeed we expect that documents that define new In-Data-Packet OAM protocols will also define the properties of these protocols, including their behavior with fragmentation. Thanks, Tal. On Fri, Jan 9, 2026 at 5:34 PM Éric Vyncke via Datatracker <[email protected]> wrote: > > Éric Vyncke has entered the following ballot position for > draft-ietf-opsawg-oam-characterization-15: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-characterization/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > # Éric Vyncke INT AD comments for draft-ietf-opsawg-oam-characterization-15 > CC @evyncke > > Thank you for the work put into this document. I am really impressed by the > quality of the definition, they are crystal clear. > > Please find below some non-blocking COMMENT points/nits (replies would be > appreciated even if only for my own education). > > Special thanks to Benoît Claise for the shepherd's *very detailed* write-up > including the WG consensus *and* the justification of the intended status. See > also comments below. > > I hope that this review helps to improve the document, > > Regards, > > -éric > > Note: this ballot comments follow the Markdown syntax of > https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed > by > a tool to create github issues. > > ## COMMENTS (non-blocking) > > ### Sherpherd's write-up > > The shepherd's write-up could be updated (OTOH the I-D has passed the shepherd > step): - question 1: the note about pre-AD review should be updated to reflect > what has been done - question 17 as RFC 7799 is now normative and is not in > the > downref registry > > ### Section 3.2 > > Should the "In-Data-Packet OAM" definition include some text about fragmented > packets ? I.e., the OAM part is probably only in one fragment but we could > also > envision the OAM part repeated in all fragments. Should there be text around > this ? The fragments could also follow a non-congruent path with the OAM > fragment. > > > _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
