Hi Med, I agree with your definitions. I believe I have applied this terminology to the latest version of https://datatracker.ietf.org/doc/draft-ietf-ospf-sr-yang/ Please confirm.
Note that we are going to update https://datatracker.ietf.org/doc/draft-ietf-isis-sr-yang/ with the analogous telecast comments from the OSPF SR model (not until next week due to primary editor vacation). Thanks, Acee > On Apr 7, 2025, at 11:39 AM, [email protected] 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 <[email protected]> > Envoyé : lundi 7 avril 2025 13:46 > À : Mahesh Jethanandani <[email protected]> > Cc : [email protected]; BOUCADAIR Mohamed INNOV/NET > <[email protected]> > 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, [email protected] 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 -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
