Re: [OPSAWG] New I-D -> Guidelines for Charactering "OAM"

uth: "there is no band".* > I am glad that that was clarified and that a less confusing expansion of > 'I' was found that all parties could live with. > >> CMP: Thus far, this does not show to me that the terms are >> confusion-safe. >> > > >> >> &

Re: [OPSAWG] New I-D -> Guidelines for Charactering "OAM"

;> >> GIM>> I agree with that wholeheartedly. >> >>> >>> >>> This is a tricky little subject and I know that Carlos and I expected it >>> to generate more than a little discussion. If we end up with “everything is >>> OK and n

Re: [OPSAWG] New I-D -> Guidelines for Charactering "OAM"

he intent. I would > suggest explicit terms such as: “User Data Embedded OAM” or “OAM-embedded > User Data”. > > > > Thank you. > > > > Cheers, > > Med > > > > *De :* OPSAWG *De la part de* Carlos Pignataro > *Envoyé :* vendredi 5 janvier 2024 21:39 >

Re: [OPSAWG] New I-D -> Guidelines for Charactering "OAM"

De la part de Carlos Pignataro Envoyé : vendredi 5 janvier 2024 21:39 À : Ops Area WG ; Adrian Farrel Objet : [OPSAWG] New I-D -> Guidelines for Charactering "OAM" Hi, Ops Area WG, Every now and again, there are discussions on how to best characterize or qualify a particular kind

Re: [OPSAWG] New I-D -> Guidelines for Charactering "OAM"

lly, while others already have >> perfect definitions, that will lead to something similar to this document >> to bring the good into the light. >> >> >> >> Further comments in line… >> >> >> >> >> >> *From:* Greg Mirsky >> *Se

Re: [OPSAWG] New I-D -> Guidelines for Charactering "OAM"

g the good into the light. > > > > Further comments in line… > > > > > > *From:* Greg Mirsky > *Sent:* 12 January 2024 00:09 > *To:* Carlos Pignataro ; Adrian Farrel < > adr...@olddog.co.uk> > *Cc:* Ops Area WG ; IETF IPPM WG ; mpls < > m...@ietf

Re: [OPSAWG] New I-D -> Guidelines for Charactering "OAM"

WG ; mpls ; spring ; DetNet WG Subject: Re: [OPSAWG] New I-D -> Guidelines for Charactering "OAM" * Hi Carlos and Adrian, thank you for starting this work. I believe that having a common dictionary helps in having more productive discussions. I took the liberty of

Re: [OPSAWG] New I-D -> Guidelines for Charactering "OAM"

- Hi Carlos and Adrian, thank you for starting this work. I believe that having a common dictionary helps in having more productive discussions. I took the liberty of inviting all the WGs which you invited to review the document and added DetNet WG. Please feel free to trim the distribution

Re: [OPSAWG] New I-D -> Guidelines for Charactering "OAM"

Carlos Pignataro wrote: > The more practical approach, considering the above, seems to progress this > document as an RFC and use the same BCP 161 (as RFC6291) -- not sure how to > signal that in the I-D. Yes, adding this new RFC to BCP161 would make sense. I don't think that there

Re: [OPSAWG] New I-D -> Guidelines for Charactering "OAM"

Many thanks Michael for the review and useful feedback! Please find some follow-ups inline. On Sun, Jan 7, 2024 at 2:54 PM Michael Richardson wrote: > > Carlos Pignataro wrote: > > We would appreciate feedback and input on this position, which aims > at > > updating the guidelines for

Re: [OPSAWG] New I-D -> Guidelines for Charactering "OAM"

Carlos Pignataro wrote: > We would appreciate feedback and input on this position, which aims at > updating the guidelines for the "OAM" acronym, with unambiguous guidelines > for their modifiers. > Guidelines for Charactering "OAM": >

[OPSAWG] New I-D -> Guidelines for Charactering "OAM"

Hi, Ops Area WG, Every now and again, there are discussions on how to best characterize or qualify a particular kind of "OAM", as well as misunderstandings due to having different definitions and contexts for a given term. A case in point is "in-band" or "out-of-band" OAM, as recently surfaced at