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 <justin.iur...@uliege.be> 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 <adr...@olddog.co.uk> 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 <alex.huang-f...@insa-lyon.fr >>> <mailto:alex.huang-f...@insa-lyon.fr>> >>> *Sent:*23 July 2024 22:38 >>> *To:*draft-ietf-opsawg-oam-characterization.auth...@ietf.org >>> <mailto:draft-ietf-opsawg-oam-characterization.auth...@ietf.org> >>> *Cc:*opsawg <opsawg@ietf.org <mailto:opsawg@ietf.org>>; Benoit Claise >>> <benoit.cla...@huawei.com <mailto:benoit.cla...@huawei.com>>; Thomas. Graf >>> <thomas.g...@swisscom.com <mailto:thomas.g...@swisscom.com>> >>> *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 -- opsawg@ietf.org >> To unsubscribe send an email to opsawg-le...@ietf.org
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
