> On 10 Mar 2016, at 17:57, Andy Bierman <a...@yumaworks.com> wrote: > > > > 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.
I don't agree - this doesn't happen automatically. There must be some extra mechanism for an extension to become mandatory to implement, e.g. a special protocol, or a negotiated capability in an existing protocol. For example, if my RESTCONF implementation uses future modules that happen to contain the "mount-point" extension, I don't want structural-mount to become mandatory to implement. > > 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. IMO it is way too late to consider such new features for inclusion in YANG 1.1. Lada > > > > 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
