On 10/03/2016 11:19, Martin Bjorklund wrote:
Ladislav Lhotka <[email protected]> wrote:
On 10 Mar 2016, at 11:16, Juergen Schoenwaelder
<[email protected]> wrote:
On Thu, Mar 10, 2016 at 10:49:33AM +0100, Ladislav Lhotka wrote:
On 10 Mar 2016, at 10:18, Juergen Schoenwaelder
<[email protected]> 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.
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.
I actually also agree with Juergen and Martin.
I see that the one of the advantages of using extensions is that it
allows them to evolve independently and more quickly than the base
draft. And I would think that it is easier to deprecate an old
extension if it was superseded by a better approach.
Rob
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
