Hi, Med, Thank you very much for your support! The document went through a number of iterations, each time improving.
Please find some follow-ups inline. > On Oct 22, 2024, at 3:52 PM, mohamed.boucad...@orange.com wrote: > > 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). CMP: Yes, this was sent to those other WGs, see my response to Greg Mirsky for pointers. > > # RFC6291 Update: clarify that it extends it but does not change anything in > that RFC. > CMP: Good point, added. > # 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. CMP: I think the title itself is clear and restrictive enough, from the start. That said, happy to add more clarity, welcome some text. > > # 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. > CMP: Good point — I titled it as follows, but other proposals welcome: CMP: <section anchor="terms" title="Terminology and Guidance"> > # 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. CMP: Substitution (adding “exact”) made. CMP: And if the WG has consensus of one term versus another, I have no preference. Only that there is a descriptive term. > > # “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”. CMP: I agree and happy to make this change, but “shared-packet” seems incomplete. How about “in-data-packet”? Or “shared-data-packet” (or even piggy-back-data-packet). CMP: Adrian, others, any suggestions here? > > ## 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. CMP: Here’s the tradeoff of weight (heavy) versus clarity and unambiguity. > > # *-QoS-* OAM terms: I would generalize to *-Forwarding-* as QoS is only one > aspect of the forwarding behavior. CMP: I like this, making the change, but please WG let me know thoughts on this. > > # 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 CMP: Many thanks for this!!! Many of the editorial and clarity suggestions are incorporated into our working copy. CMP: Thanks! Carlos. > > Thank you > > Cheers, > Med > > De : Joe Clarke (jclarke) <jclarke=40cisco....@dmarc.ietf.org > <mailto:jclarke=40cisco....@dmarc.ietf.org>> > Envoyé : lundi 21 octobre 2024 18:21 > À : opsawg@ietf.org <mailto: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
