Re: [netmod] YANG next

[Ladislav Lhotka <[e-mail]>]

On Tue, 2019-07-23 at 11:35 -0700, Andy Bierman wrote:
> 
> 
> 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? ;-)

I am actually fine with not doing any changes to YANG 1.1 at all, except perhaps
bug fixes. This doesn't necessarily mean closing the NETMOD WG, it would IMO be
immensely useful to rewrite the language specification and remove NETCONF- and
XML-specific part.

> There is no such thing as a critical extension in YANG 1.1.

One alternative to doing nothing is to introduce critical extensions but
temporarily forbid their use in IETF modules (so that existing tools continue to
work). This would allow for developing and testing new YANG features without
causing troubles to current YANG users. Specific areas and communities may
decide to treat some crictical extensions as required and use tools that support
them.

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

Yes, work on versioning and packages should continue.

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

I agree.

Lada

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