Re: [netmod] yang-data-ext issues

Andy Bierman <andy@yumaworks.com> Mon, 23 April 2018 20:58 UTC

Return-Path: <andy@yumaworks.com>
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 461E612D95A for <netmod@ietfa.amsl.com>; Mon, 23 Apr 2018 13:58:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
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 qAafNQliBs_7 for <netmod@ietfa.amsl.com>; Mon, 23 Apr 2018 13:58:53 -0700 (PDT)
Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56FCF12D957 for <netmod@ietf.org>; Mon, 23 Apr 2018 13:58:53 -0700 (PDT)
Received: by mail-lf0-x22a.google.com with SMTP id j68-v6so16994288lfg.13 for <netmod@ietf.org>; Mon, 23 Apr 2018 13:58:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=OTTJhRyRbYRg3iVDidQovehUQ3ZR1QhBdDnYQAZ7kiM=; b=1C0U9s1LIYoKCBer6544G+XYcVf9U8EEFjFSZnqwpmXdYTrY1tK+n8Z14iZcBiFktz wuPxwupl2ONDBxGU7zHlk+n+1fxHp14rsVyeQI+LgPCV0A/yiTrVGh69FAPfN5GeFA15 u9bQY1wxj7tB17H08NNl/1+vVXepiaAox7OFI33gG3apn9zdhFDVDFDfb/a67Ua3aPpx AcB4/PvdvXOGfLYxBoI2EaD23OPoo6LdtXOqOQv8nZLfX90AuD7CihL/6Vb/a0EGPArt nihLR4Iv7n/xbunuX7mBRY4tnEpj+Bo4GlgpePwBz0yn0H1ANfSmeyNu9P1xfXvFt23U KhzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=OTTJhRyRbYRg3iVDidQovehUQ3ZR1QhBdDnYQAZ7kiM=; b=ILA41uy8tPQ5899kCiPYmhwE4JmiMX2qQHZI2yUDQuDiTIywSKQBHucwEIzmzpYS1e HMu8F/n1sScFlOhm/PzZCm+jc+2CUPs74ofLvI6HWpiCIRrSnYbHiWmjUOV0y481J+GG a3eDSkSR08Az0CUNj7LfkGcjtMKTWp74cXAiiyFcatYxnz1p9tAYOWIuUJvOV75DLCOO lP9Dq4tCzbVSutbUmapT/CYB9WMxECmRNWsM33esrTiTcbJlQJLAEJD5wUVW+pjIM18X XZvv73a86coFboHiad7C3UOpdrWfPykt6KQTWjyQcI/5ZaHtiSjgAeUhwucHyzrCXl6C 7L0g==
X-Gm-Message-State: ALQs6tAmQD5EurvVJfSKWOhUsWgaW4yMO2IiGy8lcR53OcIW2BgQxFAO 3Qt+mLyCL6SsO0D+pLkfa4xUqRRByarCNYG/2ddeOA==
X-Google-Smtp-Source: AB8JxZp0DnN+iR59v67x0Pwfy/B0NAk8jnpuCqmhetZENJdOwM9fxGhHj9EJ45Od2D5FiyXD9oxicUYFjGeLcjjLPw0=
X-Received: by 2002:a19:a087:: with SMTP id j129-v6mr9595562lfe.101.1524517131364; Mon, 23 Apr 2018 13:58:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:d8c6:0:0:0:0:0 with HTTP; Mon, 23 Apr 2018 13:58:50 -0700 (PDT)
In-Reply-To: <20180423173636.fx63befibcc4vhmh@elstar.local>
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>
From: Andy Bierman <andy@yumaworks.com>
Date: Mon, 23 Apr 2018 13:58:50 -0700
Message-ID: <CABCOCHR52jhJT4Sp00+Y23GwqanLGTZBTkc=STTLeDi5OCprvw@mail.gmail.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Robert Varga <nite@hq.sk>, Ladislav Lhotka <lhotka@nic.cz>, NetMod WG <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000011c1ff056a8a4e07"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/WPySIyo5JcD3iKB7MFh019y00E8>
Subject: Re: [netmod] 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: Mon, 23 Apr 2018 20:58:56 -0000

On Mon, Apr 23, 2018 at 10:36 AM, Juergen Schoenwaelder <
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/>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>