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]
