YANG++

[abierman]

YANG++

YANG++ is a data modeling language under development.

Project Goals

• Complete the design and specification of the YANG++ language

• Design and implement open-source plugins

  • Native compiler support for YANG++
  • YANG 1.1 Translation Tool

Documentation

• YANG++ DRAFT

[BalazsLengyel]

There already was one such effort. See https://datatracker.ietf.org/doc/rfc6095/

In 3GPP we are modeling object/classes with YANG 1.1. That obviously has problems.

I would love this if it would be widely available.

[abierman]

The plan is to move the work to the netmod-wg repo and a NETMOD WG draft. I only write docs in sphinx/RST now, so that's how I started writing it. The repo is public now if you want to see the RST source YANG++ repo

[janlindblad]

While many people with programmer background have suggested similar things (even 10 years ago), it would such a major shakeup we should consider not only replacing the language version number (e.g. 2.0), but the entire language name (YANG++ as mentioned might be apt). It would be a strong shift from an operator readability focus to programming language. I am rather skeptic of going in this direction, but we can talk about it.

[abierman]

The name YANG 2.0 can be used. The name YANG++ is not important. The issue I see is that groupings are a simplistic solution already pushed to the limit.

[abierman]

"strong shift from an operator readability focus to programming language"

Is that what we have now with YANG? I guess so. It sure looks like YANG designers that try to create reusable building blocks are the lowest priority.

IMO the natural progression from ad-hoc #define descriptions (C) to organized hierarchical descriptions (C++) was a step forward.

[abierman]

Perhaps the term YANG++ is distracting but if you understand what the evolution from C to C++ is about, the name fits. In the end, there is only the 'conceptual' schema tree that is constructed from the YANG library contents. There are typedefs, groupings, base objects, augment objects, deviations, annotations, and features spread all over the place. Designers want to pretend that groupings provide a real abstraction layer, but they don't.

This YANG 1.1 approach is just one way to construct the final schema tree. YANG++ proposes a different way, but it is compatible with existing YANG 1.1.

[plajjan]

I'm really not sure the analogies with C and C++ helps here. As a counterpoint, C is a small clean language with few keywords. C++ is a beast with all the features you can find under the sun. I think you see some particular improvements, but that's in the eye of the beholder, so might be better to just state exactly what you see as improvement :) We are trying to get subject matter experts, mostly network engineers, to do a bit of data modeling and I'm really not sure trying to turn them into programming language experts is going to help that. A simple language to make people productive is a good thing.

The IETF is outputting a lot of YANG models. Very very few of them are implemented by equipment vendors. NETCONF / YANG in itself is still a success since vendors do use it to model their own proprietary YANG models, but it's taken a very long time to get here and if we are hoping for some adoption of standardized IETF device YANG models I'm just not sure it helps to radically advance the language in some exciting new direction.

I think that some form of backwards compatibility is an absolute must, like we just can't afford to start over entirely at this point. YANG 2.0 (if that's what it's called) got to be able to leverage YANG 1.x tooling etc with minimal changes, so if we are talking about enabling entirely new things in 2.0 then it needs to compile to 1.1, which is exactly the approach you are taking, if I understand things correctly. I just want to emphasize how important I think this is!

I have only skimmed YANG++ so far and so I will refrain from commenting on it. I will attempt a more thorough read soon! While I do agree with the particular critique on reusability, groupins lacking bla bla, this is just not top of mind of most operators trying to do automation and wanting better programmatic APIs.

[abierman]

OK forget C++. YANG++ is not a programming language. It simply adds well-established object-oriented design practices to the YANG grouping. Managing the grouping instead of every uses-stmt is the critical change. IMO a class hierarchy is easier for readers to understand, and more powerful for writers. No doubt the tooling is harder. Toolmakers are the lowest priority.

The solution details can be changed of course. If there is no consensus on the problem statement then those do not matter anyway.

[kwatsen]

There's another issue regarding the reusability of YANG structures. Module designers rarely create reusable groupings, and so have schema-mount, full-include, etc. YANG++ seems to address this. I look forward to Andy's presentation in the NETMOD 121 session.

[kwatsen]

Balazs: we have an RFC 6095 that describes such, what has changed since? Andy: problem, extensions must occur in the uses statement, which adds complexity Andy: the same update would have to be set in every uses. Andy: desire is the make the change to the grouping in one place

Rob: could we add an ability to augment a grouping Rob: agrees with Jan's comment that this same the beginning of a different language (not YANG-next)

Kent: YANG++ isn't a full-on OO modeling language Rob: YANG doesn't model objects per se Andy: augmenting an augment is impossible

Reusability is an important problem This idea seems to be over the target

Andy: agree w/ Rob wrt to YANG-next-next (another language) Kent: if nothing else, can cherry-pick specific ideas (e.g., the "any" statement)

[abierman]

Most of the YANG++ features could be achieved with improvements to groupings. An "augment-grouping" statement would be just as complex to implement as a derived class. However, Jan is right about avoiding new terminology. The ++ terminology is too distracting.

What about RFC 6095? YANG++ has Virtual Objects This builds on the 'abstract' complex type in the RFC. Is there any interest in this multi-layered abstraction shown in sec 1.5.1 of this RFC?