[Renaming the thread because this doesn't seem to be directly applicable
to the yang-data extension.]
I think that extensions are great in the sense that they allow YANG to
evolve more quickly without requiring a fork lift version upgrade that
may take a long time to produce.
I agree that all standard defined extensions should cleanly
inter-operate with each other.
I also think that it is useful to periodically define new versions of
YANG that fold back in all the extensions that have been successfully
and are widely deployed. And also to deprecate/obsolete stuff that
hasn't worked well.
For me, the interesting question is about namespaces when those
extensions are incorporated back into a new version of YANG:
- Does it just keep the extension prefix that the extension module was
originally defined in?
- Or does the extension get folded into core of the YANG language and no
extension prefix is used any more?
- Or does the extension get supported both with/without the extension
namespace prefix?
Thanks,
Rob
On 23/04/2018 21:58, Andy Bierman wrote:
On Mon, Apr 23, 2018 at 10:36 AM, Juergen Schoenwaelder
<j.schoenwael...@jacobs-university.de
<mailto:j.schoenwael...@jacobs-university.de>> wrote:
On Mon, Apr 23, 2018 at 07:18:38PM +0200, Robert Varga wrote:
> 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...
Once we standardize extensions (and this is what I am talking about),
we better make sure that the whole stays consistent. Otherwise, we
will end up with patchwork where all the patches may work in isolation
but sooner or later they will fall apart when you look at all the
possible combinations.
I am in favour of managing a clean definition of the core of the YANG
language instead of creating patchwork. It is great if people create
and prototype new extensions but once such extensions are considered
to be ready for general use, we should roll them into the core (and
remove any cruft from the core at the same time).
I agree with your concerns.
If the intent is that a YANG extension is optional, then its semantics
have
to be well-scoped so that tools really can skip over the extension
without any problems.
If we create standard extensions that standard YANG 1.1 modules use,
then this can
become an unofficial add-on to YANG 1.1. (e.g. annotation could
already be considered as such)
/js
Andy
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://www.jacobs-university.de/
<https://www.jacobs-university.de/>>
_______________________________________________
netmod mailing list
netmod@ietf.org <mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
