On 28/07/2016 15:51, Juergen Schoenwaelder wrote:
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.
- It is not clear at this point in time that YANG mounts are required
to be supported everywhere.
- 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 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.
I agree with this point (and also the similar one that Balazs made).
One issue I see is that extensions are effectively required to be
optional, allowing tooling to ignore them if they wish. This seems to
hamper their usefulness in some scenarios.
For the example given here, I feel that something stronger would be
useful, i.e. an extension that must be implemented by the tooling for
the particular YANG module to make sense.
Perhaps when a module includes an extension it could indicate whether
support for that extension is regarded as required for the module to be
useful, or conversely if the module is still sane even if support for
the extension isn't implemented.
Thanks,
Rob
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
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
