Hi Adrian, Thanks for your quick reply and suggestions. Please check inline below for responses.
On Tue, Jan 27, 2026 at 7:28 PM Adrian Farrel <[email protected]> wrote: > 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. > KT> Thanks. > > > 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” > > KT> That is an improvement over the current and OK with me. > > > 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. > > > > Similarly. > > This document focuses on qualifiers for the term "OAM"; not the definition of > "OAM" or "OAM protocols". 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>]. > > > > KT> Works for me. > 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>. > > > > 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 Section 3.1 > <https://www.ietf.org/archive/id/draft-ietf-opsawg-oam-characterization-16.html#RecSec>. > > > > KT> This works as well. Thanks for your suggestions and improvements. Thanks, Ketan > Cheers, > > Adrian > > > > > > > > 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]
