Re: [netmod] yang-data-ext issues

Martin Bjorklund <> Tue, 24 April 2018 14:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C9DE81289B0 for <>; Tue, 24 Apr 2018 07:43:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ci2klMDB6GOW for <>; Tue, 24 Apr 2018 07:43:25 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2B67F127333 for <>; Tue, 24 Apr 2018 07:43:25 -0700 (PDT)
Received: from localhost (unknown []) by (Postfix) with ESMTPSA id CE7991AE0471; Tue, 24 Apr 2018 16:43:23 +0200 (CEST)
Date: Tue, 24 Apr 2018 16:43:23 +0200 (CEST)
Message-Id: <>
From: Martin Bjorklund <>
In-Reply-To: <>
References: <20180423165104.zi7g75tifhekmezh@elstar.local> <> <>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [netmod] yang-data-ext issues
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Apr 2018 14:43:27 -0000

Ladislav Lhotka <> wrote:
> Robert Varga <> writes:
> > 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...
> But what prevents you from forking YANG, indicating it in the
> "yang-version" string and implementing your new statements as built-ins?
> It is tempting to think about extensions as a magic for adding modular
> extensions but it breaks down as soon as such extensions interfere with
> the YANG core (with and each other, or both).

Sure, nothing new here.  This is how the extension mechanism is
designed.  Do you feel that there are so many standard extensions that
interfere with each other that we actually have a problem?  I strongly
agree that we need to be careful with standard extensions, and I
strongly encourage vendors to not define extensions that interfere
with YANG core (been there, done that, bad idea).

In the case of yang-data, the fact is that it *is* used in standard
models (in ways not originally anticipated), and vendors have similar
proprietary extensions (we have a tailf:structure, and I think others
have reported similar things).