Thanks for engaging, Ketan.
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.
I agree with that.
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
I disagree with that.
If needed, a change would be
Guidelines for Characterizing the Term “OAM”
Introduction
CURRENT:
This document focuses on "OAM" qualifiers; not the definition of "OAM" per se.
Readers should refer to [
<https://www.ietf.org/archive/id/draft-ietf-opsawg-oam-characterization-16.html#RFC6291>
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 [
<https://www.ietf.org/archive/id/draft-ietf-opsawg-oam-characterization-16.html#RFC7276>
RFC7276].
SUGGEST:
This document focuses on qualifiers for OAM protocols; not the definition of
"OAM" per se. Readers should refer to [
<https://www.ietf.org/archive/id/draft-ietf-opsawg-oam-characterization-16.html#RFC6291>
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 [
<https://www.ietf.org/archive/id/draft-ietf-opsawg-oam-characterization-16.html#RFC7276>
RFC7276].
This would address the discuss-2.
Similarly.
This document focuses on qualifiers for the term "OAM"; not the definition of
"OAM" or "OAM protocols". Readers should refer to [
<https://www.ietf.org/archive/id/draft-ietf-opsawg-oam-characterization-16.html#RFC6291>
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 [
<https://www.ietf.org/archive/id/draft-ietf-opsawg-oam-characterization-16.html#RFC7276>
RFC7276].
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
<https://www.ietf.org/archive/id/draft-ietf-opsawg-oam-characterization-16.html#RecSec>
Section 3.1.
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
<https://www.ietf.org/archive/id/draft-ietf-opsawg-oam-characterization-16.html#RecSec>
Section 3.1.
Nah, probably…
The definitions here SHOULD be used by IETF documents qualifying the term
"OAM". 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
<https://www.ietf.org/archive/id/draft-ietf-opsawg-oam-characterization-16.html#RecSec>
Section 3.1.
Cheers,
Adrian
On Mon, Jan 26, 2026 at 4:22 PM Tal Mizrahi <[email protected]
<mailto:[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]
<mailto:[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]
> <mailto:[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]
