Hello Alex, " However, even in that case, an update to the original model is still required - you cannot simply say "let me use these data definitions from that other models", they need to be defined as a grouping" <Shiya> Oh sure, absolutely. As you pointed out in one of the earlier emails, if this could address 99+% of the cases, why not do it at least for the models which we think will have more chance of getting reused, say for instance, ietf-interfaces, ietf-hardware etc. And this we could do it today in YANG 1.1 and with no extra tools support - which is clearly an advantage over the new embed mechanisms for faster commercial deployments of the solutions. Isn't it?
Thanks, Shiya -----Original Message----- From: Alexander L Clemm <[email protected]> Sent: Thursday, August 1, 2024 10:49 PM To: Shiya Ashraf (Nokia) <[email protected]>; Alexander L Clemm <[email protected]>; Jean Quilbeuf <[email protected]>; [email protected] Subject: Re: [netmod] Re: Defining groupings after the fact? draft-jouqui-netmod-yang-full-include and the reuse of definitions [You don't often get email from [email protected]. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hello Shiya, re your comment on the "Once models have been defined this way, they cannot be altered after the fact": Well, I guess as William has pointed out, it is possible to update a model with another, equivalent model which pulls data node definitions into groupings and then uses those groupings. That would be a compatible change. The same groupings will then also be free for other models to use. However, even in that case, an update to the original model is still required - you cannot simply say "let me use these data definitions from that other models", they need to be defined as a grouping (or per Jean's proposal in the draft, you define a new construct that would let you "use" aka embed definitions without the need for a grouping to be defined). Cheers --- Alex On 8/1/2024 2:20 AM, Shiya Ashraf (Nokia) wrote: > Hi Alex, > > "<AC> Correct, you cannot augment a grouping. However, you can define a > second grouping and then use both groupings. I do think that with properly > designed modules that make extensive use of groupings 99+% of reuse scenarios > would be covered. " > <Shiya> Thanks for bringing this point up and I tend to fully agree here. In > fact when I was reading the schema mount RFC where it starts with the short > comings of "grouping", I also felt that there could be use-cases where some > of these aspects of the groupings can turn out to be its strengths. For eg: > for cases where you need greater control on what you want to embed on the > mounted tree, for instance, only a selection of the augments from the > original module or add new augments only on the embedding context etc. So > though schema-mount/full-embed are very good solutions for reusability of > existing YANG modules for certain use-cases with its own advantages, for many > cases the existing methods based on groupings might do the job and in a much > more simpler way. > > But then you say: " Once models have been defined this way, they cannot be > altered after the fact." > <Shiya> Could you explain more on this? Technically, One can still define a > new grouping with all the data nodes that are today in a standard module and > then replaces the content of the standard module with a simple uses statement > of the new grouping with out causing a backward compatibility issue or any > functional change, can’t we ? > > Thanks, > Shiya > > -----Original Message----- > From: Alexander L Clemm <[email protected]> > Sent: Thursday, August 1, 2024 12:37 AM > To: Jean Quilbeuf <[email protected]>; > [email protected] > Subject: [netmod] Re: Defining groupings after the fact? > draft-jouqui-netmod-yang-full-include and the reuse of definitions > > [You don't often get email from [email protected]. > Learn why this is important at > https://aka.ms/LearnAboutSenderIdentification ] > > CAUTION: This is an external email. Please be very careful when clicking > links or opening attachments. See the URL nok.it/ext for additional > information. > > > > Hi Jean, > > thank you - quick replies in line > > --- Alex > > On 7/30/2024 2:35 AM, Jean Quilbeuf wrote: >> Hello Alexander, >> I put some answers inline. >> >>> -----Original Message----- >>> From: Alexander L Clemm <[email protected]> >>> Sent: Monday, July 29, 2024 8:22 PM >>> To: [email protected] >>> Subject: [netmod] Defining groupings after the fact? >>> draft-jouqui-netmod-yang- full-include and the reuse of definitions >>> >>> Hello Jean, Benoit, Thomas, >>> >>> After your presentation at IETF 120, I looked at your draft >>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fda >>> tatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-jouqui-netmod-yang-full-i&da >>> ta=05%7C02%7Cshiya.ashraf%40nokia.com%7Cf800a99bb9ed462e8f7108dcb26b >>> a815%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638581422668726221 >>> %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI >>> 6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=NdC02cJcdQPE7hc76ekJos%2B >>> UoPjRQ4NEjYfLe4%2Ft%2B0k%3D&reserved=0 >>> nclude- >>> 02. >>> >>> >>> I do have some questions regarding what happens if the embedded >>> module is being augmented. Is the augmentation automatically >>> embedded as well; does such embedding need to be explicitly stated? >>> Is there a way to augment an embedded module only within the context of the >>> embedding module? >> Yes, as per the example in the slides: if you want ietf-interfaces augmented >> by ietf-ip, you have to embed them both. > <AC> I.e., you would need to augment the embedding module as well to embed > the augmentation. The aumentation of the embedding module would then include > a new "embed" statement to for the augmentation of the module that had been > originally embedded. Correct? >>> On a more general note, it strikes me that there is an increased >>> need in reusing definitions. In various forms, we see this in your >>> use cases, in network inventory use cases, in schema-mount, in >>> peer-mount. YANG does not provide good support for that, which is >>> somewhat ironic in that it does actually support several constructs >>> with reuse and extensibility in mind, from identities to groupings. >>> Hopefully the YANG-next effort will go a long ways towards improving >>> definition reuse to that the need for after-the-fact bandaids can be >>> avoided. >> Fully agree, the full embed as defined here should be a keyword in >> YANG-next. Similar constructs exist in protobuf and json-schema for instance. > <AC> Cool. </ALEX> >>> When it comes to reusing parts of definitions, it seems that a lot >>> of grief could be avoided if portions that are to be reused would >>> have been defined as groupings, which could then be used wherever needed. >>> The problem is that the grouping construct is rarely used, so many >>> YANG definitions are not available for reuse that otherwise might be. >> Grouping does not solve everything, you cannot augment a grouping so any >> augmentation would have to be repeated for each use of the grouping. >> I recommend reading the intro of RFC8528 YANG Schema Mount for a detailed >> description of these reuse issues. > <AC> Correct, you cannot augment a grouping. However, you can define > a second grouping and then use both groupings. I do think that with > properly designed modules that make extensive use of groupings 99+% of > reuse scenarios would be covered. The problem of course that in > general groupings are used only sparingly and in cases where the need > for reuse becomes obvious already within the same model. Once models > have been defined this way, they cannot be altered after the fact. > That is one of the shortcomings in YANG today, that it makes it easy > to define models that are not as reusable as they should. </AC> >>> As a thought, it might be useful to introduce a construct that will >>> allow to define a _grouping_ after-the-fact, for later reuse. I.e., >>> allow groupings to be defined in a way that the new grouping embeds >>> an existing definition, then simply make use of that grouping. That >>> would seem perhaps cleanest, able to address many of the use cases >>> and have the additional advantage that the semantics here will be very >>> clear since part of the exising YANG framework. >> There is still the augment issue from above, we have it in >> draft-ietf-opsawg-collected-data-manifest when reusing ietf-yang-push which >> augments ietf-subscribed-notifications. All these augments have to be >> rewritten with paths corresponding to the new location of the uses. > <AC> I don't think that would be an issue, actually. Just declare modular, > fine grained groupings and use those. Of course, this is somewhat a > speculative discussion as YANG is what it is and does not support this today. > This discussion probably belongs in YANG next. > Perhaps I'll put together some slides at some point to illustrate what > I mean. </AC> >> I think the semantics for Schema Mount as defined in RFC8525 is the key to >> reuse the full semantics of YANG (i.e. not only groupings but also >> augmentations, rpcs ...) without having to modify existing modules. >> What we propose in full embed is just to enable a simplified version of >> schema mount, for design time. >> >> Best, >> Jean > <AC> Cheers, Alex </AC> >>> --- Alex >>> >>> >>> >>> _______________________________________________ >>> 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] _______________________________________________ > 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]
