Hi Linda, Thanks for you IETF LC Genart review
We are tracking your comments in github and plan to address them, together with other IETF LC comments, in the next couple of weeks: https://github.com/IETF-TEAS-WG/ietf-teas-yang-path-computation/issues/133 Italo (on behalf of co-authors/contributors) > -----Original Message----- > From: Linda Dunbar via Datatracker <[email protected]> > Sent: giovedì 3 settembre 2026 01:01 > To: [email protected] > Cc: [email protected]; [email protected]; > [email protected] > Subject: draft-ietf-teas-yang-path-computation-28 ietf last call Genart review > > Document: draft-ietf-teas-yang-path-computation > Title: A YANG Data Model for requesting path computation > Reviewer: Linda Dunbar > Review result: Almost Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area Review > Team (Gen-ART) reviews all IETF documents being processed by the IESG for > the IETF Chair. Please treat these comments just like any other last call > comments. > > For more information, please see the FAQ at > > <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. > > Document: draft-ietf-teas-yang-path-computation-28 > Reviewer: Linda Dunbar > Review Date: 2026-09-02 > IETF LC End Date: 2026-09-09 > IESG Telechat date: Not scheduled for a telechat > > Summary: > This document defines a YANG data model to request TE path computation by > augmenting the TE tunnel RPCs. Major issues: None Minor issues: > > - The document explains three related approaches: stateless path computation > RPC, optional transient state in the operational datastore, and compute-only > TE > tunnel paths. The discussion is useful, but it is spread across Section 3.3 > and > Section 3.3.1. A short comparison table or summary paragraph would help > clarify when each mechanism should be used. For example: > The RPC is intended for stateless on-demand computation. The transient-state > option is used when the client may later request setup of the same computed > path. Compute-only tunnels are used when persistent tracking of the > computed > path is required. > > - Section 3.3 says that path verification is always necessary because the path > set up later may not be exactly the same as the path previously computed. > Does this document defines any verification mechanism, or only > requires/assumes that verification is done by other mechanisms? > > Nits/editorial comments: > > - Section 1.1: > s/“RFC number fpr”/“RFC number for”/ > - Section 2: > s/“The presented uses cases”/“The presented use cases”/ > > - Section 2.2: > s/“inter-domains links”/“inter-domain links”/ > > - Section 3.3: > s/“it is possible repeat the whole process”/“it is possible to repeat the > whole process”/ > > - Section 3.3.1: > s/“multi-domain path computation scenario scenarios”/“multi-domain path > computation scenarios”/ > > - Section 4: > s/“there could multiple choices”/“there could be multiple choices”/ > > - Section 5.3: > s/“These attributes includes”/“These attributes include”/ > > - Section 5.4: > s/“The models supports”/“The model supports”/ > > - YANG module description: > s/“exiting te-tunnel”/“existing te-tunnel”/ > > - Security Considerations: > s/“also applies to the use of this RPC”/“also apply to the use of this > RPC”/ > > Best Regards, > Linda Dunbar > _______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
