Hi Carlos, Thanks for the follow-up.
Please see inline. Cheers, Med De : Carlos Pignataro <cpign...@gmail.com> Envoyé : lundi 11 novembre 2024 11:38 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com> Cc : Joe Clarke (jclarke) <jclarke=40cisco....@dmarc.ietf.org>; Ops Area WG <opsawg@ietf.org> Objet : Re: [OPSAWG]Re: WG LAST CALL: Guidelines for Charactering "OAM" 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<mailto: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. [Med] I’m afraid most of those (if not all :-)) were prior to WG adoption. It is not late to fix this and I’d hope we can actively seek for that cross-WG feedback. At least the WGLC should be sent to these WG. # RFC6291 Update: clarify that it extends it but does not change anything in that RFC. CMP: Good point, added. [Med] ACK # 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. [Med] The NEW text in -04 fixes this: The guidance in this document is to avoid the terms "in-band" and "out-of-band" when refering to OAM, This is better compared to what was in -03: The guidance in this document is to avoid the terms "in-band" and "out-of-band", and instead find finer-granularity descriptive terms. Please consider this point as closed. Thanks. # 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"> [Med] Looks good to me. I would position “Historical Uses” first, though. # 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. [Med] Thanks. CMP: And if the WG has consensus of one term versus another, I have no preference. Only that there is a descriptive term. [Med] Cool. I see that Greg also raised a comment about this. Can we please have a separate thread on this and try to converge there? Thanks. # “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). [Med] As soon as we get out of “in-packet” thing, I’m fine ;-) Shared-packet was short but I’d be OK with the other two proposals. Might be better to start a dedicated thread on this to have visibility on this point and seek for more feedback? 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. [Med] Fair, but this does not address my initial comment. # *-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. [Med] Thanks. # 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. ____________________________________________________________________________________________________________ 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
