Many thanks Thomas and Alex, both for the support, as well as for the useful suggestions.
Alex, “on-path” is much more descriptive than “in-band” for sure! Thomas, Alex, will send an iteration of the draft incorporating the Node Type suggestion. (BTW, I think you meant rfc9197 or rfc9359 instead of rfc 9398?) Thanks! Carlos. > On Mar 18, 2024, at 2:55 AM, Alex Huang Feng <alex.huang-f...@insa-lyon.fr> > wrote: > > Dear Carlos and Adrian, > > As I said in the chat during the OPSAWG meeting, I also support this document. > I don’t have a lot of specific examples of how the terminology are confusing, > but I am co-authoring draft-ietf-opsawg-ipfix-on-path-telemetry where it > started as an inband telemetry protocol and then we were asked to change this > terminology to “on-path telemetry protocol”. > Also I haven’t been able to find a clear formal definition of “on-path > telemetry protocol”. > > Thanks for the document, > Alex > >> On 18 Mar 2024, at 15:32, thomas.g...@swisscom.com wrote: >> >> Dear Carlos and Adrian, >> >> As the author of draft-ietf-opsawg-ipfix-on-path-telemetry, I care and value >> that you are defining OAM terminology. This is much needed. Count me on the >> list of people who misused the term inband previously. >> >> I would appreciate of you could add also OAM node type. As an example in RFC >> 9398 for IOAM the following types are defined >> >> IOAM encapsulation node >> IOAM transit node >> IOAM decapsulation node >> >> It would be very useful to have an OAM protocol agnostic terminology. >> >> Best wishes >> Thomas >> >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org <mailto:OPSAWG@ietf.org> >> https://www.ietf.org/mailman/listinfo/opsawg >
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
