Ladislav Lhotka <lho...@nic.cz> wrote: > Robert Varga <n...@hq.sk> writes: > > > On 23/04/18 18:51, Juergen Schoenwaelder wrote: > >> Some people will say that the cost of a new language version is high. > >> (Well, when we did 1.1, some people said it will never be deployed.) > >> Anyway, not bumping the YANG version number but having instead several > >> (optional) language extensions is just hiding the version number > >> change under the carpet. > > > > Not quite, as extensions allow for modular/incremental evolution, as an > > implementer I do not have to go through a long development cycle where I > > need to rewire language aspects just to get the features my users need > > for their models... > > But what prevents you from forking YANG, indicating it in the > "yang-version" string and implementing your new statements as built-ins? > > It is tempting to think about extensions as a magic for adding modular > extensions but it breaks down as soon as such extensions interfere with > the YANG core (with and each other, or both).
Sure, nothing new here. This is how the extension mechanism is designed. Do you feel that there are so many standard extensions that interfere with each other that we actually have a problem? I strongly agree that we need to be careful with standard extensions, and I strongly encourage vendors to not define extensions that interfere with YANG core (been there, done that, bad idea). In the case of yang-data, the fact is that it *is* used in standard models (in ways not originally anticipated), and vendors have similar proprietary extensions (we have a tailf:structure, and I think others have reported similar things). /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
