Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-06-08

Andy Bierman <andy@yumaworks.com> Mon, 14 June 2021 17:55 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 9AA493A2C78 for <netmod@ietfa.amsl.com>; Mon, 14 Jun 2021 10:55:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level:
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] 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 JPcUj_e8ZI5d for <netmod@ietfa.amsl.com>; Mon, 14 Jun 2021 10:55:34 -0700 (PDT)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 51CA93A2C74 for <netmod@ietf.org>; Mon, 14 Jun 2021 10:55:34 -0700 (PDT)
Received: by mail-lf1-x12e.google.com with SMTP id a1so22417405lfr.12 for <netmod@ietf.org>; Mon, 14 Jun 2021 10:55:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yvYJ1zLjtTUR3FPbr/lmxYCiRoY/X/QqUQgbH0TVM8c=; b=j+wuVZQsSud/MYyl1zua0AudbFcB3PhpXmAf8Pk+8S2tTA7Pn+GcdAKpAe2ImUOB5H 53owzqsznJKW2sApajZ0Bu0hH639L/duxc+UnCXts+BuQi4hebXofrsSBkuySrsa4dcz dV0OiDaOI8RcCKQVvps06wXizU4Wq6HRLhYTCDkjpMQjvWRkcGjMnMFarwvl2ZPthtTb PEN7DbsubiEGskBitqA+zLkIb1YqzntVcWpJuG83VTOdAzaljXU7ZthZSp6a4FCZc/6X VXvvNTEW1ofWl+cLOSe4titwDN52TtWWDdKvmp5zCRdjvs27w/umYFE1iuJgIugDtNZp vhiA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yvYJ1zLjtTUR3FPbr/lmxYCiRoY/X/QqUQgbH0TVM8c=; b=H4VSA9cS6nW/UBEgRAD7qh0zyIfAZOh8jeCHz/G7vi35CZU0KC7WLocy3RgdHqWHmd 8D0QUfFYNkqkVmVPmYfvNrikiERHnk72B4WyYYM+QmDkvxPuO7T5r1kpXCSkWlH1Z4pB OzU79+B6grM/q63FWRU8puGmkPZMaqPKWHIK7D9JklABc0xh4tKOFIzC2r8k2siK2rKb 98NwC+2ZcQNV/Qfsup1Kz/SseGKRmb/rYQ9QY1zutP0bdZRcfdKP7r8a4+T5w7801R5C gx5LbpDD+zSxhKKRVA6A0De47i58HJA2xOQzj77lOC+vUMghiQe8FX3DPcQ3ByaKsX82 Fhdw==
X-Gm-Message-State: AOAM5308X8O4xBh0dTCi+u4NVwjkMbEEgayu4WuMY5enX/QFJD1gUpeO bFdjFV7j6L3oOM6BXiqsv2iU9WnRD5K/FV4y/1KfzA==
X-Google-Smtp-Source: ABdhPJxhlANpUNTfaI6r3Jq8WOvevHtnUemelOLh/ukYNbozYbwOKTdt8+B1BG+AXtkwW/MrLO2/cOQPIdzX40KdBGE=
X-Received: by 2002:a05:6512:3604:: with SMTP id f4mr12828735lfs.553.1623693330855; Mon, 14 Jun 2021 10:55:30 -0700 (PDT)
MIME-Version: 1.0
References: <CABCOCHT86mf2M9Mw4dhOHU2cd4ffkZ4hLd3CfPorG5mk1cUpRQ@mail.gmail.com> <0100017a0a164118-b7e3c4cc-177c-4211-b19a-9dcb77006dcd-000000@email.amazonses.com> <CABCOCHRF=jXR4qJGU5jkv8eVMn3bJfKrWEbE5GU3KfJsuzQMGw@mail.gmail.com> <0100017a0b63209f-789f601b-574a-44c7-b870-ec9bbe870c75-000000@email.amazonses.com> <CABCOCHTrZonbrspLUZ1BinLW8M+QEuuAZELReebAxjSkE7iOTw@mail.gmail.com> <0100017a0b866f67-8f4f2e4e-6c67-41cc-9c7c-b49057826adb-000000@email.amazonses.com> <DM6PR08MB508476F2B01EA22C596B7CBD9B319@DM6PR08MB5084.namprd08.prod.outlook.com>
In-Reply-To: <DM6PR08MB508476F2B01EA22C596B7CBD9B319@DM6PR08MB5084.namprd08.prod.outlook.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Mon, 14 Jun 2021 10:55:19 -0700
Message-ID: <CABCOCHTUixOZWTfw6zF3MjHWk2jk8vXTSNjLKB=gCsiHT0X4fA@mail.gmail.com>
To: "Sterne, Jason (Nokia - CA/Ottawa)" <jason.sterne@nokia.com>
Cc: Kent Watsen <kent+ietf@watsen.net>, "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000035cbea05c4bd9059"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/yIZfIH29OUXJIoVo8TZQSFoBrl8>
Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-06-08
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
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, 14 Jun 2021 17:55:40 -0000

On Mon, Jun 14, 2021 at 10:40 AM Sterne, Jason (Nokia - CA/Ottawa) <
jason.sterne@nokia.com> wrote:

> Hi guys,
>
> I can understand that concern; and in particular for something like the
> new import by "revision-or-derived". Ignoring that extension can mean tools
> may not build the right schema (although is that any worse than today
> without using import by revision ?).
>
> Despite that issue, I'd still advocate for revision-or-derived to be taken
> to standard now. It is part of a few things that cause problems today that
> really need to be addressed in the short term.
>
> But for things like the rev:non-backwards-compatible tag, and using YANG
> semver, do those actually cause any new problems (vs what they help solve)
> ? It doesn't cause tools to build the wrong thing, or servers to implement
> the wrong thing.  It only helps supply information about what is already
> happening today (particularly in vendor modules, but also in standard
> modules) that isn't being described at all (NBC changes that really do
> impact the client, but the module name is kept the same). The WG had a fair
> bit of discussion 2-3 years ago that this versioning work was needed and
> should be adopted and progressed. That is still the case IMO.
>
>
The all-or-none approach to the versioning work is producing more "none"
than "all". ;-)

YANG was designed to be used in a linear and singular release train.
This is clearly not the way the real world can use YANG.
Ignoring this pain point is making the problem worse over time.

There are many corner-cases that the DT is spending a lot of time on that
do not cause the deployment problems that a revision label could solve.

My original point: Fix this problem with the best engineering solution
possible
even if that means a new YANG language version.  Import-by-semver should
not be super-complicated and it should not be optional for a compiler to
use.

Import-by-exact-revision is flawed and not worth preserving.


Jason
>

Andy


>
> > -----Original Message-----
> > From: Kent Watsen <kent+ietf@watsen.net>
> > Sent: Monday, June 14, 2021 1:17 PM
> > To: Andy Bierman <andy@yumaworks.com>
> > Cc: Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com>;
> > netmod@ietf.org
> > Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-06-08
> >
> >
> > > I meant the current work is using extensions instead of new language
> > statements.
> > > Not that the yang-version will never be changed in the future.
> >
> > Ah, okay.
> >
> >
> > > It is not a matter of "when" if new functionality is added via
> extensions.
> > > In theory the WG could add new functionality to YANG 1.1 this way for
> > years.
> > > In practice it might be difficult to achieve widespread
> interoperability if
> > nobody
> > > agrees what "YANG next"  actually contains. Also, YANG 1.1 clearly
> says a
> > tool MAY
> > > skip over and ignore ANY external statement, so it is problematic to
> use
> > extension-stmt
> > > as if it was defining real statements. It is better to have a tool
> clearly fail
> > > with an "unsupported YANG version" error than it is to silently ignore
> > external statements.
> >
> > Agreed.
> >
> >
> > K.
> >
>
>