Hi,
https://author-tools.ietf.org/api/iddiff?url_1=https://netmod-wg.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.txt&url_2=https://netmod-wg.github.io/rfc8407bis/model-vs-module/draft-ietf-netmod-rfc8407bis.txt
This text makes a lot of sense.
And yes, it's time to have it in RFC8407bis, once for all
Regards, Benoit
On 4/7/2025 5:39 PM, mohamed.boucad...@orange.com wrote:
Hi Lou,
I like your suggestions. Updated the PR accordingly. The same link
below can be used to track the full changes.
Also, tweaked the text to reflect 1-3 items from Kent’s list.
Cheers,
Med
*De :*Lou Berger <lber...@labn.net>
*Envoyé :* lundi 7 avril 2025 13:46
*À :* Mahesh Jethanandani <mjethanand...@gmail.com>
*Cc :* netmod@ietf.org; BOUCADAIR Mohamed INNOV/NET
<mohamed.boucad...@orange.com>
*Objet :* Re: [netmod] Re: data model vs module Again (RE: Mahesh
Jethanandani's No Objection on draft-ietf-ospf-sr-yang-37: (with COMMENT))
Mehesh,
On 4/4/2025 11:05 AM, Mahesh Jethanandani wrote:
I like the idea of having the discussion here in netmod of the
terminology, where the expertise lies, and then taking it back to
IESG when we have final guidance.
I agree that the WG is the right place for this discussion.
Is your intent to send the document back to the WG to get agreement on
the new section, or do you just want the WG to discuss and agree on-list?
For those that missed it:
On 4/4/2025 1:28 AM, mohamed.boucad...@orange.com wrote:
Let's us use this discussion to converge on some clear guidance for every
one.
Here is a first draft of guidance I suggest we add to 8407bis. This
inspires from the guidance I shared earlier in this thread:
https://author-tools.ietf.org/api/iddiff?url_1=https://netmod-wg.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.txt&url_2=https://netmod-wg.github.io/rfc8407bis/model-vs-module/draft-ietf-netmod-rfc8407bis.txt
<https://author-tools.ietf.org/api/iddiff?url_1=https://netmod-wg.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.txt&url_2=https://netmod-wg.github.io/rfc8407bis/model-vs-module/draft-ietf-netmod-rfc8407bis.txt>
Which proposes a new section:
2.5. YANG Data Model vs. YANG Module
Both [RFC6020] and [RFC7950] make a distinction between the
following
concepts:
YANG data model: Describes how data is represented and accessed.
YANG structures data models into modules for ease of use
[RFC8309].
YANG module: Defines hierarchies of schema nodes to make a self-
contained and compilable block of YANG definitions and
inclusions.
Is typically a ".yang" file.
A YANG data model can consist (1) of a single YANG module (e.g.,
[RFC9129]) or (2) multiple YANG modules and YANG submodules (e.g.,
[RFC7407]).
Note that the term "YANG model" is sometimes used as an
abbreviation
of YANG data model. However, that term should be avoided in
favor of
YANG data model. Likewise, "YANG data module" should be avoided.
Even if a YANG data model is structured as a single YANG
module, YANG
data model term should be used in the title, abstract, and when the
overall design is described. "YANG module" should be used when a
specific "*.yang" file is quoted.
As contributor, I agree/like where this proposed text is heading. I
think it would be helpful to add some more guidance to authors and
reviewers on which term to use/expect. For example, state that when
using terminology related to YANG module specifications, e.g.,
augmentation or deviation, a "module" should be referenced, and that
when extending the concepts embodied in a module this is an extension
to the "YANG Model".
also some nits:
s/when/in the body of the document where/
s/quoted/referenced
Thanks,
Lou
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
netmod mailing list --netmod@ietf.org
To unsubscribe send an email tonetmod-le...@ietf.org
_______________________________________________
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org
