> 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? Lada > > > /martin > >>> some gain more traction than others. >> >> Protocols are very different because they usually have means for >> signalling/negotiating extensions. A schema, ideally, is a static >> specification against which instance documents can be validated. With >> some YANG extensions that are looming around this may not be the case >> anymore. >> >> Lada >> >>> >>> /js >>> >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>> Fax: +49 421 200 3103 <http://www.jacobs-university.de/> >> >> -- >> 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
