Many thanks to all the responses so far; most helpful and much appreciated. As a point of information, the I-D that triggered this, draft-ietf-idr-bgp-model, is out for, or about to be, YANG Doctor review so one of you can express a more formal opinon thereon. (Perhaps it will be the YANG Doctor who gladdened my heart when they said that this grouping is only used once so there is no point in making this a grouping:-).
Again, more for the benefit of the chosen YANG Doctor, the prefix in this I-D are all over the place IMHO. Setting aside the use of two letter prefix such as bp: ,bt:. br:, there are 100 or so places where the prefix will have be to edited - look for example at the use of rpol for routing policy instead of rt-pol. And I was wrong to say that I had not seen submodules before - I had forgotten about RFC8349. Tom Petch. ________________________________________ From: netmod <[email protected]> on behalf of Jan Lindblad <[email protected]> Sent: 06 August 2020 10:00 I have to agree with the long list of "Costs" of submodules listed in this thread, and can attest to the brevity of the "Benefits" side. The globally accumulated amount of gray hairs produced by the YANG 1.0 submodule rules is best measured in cubic meters. The YANG 1.1 rules are much more in line with industry expectation in my experience, but the fact that the rules differ greatly between the two YANG versions with unchanged syntax and that many tools still do not properly support the YANG 1.1 submodule inclusion rules to this date (despite otherwise boasting YANG 1.1 support for long) is additional salt in a sore world. One central point that has been missed in the discussion on the merits of modules vs. submodules is the implications this choice has on module versioning. Since versioning happens on the module/namespace level, there is a major difference between releasing 10 modules which are versioned independently, or one module with 10 submodules, which would have a single module version. If this point goes on the "Costs" or "Benefits" side in the book keeping, I'll leave open to interpretation. /jan On 6 Aug 2020, at 00:43, Mahesh Jethanandani <[email protected]<mailto:[email protected]>> wrote: 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]<mailto:[email protected]> on behalf of [email protected]<mailto:[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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
