Hi Joe, Carlos, Adrian, all, I support this good and well-written document.
Please find below some comments: # Cross-WG reviews: some concerns were raised during the CFA about "potential" conflict with work in other WGs. We argued at that time that coordinating with these WGs should take place. I wonder whether some discussion happened since then. At least the WGLC should be sent to these WGs (detnet, for example). # RFC6291 Update: clarify that it extends it but does not change anything in that RFC. # Guidance scope: The discussion about "in-band signaling"/etc. followed by the guidance on "in-band" usage (Section 2) may be interpreted as the guidance applies for any use in the IETF, while I think we should be restricting this to OAM. Some wording may be helpful here. # Better clarity: new proposed terms are being listed under the "In-Band and Out-of-Band OAM" discussion. I would use a dedicated section for these terms. # Path congruent/Non-Path-Congruent: I have a preference for path-coupled/path-decoupled, but I understand the authors prefer congruent. OK with that. I think, however, that the definition of non-path congruent should discard strict paths (not loose ones). "s/follow the same path/follow the exact same path" would be sufficient here. # "In-packet" is ambiguous as there is always a packet! What is key is to demux it vs user data. ## I suggest s/In-Packet/Shared-Packet (or something similar) ## Reorder Dedicated-Packet/Shared-Packet to emphasis on the intended use of "packet". ## Overall I wonder whether some guidance is needed for how to refer to such packets (more generally all the "* OAM packet" flavors). For example, "Dedicated-Packet OAM packets" may be heavy. # *-QoS-* OAM terms: I would generalize to *-Forwarding-* as QoS is only one aspect of the forwarding behavior. # Stale text/Redundant guidance: Please check the enclosed comments below. FWIW, the full set of comments can be found here: * pdf: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2024/draft-ietf-opsawg-oam-characterization-03-rev%20Med.pdf * doc: https://github.com/boucadair/IETF-Drafts-Reviews/raw/refs/heads/master/2024/draft-ietf-opsawg-oam-characterization-03-rev%20Med.docx Thank you Cheers, Med De : Joe Clarke (jclarke) <jclarke=40cisco....@dmarc.ietf.org> Envoyé : lundi 21 octobre 2024 18:21 À : opsawg@ietf.org Objet : [OPSAWG]WG LAST CALL: Guidelines for Charactering "OAM" This starts a two week WG LC https://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-characterization/. The authors have been polled and there is no known IPR on this work that has been disclosed at this time. Please post comments and thoughts on this document's readiness to the list. We ultimately want to run publication of this in conjunction with the on-path telemetry document. Thanks to Greg Mirsky who agreed to shepherd this draft. The WG LC will run until November 4. Thanks. Joe ____________________________________________________________________________________________________________ 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 -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
