Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> writes: > On Thu, Jul 28, 2016 at 04:14:42PM +0200, Ladislav Lhotka wrote: >> >> We could define it using built-in statements, and bump YANG version number. >> I don't get why this is worse that introducing "standard extensions", except >> at Layer 8 (Political) - we can claim that YANG is stable even though it >> isn't. >> > > - Running a document of the size and complexity of the YANG > specification through the IETF and publication process is expensive.
This is just a procedural issue. Updates to some protocols (e.g. OSPFv3) were specified as a diff. > > - It is not clear at this point in time that YANG mounts are required > to be supported everywhere. Well, we already have things in base YANG that arguably aren't required to be supported everywhere, for example notifications or actions. But either way - if an implementation doesn't support a fundamental data modelling function that's used in a module, then this implementation cannot use this module, no matter whether the function is implemented as built-in or extension. > > - It is up to this WG to keep YANG 1.1 stable. Claiming YANG isn't > stable as a justification to make it not stable is a somewhat > circular logic. I don't see anything circular here. If any implementor can randomly choose from a host of extensions, there will be no standard YANG at all. We all remember browser wars, right? They were caused by extensions to web standards. I am concerned that this can easily happen here, too. > > I strongly believe that it is feature to work with extensions wherever > possible. Gain experience with language extensions first and if they > are widely deployed and used, consider to move them into the core at > some point in time. I believe it is desirable to keep the complexity > of the core YANG language somewhat under control. For this approach to work, we would need to change the character of extensions, in particular: - an implementation should be able to signal which extensions are supported, - extensions that change the data model need to be labelled as mandatory to support. Lada > > You likely won't agree with any of this and this is fine. But I also > do not agree with your statement that working with extensions is just > a layer 8 (political) issue. > > /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
