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. 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. > 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. > 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. > <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? > 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". > 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 > 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. Cheers, Adrian _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
