I agree with Andy. It would also be good to have a tool to translate v2 to v1
modules, sounds like a good vibe-coding hackathon project eventually.
Regards,Reshad.
On Thursday, May 7, 2026 at 02:34:38 PM EDT, Andy Bierman
<[email protected]> wrote:
On Wed, May 6, 2026 at 7:06 PM Qin Wu <[email protected]> wrote:
Agee with Andy, refactoring RFC7950 is just a small step. YANG update should be
driven by Vendor deployment issues. We should engage YANG tools development
team to help review the proposed changes to this common building block,
especially new YANG statements.
In order to deploy a new YANG module using 2.0 statements, a standard mapping
should bedefined to generate a YANG 1.1 version of the module by converting new
statements to extensions.This is consistent with creating a non-NMDA version of
a module for <get> operation support.This is also theoretical since there are
no new YANG 2.0 statements yet.
Otherwise, the new YANG 2.0 modules are completely isolated and unusable until
all the required toolsare updated. It would be better if YANG 1.1 tooling
could still be used to implement a YANG 2.0 module.
-Qin
Andy
发件人: Andy Bierman [mailto:[email protected]]
发送时间: 2026年5月2日 1:47
收件人: Lou Berger <[email protected]>
抄送: NetMod WG <[email protected]>; NetMod WG Chairs <[email protected]>
主题: [netmod] Re: WG adoption call: draft-yn-netmod-yang2-02
On Mon, Apr 27, 2026 at 2:43 PM Lou Berger <[email protected]> wrote:
Hello, This email begins a 2-week adoption poll for:
https://datatracker.ietf.org/doc/draft-yn-netmod-yang2/ Please voice your
support or technical objections to adoption on thelist by the end of the day
(any time zone) May 11.
The world (and WG) hasbeen using a Continuous Integration approach with YANG
for 16+ years.
Lots of standard and proprietary YANG extensions have been added.
All the tools get along, but all extensions are purely optional to implement.
A new language version is 100% mandatory to implement, but existing tools will
reject the module.
Harder for vendors but arguably better for end users. It is more precise than
extensions, so
implementation consistency might be much better.
A new language version would require upgrading most tools, not just pyang.
Client and server tools are far more complex and take longer to update.
That is why a YANG 1.1 back-translation might be needed (i.e., convert new
stmts to extensions).
Vendors need to be able to upgrade selectively and keep all existing modules
and code working.
I don't know if a new YANG language version is needed or not.
The WG should consider vendor deployment issues, not just WG process issues.
Thank you,Lou (as Co-chair)
Andy
_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]
