Hi Med,
[snip]
> As I’m there, @authors: is there any reason why you removed this text from
> the abstract?
>
>
>
> OLD (-10):
>
> This document updates RFC 6291 by adding to the guidelines for the
>
> use of the term "OAM". It does not modify any other part of RFC
>
> 6291.
>
>
>
> (sorry if I missed where this was discussed)
One of the comments Thomas Graf noted in his review was that this text
was duplicated in the abstract and introduction. However, after
removing this text from the abstract we noticed an idnits
notification:
-- The draft header indicates that this document updates RFC6291, but the
abstract doesn't seem to mention this, which it should.
Bottom line is that in the next version we will move this text from
the introduction back to the abstract, and hence it will appear only
once.
Cheers,
Tal.
On Thu, Sep 11, 2025 at 3:27 PM <[email protected]> wrote:
>
> Hi Tim,
>
>
>
> Thank you for various review rounds and for confirming that the changes are
> satisfactory.
>
>
>
> For the Modified-Data-Packet, I also tend to agree with the position
> expressed by Tal but for a distinct reason: “modified” may be
> (mis)interpreted as if the integrity of any enclosed (user) data will be
> impacted when OAM data is also carried in such packets, while that should not
> be the case.
>
>
>
> As I’m there, @authors: is there any reason why you removed this text from
> the abstract?
>
>
>
> OLD (-10):
>
> This document updates RFC 6291 by adding to the guidelines for the
>
> use of the term "OAM". It does not modify any other part of RFC
>
> 6291.
>
>
>
> (sorry if I missed where this was discussed)
>
>
>
> Cheers,
>
> Med
>
>
>
> De : Tim Chown <[email protected]>
> Envoyé : jeudi 11 septembre 2025 12:53
> À : [email protected]; Tal Mizrahi <[email protected]>
> Cc : Carlos Pignataro <[email protected]>; [email protected];
> [email protected]; Ops Area WG
> <[email protected]>; BOUCADAIR Mohamed INNOV/NET <[email protected]>
> Objet : Re: [OPS-DIR]Re: [OPSAWG]Re: Opsdir last call review of
> draft-ietf-opsawg-oam-characterization-04
>
>
>
>
>
> Hi,
>
>
>
> I’m generally happy with the updates now in -11, thanks Tal. I’ve responded
> previously on the specific edits.
>
>
>
> To recap, the only ‘nit’ I have is the choice of term of In-Data-Packet,
> which as mentioned by Benoit below does have a history of being conflated
> with In-band, hence my personal preference for Modified-Data-Packet. But if
> the consensus is stay as is, fine.
>
>
>
> Otherwise, it’s good to go. I think the iterations have now made it a
> useful, more concise document, and the clearer emphasis on deprecating use of
> (or at least recommending against the use of) in-band and out-of-band is
> welcome.
>
>
>
> Best wishes,
>
> Tim
>
>
>
> On 10/09/2025, 17:48, "[email protected]" <[email protected]>
> wrote:
>
>
>
> Dear all,
>
> Great series of comments by Tim.
> I don't want to reply for Tim here, but I believe that draft v11 is now
> clearly.
>
> Three minor observations on my side
>
> - An example of "Hybrid OAM" that is also "In-Data-Packet OAM", is
>
> an IOAM [RFC9197] trace option that is incorporated into data
>
> packets. According to [RFC9197], IOAM '...records OAM information
>
> within the packet while the packet traverses a particular network
>
> domain. The term "in situ" refers to the fact that the OAM data
>
> is added to the data packets rather than being sent within packets
>
> specifically dedicated to OAM.'
>
>
>
> I would extend the first IOAM acronym, to stress the "in situ" qualifier,
> otherwise the reference to "in situ" comes out of nowhere, unless you know
> RFC9197.
>
> Since this document is about terminology, this seems important.
>
> Should this draft also mention something such as : the "In situ" qualifier
> should not be reused, if possible, and is not advised by this document? Or
> this is going to far?
>
>
>
> Note: I saw this note, in the appendix. Is this sufficient?
>
> In-Data-Packet OAM was in some cases referred to as "in-band".
>
> Initially, "In situ OAM" [RFC9197] was also referred to as "In-band
>
> OAM", but was renamed due to the overloaded meaning of "In-band OAM".
>
> Further, [RFC9232] also intertwines the terms "in-band" with "in
>
> situ", though [I-D.song-opsawg-ifit-framework] settled on using "in
>
> Situ". Other similar uses, including [P4-INT-2.1] and
>
> [I-D.kumar-ippm-ifa], still use variations of "in-band", "in band",
>
> or "inband".
>
>
>
> -
>
> Appendix A. Examples of the Use of the Term In-Band
>
>
>
> This appendix provides a few examples of the use of the term "in-
>
> band". These are intended to highlight the varying interpretations
>
> of the term across different contexts.
>
>
>
> Do you want to say: These are intended to highlight the varying
> interpretations
>
> of the term across different contexts, which led to the guidelines in this
> document.
>
>
>
> - nits
>
> measurment
>
>
> Regards, Benoit (Doc. Shepherd)
>
> Hi Tim,
>
>
>
> Thanks for the comments, and thanks for some further offline discussion.
>
>
>
> We believe the current version of the draft addresses these comments:
>
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-characterization/11/
>
>
>
> Please let us know if there are any remaining comments about this version.
>
>
>
> Please see my responses below, marked [TM].
>
>
>
>
>
> On Thu, Sep 4, 2025 at 6:46 PM Tim Chown <[email protected]> wrote:
>
>
>
> Hi,
>
>
>
>
>
>
>
> Here is my review of -10. I would still like to see some tweaks (sorry) not
> least due to the divergence from 7799 which I think is counter intuitive as
> is.
>
>
>
>
>
>
>
> ----- snip ----
>
>
>
>
>
>
>
> I have re-reviewed the latest version of the OAM Characterisation draft,
> draft-ietf-opsawg-oam-characterization-10.
>
>
>
>
>
>
>
> The draft seeks to simplify and clarify descriptors used for different types
> of OAM-related traffic, not least due to the archaic use of in-band and
> out-of-band terminology, which this document effectively deprecates.
>
>
>
>
>
>
>
> I consider it a good improvement on the earlier version I reviewed for
> ops-dir, but still have non-trivial Nits with the document that I would like
> to see addressed before it is advanced further. I appreciate that the
> document has been discussed for some time, but I feel these relatively small
> changes to make would improve the text and future use of the guidance.
>
>
>
>
>
>
>
> General comments:
>
>
>
>
>
>
>
> The document is well written.
>
>
>
>
>
>
>
> The definition of Hybrid still doesn’t sit well with me, I think because of
> the divergence from what is written in RFC7799, which states Hybrid is -
> quite intuitively - a blend of Active and Passive, but this document changes
> that. Hence my comments further below.
>
>
>
>
>
>
>
> The document recommends avoiding the use of in-band and out-of-band. Perhaps
> it should go further and deprecate their use in future documents? (This is
> not a strong view, and I’m fine if this isn’t done, but it might be worth
> doing for emphasis.)
>
>
>
>
>
>
>
> Specific comments:
>
>
>
>
>
>
>
> Abstract:
>
>
>
>
>
>
>
> Add at the end of para 1:
>
>
>
> “This document recommends they no longer be used when referring to OAM.”
>
>
>
> [TM] The abstract was updated with a slightly reworded sentence.
>
>
>
>
>
> so the abstract makes this feature of the document very clear. The abstract
> says nothing on this as is.
>
>
>
>
>
>
>
> Section 3.1:
>
>
>
>
>
>
>
> The “Hybrid” term as used here is NOT consistent with RFC 7799. Hence, I
> would rewrite the definition to be in line with it:
>
>
>
>
>
>
>
> Hybrid OAM:
>
>
>
> Use a combination of active and passive methods which may
> include augmentation or modification of a single data stream of interest, or
> the coordinated use of multiple streams, e.g., an active OAM stream alongside
> an unmodified data stream. (This is in line with Section 3.8 of RFC7799.)
>
>
>
> [TM] The Hybrid OAM definition was updated along the lines you suggested.
>
>
>
>
>
>
>
>
>
> I would then rename In-Data-Packet OAM to Modified-Data-Packet OAM (it avoids
> the use of “in”, as per “in-band” and does exactly what it says on the tin),
> as a sub type of Hybrid.
>
>
>
> [TM] We have had many discussions about this term, and In-Data-Packet
>
> OAM seemed like the most reasonable compromise, so it would be
>
> preferable not to change it.
>
>
>
>
>
>
>
>
>
> Modified-Data-Packet OAM:
>
>
>
> OAM-related information is carried in the packets that also
> carry the data traffic, e.g., where OAM-related bits may be added or
> rewritten along the path. This is a specific case of Hybrid OAM. It was
> sometimes referred to as “in-band”.
>
>
>
> [TM] This definition was slightly reworded based on your comment.
>
> However, please note that "OAM-related bits may be added or rewritten
>
> along the path" is not necessarily the general case. IOAM is an
>
> example in which this is true, and it is presented in this section
>
> (the third example). So it seems like the current (updated) text makes
>
> sense.
>
>
>
>
>
>
>
>
>
> Then for the examples in this section:
>
>
>
> Examples 1-4 are fine (with In- rewritten to Modified-)
>
>
>
> Example 5 clarify the active packets here are not ‘probe’ packets but rather
> carry data about observed (passive) network characteristics (loss).
>
>
>
> [TM] A clarification was added to the example.
>
>
>
>
>
> Example 6 is exactly why the Hybrid OAM terms needs to be as I’ve rewritten
> it above, as per 7799.
>
>
>
>
>
>
>
> Section 3.2:
>
>
>
>
>
>
>
> I think this needs to say for Path-Congruent that:
>
>
>
> “The OAM information is guaranteed to follow…”
>
>
>
> and for Non-Path-Congruent OAM:
>
>
>
> “The OAM information does not necessarily follow…”
>
>
>
> because it might not. It’s about certainty, and the possibility/likelihood
> of incongruent traffic.
>
>
>
> [TM] The definition of "Non-Path-Congruent OAM" was slightly reworded
>
> along these lines. It does not seem necessary to update
>
> "Path-Congruent". Similarly, "Different-Forwarding-Treatment OAM" was
>
> also updated.
>
>
>
>
>
>
>
>
>
> If you look at the IP Ping example in 3.4, you already say “is not
> guaranteed” there. Same principle.
>
>
>
>
>
>
>
> I’d delete the last sentence of the penultimate paragraph and “A further
> concept” as that’s covered below in 3.3
>
>
>
> [TM] Agreed.
>
>
>
>
>
>
>
>
>
> Section 3.3:
>
>
>
>
>
>
>
> Same thing here
>
>
>
> Equal:
>
>
>
> “The OAM packets are guaranteed to receive the same…”
>
>
>
> and for Different:
>
>
>
> “The OAM packets may receive different...”
>
>
>
> (adding guaranteed and may)
>
>
>
> [TM] Right, as noted above, "Different-Forwarding-Treatment OAM"
>
> definition was reworded.
>
>
>
>
>
>
>
>
>
> Appendix A:
>
>
>
> Delete the first sentence, as the doc doesn’t discuss in-band examples
> directly anymore.
>
>
>
> [TM] This sentence was reworded.
>
>
>
>
>
>
>
>
>
> ---- snip ----
>
>
>
>
>
>
>
> Best wishes,
>
>
>
> Tim
>
>
>
> Thanks,
>
> The authors.
>
>
>
> ____________________________________________________________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
