Re: [netmod] YANG next

[Ladislav Lhotka <[e-mail]>]

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.

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.

Lada

> 
> 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