[netmod] Re: YANG module vs YANG data model

[Scott Mansfield <[e-mail]>]

Here is the guidance I have been using in the IEEE 802 YANG coordination group.  It may not be perfect, but it makes a distinction between model and module in what I feel is consistent.

Research based on IETF documents…
•  YANG Data Model

  *   Not explicitly defined.  Data model is defined in the terminology section of IETF RFC 7950 as: “data model: A data model describes how data is represented and accessed.”
•  YANG Module

  *   In IETF RFC 7950:
     *   Section 3:
        *   module: A YANG module defines hierarchies of schema nodes. With its definitions and the definitions it imports or includes from elsewhere, a module is self-contained and “compilable”.
     *   Section 4.1:
        *   “YANG structures data models into modules and submodules.”
     *   Section 4.2.1:
        *   “YANG data models are defined in modules. A module contains a collection of related definitions.”
     *   Section 5.2: “YANG modules and submodules are typically stored in files, one “module” or “submodule” statement per file.”
IEEE 802 YANG coordination group definitions:

  *   YANG model
     *   One or more YANG modules used to configure and monitor the managed element or system.
  *   YANG module
     *   The description of the data model used to configure and monitor the managed element or system. A YANG module defines a hierarchy of nodes that can be used for NETCONF-based (see IETF RFC 7803) and RESTCONF-based (see IETF RFC 8040) operations.
  *   Schema tree
     *   The definition hierarchy specified within a module. [IETF RFC 7950]
  *   Schema
     *   A collection of schema trees with a common root. [IETF RFC 8528]
Hope this helps.

-scott.

From: IGNACIO DOMINGUEZ MARTINEZ-CASANUEVA <[e-mail]>
Sent: Tuesday, September 24, 2024 4:59 AM
To: [e-mail]
Subject: [netmod] YANG module vs YANG data model

Dear NETMOD WG,

Since I started working with YANG, I have felt the impression that we tend to use the terms “module” and “model” indistinctly, leading to misunderstandings.

According to RFC7950:

“a data model describes how data is represented and accessed.”

And later we can find:

                “YANG structures data models into modules and submodules.”
And:
                “YANG data models are defined in modules.  A module contains a collection of related definitions.”

The identification and versioning of YANG modules and submodules is clear, and in fact, keeps evolving as we have seen in the YANG Semantic Versioning<https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-semver/> discussions. However, when it comes to YANG data models, to the best of my knowledge, there are no means for identifying them.

In my opinion, this is a limitation that is hindering the cataloguing and access to YANG data. From the standpoint of a data consumer, what you care about is the data model, that is, the compiled hierarchy or collection of imported, deviation, and augmentation modules. Let’s put an example with two different data models:


  1.  Module A (name: module-A) --> augmented by Module B (name:module-B)
  2.  Module A (name: module-A) --> augmented by Module C (name:module-C)

How do we refer to the first data model? Should we name it “module-A”, like the parent or root module? Please, also note here that concepts like “parent module” or “root module” have not been formally defined in the scope of YANG data modelling.

How about the second data model in the example? We cannot name it “module-A” as we would have a naming conflict with the first data model.

I have seen other activities within the IETF that have come across this issue. For instance, An Architecture for YANG-Push to Message Broker Integration<https://datatracker.ietf.org/doc/draft-ietf-nmop-yang-message-broker-integration/00/> with the implementation of the YANG Schema Registry. In this case, the YANG data models (not the modules), and therefore, the YANG schemas, need to be uniquely identified in the registry. However, the algorithm used for generating the schema IDs is still unclear.

I think the YANG Packages<https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-packages/> draft aimed at solving this, though I’m missing why the document was abandoned. I would kindly appreciate I someone could shed some light.

Many thanks!

Best regards,
Nacho.


________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição