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

Robert Wilton <rwilton@cisco.com> Tue, 24 April 2018 08:30 UTC

Return-Path: <rwilton@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 3CC611270AC for <netmod@ietfa.amsl.com>; Tue, 24 Apr 2018 01:30:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id rK1bG20134Vu for <netmod@ietfa.amsl.com>; Tue, 24 Apr 2018 01:30:22 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF46B126DEE for <netmod@ietf.org>; Tue, 24 Apr 2018 01:30:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11491; q=dns/txt; s=iport; t=1524558622; x=1525768222; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=J5eCz4iY0PlIzPO3brKqro7ZpvcRxG5Ch6pimwosHMU=; b=bqZI2IsvtkiC8JM84zoBkOJl4x7GU1FY1pQHo4nksKF9PgMzyTNJ4H/R smsmUAk6ZnjgGW89OaGXJ4021ztvfjxZaT6Y7bYN9iZr5nnRzrimfR0J5 6kVViKxpznqPt+iStTyyzXULjvw1rfFdw+MTd+4t3rViA9If5uRXQwXkI I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CPAQAB6t5a/xbLJq1ZAxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGDFASBDBdjKINqiGCNZSmBD44UhG6BeAsYAQqDEXFGAoM?= =?us-ascii?q?RNhYBAgEBAQEBAQJsHAyFIwEBAQMBASFLGQIJEggnAwICGwwfEQYBDAYCAQG?= =?us-ascii?q?FCw+KY5tBghwfg1oBXoNygjQFBYlbP4EygWlRgz8BAYIBJoI5glQCh1OJGIc?= =?us-ascii?q?MCIE1jQUGAodIhQSLDYUhgSUjCCmBUjMaCBsVO4JDgXAwF3oBCYJ0hGGFCAE?= =?us-ascii?q?2PjCQQgEB?=
X-IronPort-AV: E=Sophos;i="5.49,321,1520899200"; d="scan'208,217";a="3373615"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Apr 2018 08:30:20 +0000
Received: from [] (dhcp-ensft1-uk-vla370-10-63-23-54.cisco.com []) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w3O8UHsF012939; Tue, 24 Apr 2018 08:30:19 GMT
To: Andy Bierman <andy@yumaworks.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Robert Varga <nite@hq.sk>, Ladislav Lhotka <lhotka@nic.cz>, NetMod WG <netmod@ietf.org>
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>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <30689299-e689-0942-8841-8533e1847c4a@cisco.com>
Date: Tue, 24 Apr 2018 09:30:17 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <CABCOCHR52jhJT4Sp00+Y23GwqanLGTZBTkc=STTLeDi5OCprvw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------B7AD1125BABAB1BD9FB69DCB"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/gsmijkF7IpJCArX3Jz2WMY1fqIo>
Subject: [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 08:30:24 -0000

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


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