Hi Ketan, The draft has been updated based on the discussion in this thread: https://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-characterization/17
If this resolves your DISCUSS points, we would appreciate if you updated your ballot. Cheers, Tal. On Tue, Jan 27, 2026 at 4:50 PM Ketan Talaulikar <[email protected]> wrote: > > 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] 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]. >> >> >> >> SUGGEST: >> >> This document focuses on qualifiers for OAM protocols; not the definition of >> "OAM" per se. Readers should refer to [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]. >> >> >> >> 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] 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]. >> >> > > > 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. >> >> >> >> 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. >> >> >> >> 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. >> >> > > > 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]
