Hi Benoit, Sure, will do.
Tim On 03/09/2025, 09:34, "[email protected]" <[email protected]> wrote: You don't often get email from [email protected]. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> Hi Tim, Can you please schedule a review of the latest draft version. The datatracker still shows: OPSDIR IETF Last Call review (of -04) by Tim Chown<https://datatracker.ietf.org/doc/review-ietf-opsawg-oam-characterization-04-opsdir-lc-chown-2024-11-21/> Not ready Thanks and Regards, Benoit Hi Tim, We believe that the current version (10) addresses your comments below. https://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-characterization/10 Please see below - marked [TM]. On Mon, Jul 7, 2025 at 5:49 PM Tim Chown <[email protected]><mailto:[email protected]> wrote: Hi Tal, To be more specific, I find the hybrid vs in-packet terminology still too inter-twined. And ‘hybrid’ just seems the wrong word, to me. [TM] In the current version we have clarified the "Hybrid" definition and the overlap with "In-Data-Packet". We have also added clearer examples to clarify this. Notably, "hybrid" is a term that was defined in [RFC7799], and the current draft does not update or change that term. The current version is clearer about that. And the additional text on “Using Multiple Criteria” could/should be morphed into a set of examples, though of course you also have examples earlier in the document. Maybe do one or the other. [TM] The "Using Multiple Criteria" in the current version indeed includes a set of examples, starting from the sentence "A few example of OAM classification according to the three criteria are presented below". Tim [TM] We hope this addresses the comments. Thanks, The authors. On 11/06/2025, 09:42, "Tal Mizrahi" <[email protected]><mailto:[email protected]> wrote: Hi Tim, Thanks again for the thorough review and comments. We have posted an updated version that we believe addresses the comments you recently sent. https://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-characterization/07/ Updates compared to version 06 include: - "Terminology and Guidance" was moved into a separate section (section 3), with a subsection for each criterion. - The definition of the term "Hybrid OAM" was slightly reworded based on the feedback. - Slightly clarified the example illustrating the difference between hybrid and in-packet OAM. - A clarification about the term "path-congruent" was added. Please let us know whether the current version has addressed your concerns. Thanks, The authors. On Thu, Jun 5, 2025 at 12:06 PM Tim Chown <[email protected]><mailto:[email protected]> wrote: Hi Carlos, Thanks. I think it’s those categories where in-band and out-of-band language is used very loosely when it needn’t be used. The proposed use of hybrid and in-packet isn’t great. I think ideally you’d encourage use of descriptors that explicitly spell out what is meant with respect to the path followed, treatment at a device, encapsulation, header insertion, etc. I think your (very good) goal is to remove/reduce poor / ambiguous use of the in-band/out-of-band language, and that approach should help achieve that. Tim On 05/06/2025, 00:16, "Carlos Pignataro" <[email protected]><mailto:[email protected]> wrote: Tim, Thank you again for taking the time to re-review this document. I really appreciate both your time and the thoughtful details in your feedback. We (Tal, Adrian, and I) will be replying in detail — in the meantime, thanks for this assertion: I like that the emphasis is now on saying “don’t just use in-band and out-of-band” as that language is usually loose and can be ambiguous. As well as for the specifics on the remaining concerns you have. Best, Carlos. On Jun 4, 2025, at 12:14 PM, Tim Chown <[email protected]><mailto:[email protected]> wrote: Hi Carlos. Apologies for the delay, too many life distractions. The -06 draft is now better than the -04 I reviewed, in that it is shorter, and less complex. But I still have a few concerns. I like that the emphasis is now on saying “don’t just use in-band and out-of-band” as that language is usually loose and can be ambiguous. I fully support that aspect of this draft, and it is welcome. Sections 1 and the first part of 2 are fine. But then in 2.1 you introduce several terms in a bit of a haphazard way. I think the document is a little Frankenstein in nature after being reworked a few times. Not your fault, but I think it needs some fresh structure on top of the ideas you have. The differentiation for pathing, for packet treatment, and for active vs passive is good, but you also muddle in hybrid and in-packet with active and passive, and the difference between hybrid and in-packet is a bit ambiguous and unclear. Hybrid sounds to me like hybrid active+passive, if I had to guess. My suggestion would be to make section 2.1 a new section of its own, 3, and within that have numbered subsections with headings something like: 3.1 OAM – general approach 3.2 OAM – traffic modification in flight 3.3 OAM – traffic path followed 3.4 OAM – traffic forwarding treatment And then you can re-use much of your text by talking clearly in there about OAM – general approach Describe the use of dedicated (active) probe packets, OAM via pure traffic observation (passive), and OAM by modifying the data stream. Maybe ‘hybrid’ is then where active probe packets are modified in transit? OAM – traffic modification in flight Describe ways in which traffic can be modified, e.g.: · Encapsulation/tunnelling · Header-insertion (IPv6, in particular) · Rewriting header fields Some of these will affect packet size, some won’t. And may have MTU/fragmentation impact, though that’s not in the scope of this draft. Note here that this might be modification of active probes or of the data stream traffic. The modification may be localised to a domain, such that modifications are undone or changed in some way on egress. OAM – traffic path followed Active probes may follow different paths to the data stream traffic OAM – traffic forwarding treatment Within a specific forwarding device, active probes may get different treatment, e.g., QoS, to the data stream traffic. Maybe define the term ‘data stream’ as meaning the non-OAM data passing through the network which is the subject of OAM. Section 2.2 then becomes section 4, and the subsequent sections are renumbered accordingly. A small nit in Section 2: “that OAM can be” -> “that OAM traffic can be” Oh, and if you want to ack me for comments, feel free. Best wishes, Tim On 30/05/2025, 15:21, "Carlos Pignataro" <[email protected]><mailto:[email protected]> wrote: Thank you, Tim! We look forward to your re-review. Best, Carlos. On May 29, 2025, at 10:59 AM, Tim Chown <[email protected]><mailto:[email protected]> wrote: Hi Tal, I’ll look shortly. Tim On 28/05/2025, 07:08, "Tal Mizrahi" <[email protected]><mailto:[email protected]> wrote: Hi Tim, A kind reminder - please let us know if the current version addresses your comments. Thanks, Tal. On Thu, May 15, 2025 at 7:09 PM Tal Mizrahi <[email protected]><mailto:[email protected]> wrote: Hi Tim, Thanks again for your review. We have revised the draft, and we believe the current version addresses the main comments you raised. Link to the current draft: https://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-characterization Diff compared to version 04 (which you previously reviewed): https://author-tools.ietf.org/iddiff?url1=draft-ietf-opsawg-oam-characterization-04&url2=draft-ietf-opsawg-oam-characterization-06&difftype=--html Please let us know if the current version has addressed your comments
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
