On Thu, Mar 10, 2016 at 4:18 AM, Ladislav Lhotka <lho...@nic.cz> wrote:
> > > 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. > I think standard extensions can be in standard YANG modules. My problem with extensions is that they become mandatory-to-implement if the module is advertised. IMO, YANG 1.1 MUST require that if-feature-stmt can appear within an external statement. There is currently no way to create an optional extension. We have also received customer requests to allow the if-feature-stmt inside the deviation-stmt, which would be a really useful addition to YANG 1.1. > > Lada > > > > > Rob > Andy > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
