Hi Ketan, all, In addition to what Adrian already mentioned, please see inline some inputs.
Cheers, Med > -----Message d'origine----- > De : Ketan Talaulikar via Datatracker <[email protected]> > Envoyé : mercredi 21 janvier 2026 14:49 > À : The IESG <[email protected]> > Cc : [email protected]; [email protected]; draft- > [email protected]; [email protected]; > [email protected] > Objet : Ketan Talaulikar's Discuss on draft-ietf-opsawg-oam- > characterization-15: (with DISCUSS and COMMENT) > > > Ketan Talaulikar has entered the following ballot position for > draft-ietf-opsawg-oam-characterization-15: Discuss > > When responding, please keep the subject line intact and reply to > all email addresses included in the To and CC lines. (Feel free to > cut this introductory paragraph, however.) > > ------------------------------------------------------------------ > DISCUSS: > ------------------------------------------------------------------ > > Thanks to the authors and the WG for their work on this document. > > 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. [Med] As you rightfully indicated, the use of the tag is inconsistent in the IETF. For this specific context, I do agree with the initial reasoning from the WG, which is basically using the update to signal the following for readers/authors: * RFC 6291 is what you need to know for characterizing OAM * If you need to further qualify OAM, then look at the guidance in draft-ietf-opsawg-oam-characterization. In order to help digest how "update" is used in the document, the abstract has the following: This document updates RFC6291 by adding to the guidelines for the use of the term "OAM". It does not modify any other part of RFC6291. This comment is actually related to the other points in your ballot. This document does not change the scope of OAM, how a "thing" is characterized as OAM, whether "management"/"provisioning" is part of OAM, how O&M is distinct from OAM, etc. All these matters are not altered by this document; RFC6291 applies. If you think that "OAM protocol" is still confusing for you, the authors can consider adding a pointer to rfc7276#section-2.2.3. Thank you. > > Per > https:.. - 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?). > > Which then brings up the question in my mind about what is being > changed in > RFC6291? This seems like an independent document to me. > > <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". 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? > > 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? > > > ------------------------------------------------------------------ > ---- > 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. > > 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. > > ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
