> On 10 Mar 2016, at 12:34, Robert Wilton <rwil...@cisco.com> wrote: > > > > On 10/03/2016 11:19, Martin Bjorklund wrote: >> Ladislav Lhotka <lho...@nic.cz> wrote: >>>> On 10 Mar 2016, at 11:16, Juergen Schoenwaelder >>>> <j.schoenwael...@jacobs-university.de> wrote: >>>> >>>> On Thu, Mar 10, 2016 at 10:49:33AM +0100, Ladislav Lhotka wrote: >>>>>> On 10 Mar 2016, at 10:18, Juergen Schoenwaelder >>>>>> <j.schoenwael...@jacobs-university.de> wrote: >>>>>> >>>>>> On Thu, Mar 10, 2016 at 09:44:04AM +0100, Ladislav Lhotka wrote: >>>>>>> Hi, >>>>>>> >>>>>>> this revision is based on the IETF LC. In particular, Robert Sparks >>>>>>> suggested in his Gen-ART LC review to include an explanation as to why >>>>>>> we chose a YANG extension rather than a built-in statement. I added a >>>>>>> paragraph at the end of Introduction, please have a look, I hope it's >>>>>>> a fair account that shouldn't cause any controversy. >>>>>>> >>>>>> I think it is a feature to use extensions for new statements that do >>>>>> not have to be in the core. Modularity is a good thing, the YANG >>>>>> 1.1. specification is already 200 papges. When adding new statements, >>>>>> we should rather ask the question 'can this not also be done using >>>>>> extensions'? >>>>> I am not convinced about that. If we have a host of "standard" >>>>> extensions (annotation, complex-type and co., mount-point, >>>>> mount-module, you name them), every module author then may choose a >>>>> subset of extensions for use in the module >> Sure. The author will use the subset of core statement + extensions >> that is needed. If the module doesn't need meta-data, it won't be >> used regardless of if it's a core statement or an extension. >> >>>>> and then the value of YANG >>>>> as a standard data modelling language would be gone. >>>>> >>>> There will be a natural filter; things that are widely used will be >>>> widely supported, things that are not widely supported will not be >>>> widely used. We have the same with protocols and protocol extensions, >>> Asymptotically, yes. But the modules developed in the meantime will be >>> a mess. >> I disagree. I agree w/ Juergen that defining extensions when it is >> possible is a feature. > I actually also agree with Juergen and Martin. > > I see that the one of the advantages of using extensions is that it allows > them to evolve independently and more quickly than the base draft. And I > would think that it is easier to deprecate an old extension if it was > superseded by a better approach.
This would all be fine as long as modules developed with such extensions stay experimental, too. Lada > > Rob -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
