Thanks Alex, Adrian, and Justin! I do plan on submitting a revision soon, and I also feel these are sensible and stable based on the feedback we have received.
Thanks, Carlos. > On Jul 24, 2024, at 4:39 PM, Justin Iurman <[email protected]> wrote: > > +1 > > IMHO, keeping "Encapsulating", "Transit" and "Decapsulating" nodes > terminology (and related definitions) is the way to go. It's used in RFC 9197 > (and in all IOAM related documents as well), and I think folks are used to > those terms/definitions now. Besides, I don't see any other better terms (nor > definitions) to replace them. > > Thanks, > Justin > > On 7/24/24 10:05, Alex Huang Feng wrote: >> Dear Adrian, >> Thanks for the rapid response. >> IMO, (at least) the definitions of encapsulation, transit and decapsulation >> nodes are well defined (and also well understood from the IETF community), >> so I am personally not worried about any future changes to these definitions. >> I only wanted to get the perspective from the authors and I would say your >> response is rather encouraging. >> Cheers, >> Alex >>> On 23 Jul 2024, at 14:55, Adrian Farrel <[email protected]> wrote: >>> >>> Well timed email, Alex. >>> I made a note during today’s meeting to chase Benoit to see whether he is >>> happy with the references. >>> On reflection, getting Benoit happy may be a stretch. >>> The authors are working on polish. Carlos plans a revision “soon”, and I >>> plan to take a pass next week. >>> My gut feeling is that the terms are stable, but not completely cooked. >>> There is a risk of a small percentage churn. >>> We are, however, aware that it would be good to push this document hard and >>> fast to ensure that it can be available for everyone sooner rather than >>> later. >>> Obviously, we would really like references, but we are also aware that >>> normative references will (ultimately) cause delays in the RFC Editor Queue. >>> Let me say that the authors will do their best. >>> Can I encourage the WG to be proactive and try to get reviews done now so >>> that when we get to WGLC the document is already practically perfect. >>> Cheers, >>> Adrian >>> *From:*Alex Huang Feng <[email protected] >>> <mailto:[email protected]>> >>> *Sent:*23 July 2024 22:38 >>> *To:*[email protected] >>> <mailto:[email protected]> >>> *Cc:*opsawg <[email protected] <mailto:[email protected]>>; Benoit Claise >>> <[email protected] <mailto:[email protected]>>; Thomas. Graf >>> <[email protected] <mailto:[email protected]>> >>> *Subject:*Reference to oam-characterization draft >>> Dear authors, >>> Thanks a lot for writing and pushing this draft. It is very useful. >>> I only want to raise that our draft is now having a normative reference to >>> draft-ietf-opsawg-oam-characterization. >>> We are using the terms “encapsulation", “transit" and “decapsulation" node >>> in >>> https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-on-path-telemetry/ >>> <https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-on-path-telemetry/> >>> (See section 2 Terminology) >>> I would like to get the opinion from the authors on whether the definition >>> of these terms is stable enough to be used already on other documents. >>> The reason I am asking is because draft-ietf-opsawg-ipfix-on-path-telemetry >>> is currently very close to get a WGLC and we were wondering if using the >>> terms from oam-characterization is the way to go. >>> Regards, >>> Alex, on behalf of draft-ietf-opsawg-ipfix-on-path-telemetry authors >> _______________________________________________ >> OPSAWG mailing list -- [email protected] >> To unsubscribe send an email to [email protected]
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
