Ladislav Lhotka <lho...@nic.cz> wrote: > > > On 10 Mar 2016, at 12:19, Martin Bjorklund <m...@tail-f.com> 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. > > If it is a built-in statement, implementations have no excuse to > ignore it. Even with metadata, an implementation that uses DSDL > validation but ignores some annotation definitions will find instance > documents containing them invalid. > > > > >>>> 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. > > OK, so what about complex-type, that Balazs has just asked about? Do > you encourage authors of standard track modules to use it if they feel > they need it?
No - but not because it is an extension, but because it is Experimental. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
