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
_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]
