On Fri, Apr 04, 2025 at 12:52:01PM +0000, IGNACIO DOMINGUEZ MARTINEZ-CASANUEVA wrote: > > However, I would like to take advantage of this thread to bring back the > concern I raised a few months ago on the limitations for identifying and > managing YANG data models. > > I understand and I can live with the proposal to define a “(YANG) data model” > as a set of YANG modules. If we all agree on this definition, then I think we > really need to clarify how we identify and refer to a YANG data model. >
Its quirky. Ideally we would have a data model for some technology X. Often we start with that and a corresponding YANG module (it could be several YANG modules but it is often exactly one). Over time, there are extensions of the technology X and thus extensions of the data model for X, typically encoded in additional YANG modules. Instead of seeing this as an extension of the X data model, we often treat the extension as its own universe. Here is an example: RFC 9129: YANG Data Model for the OSPF Protocol RFC 9587: YANG Data Model for OSPFv3 Extended Link State Advertisements (LSAs) Perhaps RFC 9587 should have been titled "Extension of the YANG Data Model for the OSPF Protocol for Extended Link State Advertisements (LSAs)". Yeah, titles get awkward, so we take sloppy shortcuts. (You can likely find other examples here [1] or in I-Ds not yet published.) In short, we have no clear idea what the scope of our models are, perhaps YANG packages will eventually help if YANG data models map to YANG packages. /js [1] https://en.wikipedia.org/wiki/YANG#Standards-track_data_models -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
