Hi Rob, Makes sense to me and thanks for supplying OLD/NEW ;-)
I initially tried to avoid including more details on submodules because as we had this generic note in the document: Note that the term 'module' may be used as a generic term for a YANG module or submodule. When describing properties that are specific to submodules, the term 'submodule' is used instead. That's said, I went with a slight version of your proposed modification. This basically recalls that independent of the submodules, this is still viewed as a single YANG module. Please check the same link and let me know if you still have any concern. Thanks, Rob. Cheers, Med De : Rob Wilton (rwilton) <rwil...@cisco.com> Envoyé : jeudi 10 avril 2025 12:33 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>; Scott Mansfield <scott.mansfi...@ericsson.com>; Benoit Claise <benoit.claise=40huawei....@dmarc.ietf.org>; Lou Berger <lber...@labn.net>; Mahesh Jethanandani <mjethanand...@gmail.com> Cc : netmod@ietf.org Objet : Re: [netmod] Re: data model vs module Again (RE: Mahesh Jethanandani's No Objection on draft-ietf-ospf-sr-yang-37: (with COMMENT)) Hi Med, Sorry, I was catching up with thread, and I thought that I was fine with it, but I have a problem with the current definition because the text is unclear with regards to submodules, arguably it is worse because it implies that if you have a module including submodules that means that it should be referred to a YANG data model rather than a YANG module. Reading the text here, 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 states that a "YANG Module" is one .yang file. I think that is wrong when a YANG Module includes Submodules. Submodules are separate .yang files, but they are not separate YANG modules. They are YANG Submodules of a YANG Module. A "YANG Module" should effectively refer to a single .yang file that starts with a module statement, but the YANG module logically includes all related submodules in separate .yang files. Otherwise, the proposed definition will conflict with RFC 7950, since it states: o 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". Submodules are neither self-contained, nor independently compilable. Hence, I would propose that you tweak the text to something like: OLD: A YANG module 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]). NEW: A YANG module is typically a single ".yang" file, starting with a "module" statement. A YANG module may comprise included submodules that are stored in separate ".yang" files starting with a "submodule" statement. A YANG data model can consist (1) of a single YANG module (e.g., [RFC9129]) or (2) multiple YANG modules (e.g., [RFC7407]). Kind regards, Rob From: mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> Date: Wednesday, 9 April 2025 at 18:05 To: Scott Mansfield <scott.mansfi...@ericsson.com<mailto:scott.mansfi...@ericsson.com>>, Benoit Claise <benoit.claise=40huawei....@dmarc.ietf.org<mailto:benoit.claise=40huawei....@dmarc.ietf.org>>, Lou Berger <lber...@labn.net<mailto:lber...@labn.net>>, Mahesh Jethanandani <mjethanand...@gmail.com<mailto:mjethanand...@gmail.com>> Cc: netmod@ietf.org<mailto:netmod@ietf.org> <netmod@ietf.org<mailto:netmod@ietf.org>> Subject: [netmod] Re: data model vs module Again (RE: Mahesh Jethanandani's No Objection on draft-ietf-ospf-sr-yang-37: (with COMMENT)) Hi Scott, all, Glad to hear this is useful for other SDOs, as well. Unless I hear strong objections, the change will be implemented early next week. Cheers, Med De : Scott Mansfield <scott.mansfi...@ericsson.com<mailto:scott.mansfi...@ericsson.com>> Envoyé : mercredi 9 avril 2025 12:24 À : Benoit Claise <benoit.claise=40huawei....@dmarc.ietf.org<mailto:benoit.claise=40huawei....@dmarc.ietf.org>>; BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>>; Lou Berger <lber...@labn.net<mailto:lber...@labn.net>>; Mahesh Jethanandani <mjethanand...@gmail.com<mailto:mjethanand...@gmail.com>> Cc : netmod@ietf.org<mailto:netmod@ietf.org> Objet : RE: [netmod] Re: data model vs module Again (RE: Mahesh Jethanandani's No Objection on draft-ietf-ospf-sr-yang-37: (with COMMENT)) The amount of work and consideration to reach the current text is extremely appreciated. This terminology has spawned hours and hours of discussion in other SDOs, so it is welcome to have an IETF guideline on the topic. The text in 8407bis is clear and provides a practical definition of the terms that can be adopted over time by SDOs/Industry that build YANG data models. Many thanks, -scott. From: Benoit Claise <benoit.claise=40huawei....@dmarc.ietf.org<mailto:benoit.claise=40huawei....@dmarc.ietf.org>> Sent: Tuesday, April 8, 2025 5:04 AM To: mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>; Lou Berger <lber...@labn.net<mailto:lber...@labn.net>>; Mahesh Jethanandani <mjethanand...@gmail.com<mailto:mjethanand...@gmail.com>> Cc: netmod@ietf.org<mailto:netmod@ietf.org> Subject: [netmod] Re: data model vs module Again (RE: Mahesh Jethanandani's No Objection on draft-ietf-ospf-sr-yang-37: (with COMMENT)) 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<mailto: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><mailto:lber...@labn.net> Envoyé : lundi 7 avril 2025 13:46 À : Mahesh Jethanandani <mjethanand...@gmail.com><mailto:mjethanand...@gmail.com> Cc : netmod@ietf.org<mailto:netmod@ietf.org>; BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com><mailto: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<mailto: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 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<mailto:netmod@ietf.org> To unsubscribe send an email to netmod-le...@ietf.org<mailto:netmod-le...@ietf.org> ____________________________________________________________________________________________________________ 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. ____________________________________________________________________________________________________________ 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 to netmod-le...@ietf.org
