Re: [netmod] YANG next

[Andy Bierman <[e-mail]>]

On Tue, Jul 23, 2019 at 11:00 AM Ladislav Lhotka <[e-mail]> wrote:

> On Tue, 2019-07-23 at 09:22 -0700, Andy Bierman wrote:
> >
> >
> > On Tue, Jul 23, 2019 at 9:03 AM Ladislav Lhotka <[e-mail]> wrote:
> > > Hi,
> > >
> > > this morning I attended the side meeting "Next Step of IETF YANG". I
> was
> > > somewhat misled into thinking that it would be about future evolution
> of
> > > YANG
> > > the language, which was not the case at all. However, my personal
> conclusion
> > > from the meeting is that it would be a total disaster to throw in a new
> > > version
> > > of YANG within the next few years or so.
> > >
> >
> >
> > I hope a summary of the meeting is posted to the WG mailing list.
>
> I think so, minutes were taken.
>
> >
> > > The operators and equipment vendors are busy putting together YANG
> modules
> > > and
> > > tools, filling the gaps, coping with NMDA, schema mount, IETF versus
> > > OpenConfig
> > > etc. A new YANG version (and modules written in it) would IMO be
> extremely
> > > counter-productive at this rather turbulent stage.
> > >
> > > So, if we want to continue the yang-next discussion, I think we first
> have
> > > to
> > > figure out how to evolve YANG without making waves in the current YANG
> pond
> > > and
> > > let the operators and vendors do their work, without which YANG can
> never
> > > succeed.
> > >
> >
> > IMO a new version of YANG would not be disruptive (if done right).
> > The issue is whether it is cleaner in the long-run to introduce NBC
> changes
> > properly
> > with a new version number, or not so properly, through YANG extensions.
>
> I don't see much difference provided that the extensions will be properly
> signalled. But we have to take into account that some tools that people
> use may
> not be updated for quite some time, and if they cannot properly work with
> modules written for the new version (or extensions), then things will
> break.
>
>
So you want to work on YANG 1.2, but just the parts you want to change? ;-)
There is no such thing as a critical extension in YANG 1.1.
IMO it would be a bad idea to develop standard modules that relied on tool
support of
any extension. A tool is allowed to skip any extension when parsing a
module.
This cannot be changed in YANG 1.1.


> This problem is actually not limited to YANG itself - people are reporting
> problems with the transition to NMDA.
>
> >
> > E.g -- adding a leaf to the datastore that says "I don't follow the
> rules in
> > 7950"
> > is still breaking the YANG 1.1 contract.  Using extensions instead of
> real
> > statements
> > is problematic because they are optional to implement (as you point out
> all
> > the time).
>
> Yes, hence critical extensions. However, the problem is still the same -
> these
> changes require updated tools, and not all tools will be updated
> immediately. I
> think that we should make sure that (at least in the IETF) all modules
> will be
> compatible with tools supporting YANG 1.1, say for the next 5 years.
>
>
I am OK with the current WG priorities such as versioning.
Those YANG extensions simply clarify YANG 1.1 so no rules are broken
and no YANG 1.1 functionality is removed if a tool ignores the extensions.
Also OK with not working on YANG 1.2 or critical extensions.
There are no must-have features at this time.

Lada
>
>
Andy


> >
> > Seems like the WG is going the YANG extension route, which has its own
> set of
> > problems
> > compared to a new YANG language version.
> >
> >
> > > Lada
> >
> > Andy
> >
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>
>