Hi Tal,
Thanks for sharing the updated version. The changes do not fully address my
comments.
May I suggest the following to address the point that I raised by discuss-1?
Abstract
CURRENT
This document updates RFC 6291 by adding to the guidelines for the use of
the term "OAM" with qualifiers. It does not modify any other part of RFC
6291.
SUGGEST
This document extends RFC 6291 by adding to the guidelines for the use of
the term "OAM" with qualifiers. It does not modify any part of RFC 6291.
Coming to discuss-2, the document is not clear whether the terminologies
that it introduces are scoped specifically (or only) to measurement and
monitoring protocols or to all OAM protocols. The added reference to RFC
7276 Section 2.2.3 conveys that it is the former.Am I correct?
An OAM function is an instrumentation measurement type or
diagnostic.
An OAM protocol is a protocol used for implementing one or more
OAM functions.
Given that Adrian and I both had the impression that the "OAM
protocols" referred were wider and beyond the above, I would suggest
the following change for clarity:
Title
CURRENT: Guidelines for Characterizing "OAM"
SUGGEST: Guidelines for Characterizing OAM Protocols
Introduction
CURRENT:
This document focuses on "OAM" qualifiers; not the definition of "OAM"
per se. Readers should refer to [RFC6291
<https://www.ietf.org/archive/id/draft-ietf-opsawg-oam-characterization-16.html#RFC6291>]
for an overview of OAM scope. This document does not extend or
restrict that scope. Also, readers may refer to the OAM protocol
toolset defined in Section 2.2.3. of [RFC7276
<https://www.ietf.org/archive/id/draft-ietf-opsawg-oam-characterization-16.html#RFC7276>].
SUGGEST:
This document focuses on qualifiers for OAM protocols; not the
definition of "OAM" per se. Readers should refer to [RFC6291
<https://www.ietf.org/archive/id/draft-ietf-opsawg-oam-characterization-16.html#RFC6291>]
for an overview of OAM scope. This document does not extend or
restrict that scope. The term OAM protocols refers to protocols used
for implementing measurement or diagnostic OAM functions as defined in
Section 2.2.3. of [RFC7276
<https://www.ietf.org/archive/id/draft-ietf-opsawg-oam-characterization-16.html#RFC7276>].
This would address the discuss-2.
Thanks for introducing section 3.7. However, I found some portions of it
hard to parse and would suggest the following (assuming I am getting the
intent right):
CURRENT:
The definitions here SHOULD be used by IETF documents referencing OAM. IETF
documents that explicitly want to create different definitions for the
terms defined here can do so, but unless an alternate definition is
provided the definitions of the terms in this document apply. IETF
documents that have a requirement for different definitions are encouraged,
for clarity's sake, to find terms different than the ones defined here. See
also Section 3.1
<https://www.ietf.org/archive/id/draft-ietf-opsawg-oam-characterization-16.html#RecSec>
.
SUGGEST:
The definitions here SHOULD be used by IETF documents referencing OAM
protocols. IETF documents that explicitly want to create different
characterizations beyond the definitions of the terms in this document, can
introduce such terms provided they are different from the ones defined in
this document for clarity's sake. See also Section 3.1
<https://www.ietf.org/archive/id/draft-ietf-opsawg-oam-characterization-16.html#RecSec>
.
Thanks,
Ketan
On Mon, Jan 26, 2026 at 4:22 PM Tal Mizrahi <[email protected]>
wrote:
> Hi Ketan,
>
> An updated version has been posted, incorporating updated text based
> on the issues raised in this thread as well as comments from other
> ADs.
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-characterization/16
>
> The revised version includes a clarification in the introduction about
> the context of the term OAM, as well as revised text in the abstract
> that explains how RFC 6291 is updated by this document. We believe
> these changes (hopefully) resolve both DISCUSS points you raised.
> Another update based on this thread, as suggested by Adrian to address
> one of the issues you raised, was to add the text "(including a
> reference to this document)".
>
> If the current version addresses your concerns, we would appreciate if
> you updated your ballot position.
>
> Thanks,
> Tal.
>
>
> On Thu, Jan 22, 2026 at 10:45 AM Ketan Talaulikar <[email protected]>
> wrote:
> >
> > Hi Adrian,
> >
> > Before this review, I had not really read RFC6291 but was somewhat
> comforting to find that my understanding of the OAM acronym was aligned
> with it. That RFC simply explains the acronym besides clarifying other
> usage that were prevalent before it was published.
> >
> > Please check inline below for responses and clarifications:
> >
> > On Wed, Jan 21, 2026 at 9:27 PM Adrian Farrel <[email protected]>
> wrote:
> >>
> >> Hi Ketan,
> >>
> >> Thanks for the careful review.
> >>
> >> > I have a couple of points that I would like to discuss.
> >> >
> >> > <discuss-1> Does this document really "update" RFC6291? (Note: the
> "update"
> >> > metadata tag is perhaps used in an inconsistent way across areas/WGs
> - this
> >> > point is more about the text in the document.)
> >> >
> >> > RFC6291 is about the guidelines for the use of the OAM acronym in the
> IETF.
> >> > This document does not seem to be changing that.
> >>
> >> Yes, the tag "updates" is slippery and we have struggled to get the
> IESG to give us advice on which we can reliably build.
> >> I think the default behaviour now is for authors (and their AD) to make
> a guess at the appropriate use of the tag and then let the IESG tell them
> they're wrong :-)
> >>
> >> So, the author's intent was to form a linkage such that readers of 6291
> would find this document.
> >
> >
> > KT> I don't agree with that kind of usage of the RFC metadata tag
> "updates" but that is just a personal opinion which does not mean anything
> since there is no IETF consensus to guide us. So, I will leave that to the
> responsible AD - it is not what my DISCUSS position is about.
> >
> > KT> If the purpose of the use of "update" tag is to simply get the
> attention of someone that stumbles upon RFC6291 then can we say so
> explicitly in the abstract and the introduction? If that sounds odd (which
> it does to me, then please consider removing the tag). In general, what I
> am looking for (in the document text) is a clear understanding of what the
> document is exactly changing in the document that it is marked to "update".
> The following statement is incorrect because what is being done is more
> terms are being defined (i.e., it is an extension).
> >
> > This document updates RFC6291 by adding to the guidelines for the use of
> the term "OAM".
> >
> > KT> And if someone is wondering why I am hung up on this, I am dreading
> the day when we start to add these "also see" documents to some of our base
> specifications (e.g., RFC4271 for BGP) resulting in 10s or 100s of such
> "updates" listed against it making it harder to find the documents that are
> really changing/fixing base issues. There is also the highly subjective
> evaluation of which extensions are "important" to get tagged against the
> base specification.
> >
> >
> >>
> >> Additionally, this document concerns the terms "in-band OAM" and
> "out-band OAM" which (of course) include the term "OAM" which 6291
> clarifies. So it seems that this document at least builds on 6291.
> >
> >
> > KT> Yes! Build on. Adds more (extends).
> >
> >>
> >>
> >> > Per https://www.rfc-editor.org/rfc/rfc6291#section-3 - this document
> is
> >> > tackling only the "Operations" part and that too very narrowly about
> >> > terminologies related to monitoring and measurement protocols within
> the
> >> > Operations bucket. It does not cover Administration or Maintenance.
> >> >
> >> > Then doesn't this document sound more like "Guidelines for
> Characterization of
> >> > OAM Monitoring & Measurement Protocols" (or something like that?).
> >>
> >> Yes, I buy that except for the fact that the terms that are often used
> are in-band OAM" and "out-band OAM" and not "in-band OAM Monitoring &
> Measurement Protocols" etc.
> >>
> >> In some networks, administration and maintenance is carried out with
> messages sent on a "management channel" (alternatively Maintenance
> Communication Channel - MCC) that may utilise a completely separate
> physical network, a separate channel, packets mixed with the data, or
> overhead in packets.
> >
> >
> > KT> My observation is that "OAM" is being increasingly used only in the
> context of either monitoring or measurement protocols. This is actually
> against RFC6291 in spirit. Case in point, all examples in Sec 3.5 of this
> document are of those protocols. Med pointed me to RFC7276 which gives an
> overview of "OAM Tools" but there as well, all the protocols discussed seem
> to be related to monitoring or measurement.
> >
> >>
> >>
> >>
> >> > Which then brings up the question in my mind about what is being
> changed in
> >> > RFC6291? This seems like an independent document to me.
> >>
> >> As above. If removing that "updates" tag is the agreed outcome, I'd be
> OK with that and the consequent tweaks to the text.
> >> But I think it is above my paygrade to decide. The IESG can discuss and
> tell us what to do. The authors cannot resolve this point.
> >
> >
> > KT> As clarified above, I am not insisting on removing the "updates"
> tag. Can the authors/WG consider changing the sentence quoted above to
> explain the motivation for the use of that tag if they wish to retain it?
> >
> >>
> >>
> >> > <discuss-2> In continuation of the previous point, are all protocols
> under the
> >> > larger "OAM" bucket only about monitoring or measurement? This
> document gives
> >> > the impression that all OAM protocols are related to
> monitoring/measurement by
> >> > use of the term "OAM protocol".
> >>
> >> I don't understand this point. How does using the term "OAM protocols"
> imply that all OAM protocols are related to monitoring/measurement?
> >
> >
> > KT> I have provided reasons (this document and RFC7276) which gives me
> that impression. I would ask this question to the WG to clarify whether
> that is correct or wrong. If the WG consensus is that OAM protocols/tools
> include things used outside of measurement and monitoring (for
> administration, management, and other types of operations), then at least
> add that text in this document to clarify that and also provide some
> examples of these other protocols.
> >
> >>
> >>
> >> > There is text in section 3.5 that gives the
> >> > (correct) impression that measurement protocols are a subset of OAM
> protocols.
> >> > What about other? With the RFC6291 definition of the OAM acronym,
> would NETCONF
> >> > and SNMP be considered as OAM protocols?
> >>
> >> Yes, I believe SNMP (god rest its soul) is an OAM protocol. Management
> messages (i.e., management protocols) could be sent in a number of channels
> (as described above).
> >> Often, in the past, someone might have said "Netconf is an out-of-band
> management protocol". In a packet network, that designation of
> "out-of-band" might be confusing.
> >> In the context of this document, Netconf would be described as "Active
> OAM".
> >
> >
> > KT> In continuation of my previous response, can these "other OAM
> protocols" be added in section 3.5 ?
> >
> >>
> >>
> >>
> >> > Given that this document is all about terminologies, I am wondering
> whether it
> >> > is accurately characterizing all OAM protocols or a specific sub-set
> of OAM
> >> > related protocols related to operations alone. I am guessing only
> monitoring
> >> > and measurement protocols? Is it possible to clarify this context?
> >>
> >> Happy to consider any clarifications, but I just reread and unless we
> add "and, when we say OAM, we mean all OAM" I don't know what else to say.
> >>
> >> > COMMENT:
> >> >
> >> > Thanks for bringing clarity to the terminologies and the
> recommendations to
> >> > move away from the "band-specific" terminologies. I would suggest
> adding more
> >> > specific recommendations (perhaps in section 3.1?) for future
> documents - i.e.,
> >> > specifically adding this document as a reference when using any of the
> >> > terminologies in those documents and only going further/beyond to
> provide
> >> > context-specific details.
> >>
> >> Yeah, we can:
> >> OLD
> >> The document also presents
> >> alternative terms and definitions for use in future IETF documents
> >> referencing OAM, without precluding the use of other precise,
> >> descriptive terms that do not rely on the "-band" convention.
> >> NEW
> >> The document also presents
> >> alternative terms and definitions for use in future IETF documents
> >> that discuss OAM (including a reference to this document), without
> >> precluding the use of other precise, descriptive terms that do not
> >> rely on the "-band" convention.
> >> END
> >
> >
> > KT> Thanks, that works.
> >
> >>
> >>
> >> > Coming to the choice of BCP track, I am not sure if that is the best
> option.
> >> > This document would also do just as well as informational (RFC7799
> being a good
> >> > example). Have all the terms introduced in the document been
> sufficiently
> >> > vetted out as "best current practice" (I am not sure myself)? So, I
> support
> >> > positions questioning the BCP status but I would rather focus on the
> discussion
> >> > points in my ballot.
> >>
> >> Another point above my paygrade.
> >> I would personally say that this document is giving strong guidance on
> terminology usage to the point of insistence. That, for me, makes it a BCP.
> >>
> >> The IESG can discuss and tell us what to do. The authors cannot resolve
> this point.
> >
> >
> > KT> This isn't a blocking comment from my side. I am merely stating that
> Informational would serve the purpose just as well. If it were to remain a
> BCP, I am guessing it becomes a part of BCP161 or does it get its own BCP
> number (regardless of whether the updates tag is retained or removed)?
> >
> > Thanks,
> > Ketan
> >
> >>
> >>
> >> Cheers,
> >> Adrian
> >>
> >>
>
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
