We already have some RFCs and drafts that propose extensions that would/could go into YANG 1.2. I would like to have an “official” agreement/document/wiki that lists what is planned to go into 1.2 whenever it happens. That would help us to have a platform that contains a well defined set of additions beyond YANG 1.1.
Regards Balazs From: netmod <netmod-boun...@ietf.org> On Behalf Of Andy Bierman Sent: 2019. július 24., szerda 10:10 To: Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de>; Andy Bierman <a...@yumaworks.com>; NETMOD WG <netmod@ietf.org> Subject: Re: [netmod] YANG next On Wed, Jul 24, 2019 at 6:52 AM Ladislav Lhotka <lho...@nic.cz <mailto:lho...@nic.cz> > wrote: Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de <mailto:j.schoenwael...@jacobs-university.de> > writes: > On Tue, Jul 23, 2019 at 02:00:29PM -0400, Ladislav Lhotka wrote: >> >> This problem is actually not limited to YANG itself - people are reporting >> problems with the transition to NMDA. >> > > The YANG update from 1 to 1.1 mostly affected compiler writers - and > to a much lesser extend module authors and module implementors. NMDA, > affects client and server implementors much more directly, additional > instrumentation on the server side needs to be written, application > logic on the client side needs to be adjusted. NMDA is an evolution of > architectural principles and this already indicates that there is a > certain investment to make. But both updates induced some changes in YANG modules that affect users and integrators. Take ietf-ospf module as an example: it is of course a great addition to the YANG module collection, but in order to use it, all tools have to support - YANG 1.1, e.g. because of the special XPath functions, and - NMDA, because otherwise state data are missing. Despite the fact that YANG 1.1 and NMDA are undoubtedly improvements, users may get frustrated if lazy authors (including myself) don't update their tools in a timely manner. > > If we discuss YANG next, we should compare it to the YANG 1 to 1.1 > transition and not to the NMDA transition. When we started YANG 1.1 Both types of changes may have similar effects on YANG users. > work, there were people who said that nobody would implement it. But > then implementations were adopted relatively fast when we finalized > YANG 1.1. When we started YANG 1.1, there were only a few YANG modules around with little practical use, so nobody really cared. The situation is now very different. Not that different. The IETF does not value stability that much. Maybe customer expectations are different, but some of us have to follow 2 simple rules: - Whatever works SHALL continue to work - If you changed how it works, you broke it (even if you fixed it) Some customers even think they should be able to upgrade from any existing version to any new version, and these rules still hold. Therefore every change in server behavior must be "opt-in" by the vendor and maybe the client as well. Instead of automatically upgrading because of course you want the spiffy new features, vendors want the behavior to stay exactly the same (unless they choose to change it). There is no real need for YANG 1.2 unless and until NBC changes need to be made, and we try to avoid doing that. Lada Andy > > While a collection of patches (updates) of YANG 1.1 may sound simpler, > I am not sure this is really true. We will loose a common baseline and > instead get complexity since we will get systems that all support > different sets of patches (updates) of YANG 1.1. I believe we are all > much better off if we have a common baseline language and tools that > support the common baseline language. Again, if done right, YANG next > will mostly affect compiler writers and tool makers and not so much > module authors and implementors. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <https://www.jacobs-university.de/> -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
