YANG profiles and views

[italobusi]

There a trend (especially in IETF WGs) to create new YANG models to address some specific use cases rather than re-using existing YANG models because existing YANG models either provides more information than needed for that specific application or the information provided is not formatted as expected by the application

Slides presented and discussed during the IETF 121 side meeting: YANG Profiles and Views v00.pptx

[italobusi]

An example for the need of a profile, is the current debate in NMOP WG where there are two competing proposals for YANG models for SIMAP:

1. augment RFC8345 with new data nodes to address the gaps of RFC 8345 to address the SIMAP requirements
2. use RFC8795, which is augmenting RFC8345 and already addressing some (if not all) the gaps of RFC 8345 to address the SIMAP requirements

The concern raised against proposal 2 is that the YANG model defined in RFC8795 is quite huge (thousand of lines of codes) while for the SIMAP application only few attributes are needed

[italobusi]

An example for the need of a view is the current debated in NMOP WG for the modelling of bidirectional links

RFC 8345 models bidirectional links as two unidirectional link instances between the same two TPs. This model design has proven very convenient for some applications developed on top of RFC 8345 augmentations defined in TEAS and CCAMP WGs

However, there are some applications that would benefit from seeing the bidirectional model being model as a single link with a leaf indicating that it is bidirectional

It could be useful to have a mechanisms that these applications can use to get the information formatted as they need with no need to change the YANG data models already standardized

YANG views can be seen as a mechanisms that applications can use to create SQL-like views over YANG datastores

[plajjan]

I think the issue description should state the content body, like if this is a problem statement (as per the slides preso) then the github issue description should include the problem statement.

I am against adding some notion of profiles or views to the YANG language. I don't really think this is a language feature at all. It seems to me that the problem you describe is best solved by having a well fitting YANG model. YANG models can be made to fit multiple use-cases / scenarios through if-features or using a collection of YANG models that augment, in order to provide a choice of which models / features to implement. The example you bring up is that RFC8795 is huge and that only a few lines are needed. This means the model didn't use if-features or multiple YANG models to provide a selectable choice of features that is suitable for your use case. If YANG models aren't well written for the use cases they intend to solve, then we can't fix that by slapping on more things in the YANG language. I think you are really asking for a RFC8795 with if-features to suite your use case.

Let's say we had views, like offered by some SQL databases, what would that mean? I think it means we have an actual table somewhere and from that table, we select and transform the data in some way to produce a view, which is like a virtual table. In YANG terms, the actual table would be described by a YANG model and the view / virtual table would be described by another YANG model. So views are rather a feature that a NETCONF server could use to expose data in different ways, more than a feature that is suitable for the YANG language itself.