Re: [netmod] Extensions vs new YANG versions [was Re: yang-data-ext issues]

Ladislav Lhotka <lhotka@nic.cz> Tue, 24 April 2018 14:07 UTC

Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D55C12D7F9 for <netmod@ietfa.amsl.com>; Tue, 24 Apr 2018 07:07:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxJ-LWE7luFL for <netmod@ietfa.amsl.com>; Tue, 24 Apr 2018 07:07:40 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5972512EA93 for <netmod@ietf.org>; Tue, 24 Apr 2018 07:07:33 -0700 (PDT)
Received: by trail.lhotka.name (Postfix, from userid 109) id 433D31820159; Tue, 24 Apr 2018 16:13:14 +0200 (CEST)
Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id 2FD6A1820055; Tue, 24 Apr 2018 16:13:10 +0200 (CEST)
From: Ladislav Lhotka <lhotka@nic.cz>
To: Robert Wilton <rwilton@cisco.com>, Andy Bierman <andy@yumaworks.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Robert Varga <nite@hq.sk>, NetMod WG <netmod@ietf.org>
In-Reply-To: <30689299-e689-0942-8841-8533e1847c4a@cisco.com>
References: <20180416.145617.1262098657698751846.mbj@tail-f.com> <87h8oal7iu.fsf@nic.cz> <a7d3702d-1406-7bd2-caf6-7c07812c86aa@hq.sk> <6d5cd4e4257822e4a5c478dc934c5433428aff38.camel@nic.cz> <20180423165104.zi7g75tifhekmezh@elstar.local> <ecb9cc29-67c5-df8f-8a37-140733e0c1e7@hq.sk> <20180423173636.fx63befibcc4vhmh@elstar.local> <CABCOCHR52jhJT4Sp00+Y23GwqanLGTZBTkc=STTLeDi5OCprvw@mail.gmail.com> <30689299-e689-0942-8841-8533e1847c4a@cisco.com>
Mail-Followup-To: Robert Wilton <rwilton@cisco.com>, Andy Bierman <andy@yumaworks.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Robert Varga <nite@hq.sk>, NetMod WG <netmod@ietf.org>
Date: Tue, 24 Apr 2018 16:07:30 +0200
Message-ID: <8736zksnod.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/tao3BCwc_aG4USFKPsQm34-grbY>
Subject: Re: [netmod] Extensions vs new YANG versions [was Re: yang-data-ext issues]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Apr 2018 14:07:44 -0000

Robert Wilton <rwilton@cisco.com>; writes:

> [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.

This is of course a double-edged sword. In my view, extensions must not
influence the resulting data model, and I thought the last paragraph in
sec. 6.3.1 of RFC 6020 had been intended to mean exactly this.

I would prefer to indicate experimental versions of YANG in the version
string (e.g. as a topical branch), and use YANG extensions only for
stuff that's outside the realm of data modelling. For example, the
extension in NACM is perfectly OK because it is a hint for protocol
operation and doesn't affect the schema in any way.

>
> 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.

Without a metamodel, it is difficult to avoid YANG becoming a kitchen
sink.

And what about extensions that won't make it into the new official
version?  For example, imagine that "openconfig:pattern" won't be
accepted - would it really matter? The forked versions will continue to
exist but they could still claim adherence to the IETF standard (which
is what marketing departments love).

Lada

>
> 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.schoenwaelder@jacobs-university.de 
>> <mailto:j.schoenwaelder@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
>

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67