From: netmod <[email protected]> on behalf of Sterne, Jason (Nokia - CA/Ottawa) <[email protected]> Sent: 07 August 2020 22:40
I agree submodules can cause confusion, but I also agree with Mahesh that they can be useful to partition things for people using the modules. Especially for huge models (e.g. router vendor models). You can jump right to a subsection of the data (a bit like a document with chapters rather than one huge chapter). It can also be useful for consumers of the models for versioning (when you want to avoid multiple namespaces). If a model is made up of 30 sub-modules, it might be useful to know that the "bgp" part changed while the other parts of the model didn't. <tp> Jason, Jan commented earlier that versioning happens at the module/namespace level in which case it would seem to me that all submodules will by definition have the same version so you cannot tell which submodules have changed,, I think too that there is a fallacy in the belief that dividing up something large makes it easier to use, understand etc. Divide up code by procedure, subroutine etc and if you can provide a parameter or two input, and one or two results output, and all the complexity of data structures, validation, algorithms etc and hidden out of sight, then you have simplified. But DDL is not like that. With a grouping or submodule, you need to know the internals, of what objects there are, how they are structured, what semantics they have, pretty much everything inside; it is just harder to find, to reference, to access because it has been wrapped up in something that gets in the way and tucked out of sight in some part of the I-D, Rather simplification comes from having the right structure in the model, which some WG are good at, Tom Petch Jason From: netmod <[email protected]> On Behalf Of Mahesh Jethanandani Sent: Wednesday, August 5, 2020 6:43 PM To: [email protected] Subject: Re: [netmod] submodules the hidden benefits A contrarian view: I find the use of sub-modules helpful when I want to use separate files to maintain part of the module that is logically separate, while maintaining/restricting the use of them to a single namespace. The fact that tools have a problem with trying to compile a sub-module can be addressed in the tools themselves. On Aug 5, 2020, at 2:44 PM, Reshad Rahman (rrahman) <[email protected]<mailto:[email protected]>> wrote: Indeed https://github.com/netmod-wg/yang-next/issues/26 On 2020-08-05, 5:22 PM, "netmod on behalf of Vladimir Vassilev" <[email protected] on behalf of [email protected]<mailto:[email protected]%20on%20behalf%20of%[email protected]>> wrote: On 05/08/2020 18.48, Juergen Schoenwaelder wrote: I personally meanwhile believe that sub-modules add complexity with little extra value but this view surely is not shared by others. +1. IMO removing sub-modules from YANG 2.0 should be on the list of proposed changes. /Vladimir _______________________________________________ netmod mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
