Hi, Med, Thank you! Please see one more follow-up inline.
> On Nov 12, 2024, at 4:29 AM, mohamed.boucad...@orange.com wrote: > > Hi Carlos, > > Thanks for the follow-up. > > Please see inline. > > Cheers, > Med > > De : Carlos Pignataro <cpign...@gmail.com <mailto:cpign...@gmail.com>> > Envoyé : lundi 11 novembre 2024 11:38 > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com > <mailto:mohamed.boucad...@orange.com>> > Cc : Joe Clarke (jclarke) <jclarke=40cisco....@dmarc.ietf.org > <mailto:jclarke=40cisco....@dmarc.ietf.org>>; Ops Area WG <opsawg@ietf.org > <mailto: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. CMP2: I just sent a note to ippm, detnet, bier, mols, and spring. CMP2: See: https://mailarchive.ietf.org/arch/search/?as=1&email_list=&end_date=&q=text%3A%22Mail+regarding+draft-ietf-opsawg-oam-characterization%22&qdr=a&start_date= CMP2: Note that this had already been brought up more recently to DetNET, but seems to have been largely ignored (or looked the other way)… https://mailarchive.ietf.org/arch/msg/detnet/NqTndz1P2DaGTH45JCw5O9XQQqc/ —>8— From: Janos Farkas <janos.far...@ericsson.com> To: Pascal Thubert <pascal.thub...@gmail.com>, DetNet WG <det...@ietf.org> The in-band and out-of-band OAM definitions are not clear to me. Perhaps I’m not alone, there is a suggestion to avoid these terms: https://www.ietf.org/archive/id/draft-ietf-opsawg-oam-characterization-01.html#name-in-band-and-out-of-band-oam What should we do with it in draft-ietf-raw-architecture? —>8— Thanks, Carlos. > > # 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
