Hi Kent, Thanks for your feedback. Am working on those and hope to have an updated draft pretty soon.
I would indeed like to present this in the WG at Madrid. I am working out my travel plans for the same. -Rajesh From: Kent Watsen <kent+i...@watsen.net> Date: Friday, June 20, 2025 at 8:47 PM To: Rajesh Tarakkad Venkateswaran (rtv) <rtv=40cisco....@dmarc.ietf.org> Cc: netmod@ietf.org <netmod@ietf.org>, Veena Ramamoorthy (vemoorth) <vemoo...@cisco.com>, Sarthak Jain (sarthakj) <sarth...@cisco.com>, Sai Venkata Giri Karnati (saikarna) <saika...@cisco.com>, Venkata Harish Nagamangalam (vnagaman) <vnaga...@cisco.com>, Rob Wilton (rwilton) <rwil...@cisco.com> Subject: [netmod] Re: [NETMOD] New Draft: Enhancements to YANG Language for Capturing Subtree Replacements Hi Rejesh, Thanks for joining the list and resending. The motivation is clear and good. Referencing https://github.com/netmod-wg/yang-next/issues/130 is appreciated. The document is somewhat difficult to read due to formatting issues. Please put more text into code blocks. The solution is unclear, more description text would help, especially on each example. There will soon be a call-for-presentations for the IETF 123 meeting in July. Perhaps you would like to present this work to the WG? Kent On Jun 19, 2025, at 5:43 AM, Rajesh Tarakkad Venkateswaran (rtv) <rtv=40cisco....@dmarc.ietf.org> wrote: resending due to an email subscription issue, hopefully now sorted. Dear NETMOD Working Group, I would like to bring to your attention a new draft that addresses an important issue in YANG model evolution: draft-rtv-netmod-yang-subtree-replacement-00. This is available at: https://rajesh-rtv.github.io/yang-replacement/draft-rtv-netmod-yang-subtree-replacement.html This is an early (--00) draft intended as a starting point for discussion, and we welcome your feedback. Problem statement: When YANG model nodes are deprecated or obsoleted, information about replacement paths is typically documented in separate, unstructured documents. This makes migration difficult, error-prone, and difficult for automation. Network operators must manually search through external documentation to find replacement paths, and tools cannot programmatically identify replacement nodes or assist in migration. Our draft proposes a YANG Extension mechanism for use with existing deployed versions of YANG, enabling automation tools to identify replacement nodes and assist users in migrating from deprecated elements to their replacements. The approach described in this draft is based on internal Cisco infrastructure that we have successfully implemented and used. We believe this practical experience validates both the need for this solution and the viability of our approach. We would greatly appreciate if members could review this short document and provide feedback on: 1. Do others experience this issue and agree that it should be solved? 2. Is it beneficial to solve this in the existing version of YANG rather than waiting for a new version? 3. Is our proposed solution approach on the right track? We hope to present and discuss this draft at the upcoming IETF meeting in Madrid and would value your thoughts before then. Thank you for your time and consideration. Best regards, Rajesh TV _______________________________________________ netmod mailing list -- netmod@ietf.org<mailto:netmod@ietf.org> To unsubscribe send an email to netmod-le...@ietf.org<mailto:netmod-le...@ietf.org>
_______________________________________________ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
