Re: [netmod] All IETF YANG modules MUST include revision-label statements

Andy Bierman <> Tue, 31 March 2020 16:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 885463A23CC for <>; Tue, 31 Mar 2020 09:19:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.013
X-Spam-Status: No, score=0.013 tagged_above=-999 required=5 tests=[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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id b8gp1CV0ol1f for <>; Tue, 31 Mar 2020 09:19:45 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::b43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CD41A3A2355 for <>; Tue, 31 Mar 2020 09:19:44 -0700 (PDT)
Received: by with SMTP id c13so8219209ybp.9 for <>; Tue, 31 Mar 2020 09:19:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gawrFphQOkA4lm06brGLj3XMMi+Ec//IeiwPHLnll3c=; b=w3Xbq/A6J3x1K3KOQsrX23smtatPzajFmZ1sckjQ7hj2GHGQS7DPESLWtaJYUtei9e fqEkBCYk7t1nAzmXHVqpbX4+7t7gi0uejafftrc/DEC1rLgqcnTQL5SkJab5LnLGRXTA L5pKv7l8idX2rAWyRvPQ+VjdLmah9+4dJJIrvJF3npKMqzgmkwtoPel4PlKWJUsvjXGN p7/CjyKX3R2uqfdQeXa7xeMyfb2jz2vWH5y4gL9MNiJS3KYD4dd5zZ9ppK5PW/xAJGi1 zAWvKhsFB1hUCS4zOnkY8r0/X5uy+vLIbguau7gpl1pi4NFr0MQdbzfCzT2nFFGqoL0j K6uw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gawrFphQOkA4lm06brGLj3XMMi+Ec//IeiwPHLnll3c=; b=CuBuOvAn0VkOfqfVChuQLecKFlRaVrIXSpI/dz8rLljKzbCiSy9Xy2/U0WIGpHzHtD 7JGAX6ncaF67uyUe4g/iU8ho3G9W+RNYtfL8rMI44oszISE6hsc//JtANhhcHzokjs3i 26qwVktOWqoKiPJO5uWxIeaQmTlqFrS5gPIM6h2DsMsSbHaKPPmP1OiW6XNFToDKCztL NKItZfeg/gC8JlDwYt9cxGEBMzQBCfGF805wXRYMXUH9Yw544dIY0xDe2iNEB99Xc/pV gx1HnQmTu96mvv4GI0kfliKw+BYDyCpUjUMCbSt7/NV6ZJdAda05lb5UAUkkg6Bqr8yD tViw==
X-Gm-Message-State: ANhLgQ1VQHsKCiP7fErYzqgMd5bTaaREH9XdH9BNbmLC9q8+OpXCAjve 8x7QBiA7A+6TumGLLIdmIckkyuDRGAYgm+FMdcV5CA==
X-Google-Smtp-Source: ADFU+vveD41TD3T0isYOfCwSZL8PkoHAPNxPwKIaSBbzsWzt3V5dTNxjYBSGWrghBwIq4M/cyOTP0STQRS/U7f6gfDo=
X-Received: by 2002:a5b:c4a:: with SMTP id d10mr10620656ybr.59.1585671583845; Tue, 31 Mar 2020 09:19:43 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
From: Andy Bierman <>
Date: Tue, 31 Mar 2020 09:19:32 -0700
Message-ID: <>
To: Kent Watsen <>
Cc: "Rob Wilton (rwilton)" <>, =?UTF-8?Q?Martin_Bj=C3=B6rklund?= <>, "" <>
Content-Type: multipart/alternative; boundary="0000000000007c642805a228ef9f"
Archived-At: <>
Subject: Re: [netmod] All IETF YANG modules MUST include revision-label statements
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 31 Mar 2020 16:19:48 -0000

On Tue, Mar 31, 2020 at 8:37 AM Kent Watsen <> wrote:

> [replying to Reshad as well]
> Hi Rob,
> My impression is that Semver 2.0.0 works fine if you can always force
> clients to move to the latest version of the API whenever any bugfixes are
> made to the API (whether they are BC or NBC).  This is a natural fit for
> open source projects, but not so great for long life paid support contracts.
> Agreed.
> The goal of YANG semver is not to facilitate release branching.  It is to
> allow vendors to fix YANG modules without forcing clients to update to the
> latest version of that YANG module (which may contain other unrelated NBC
> changes and have lots of dependencies on other modules).
> This is what Reshad was pointing to as well.  I’m very familiar with the
> issue, from my Juniper days, where there were all sorts of patch and (gasp)
> customer special releases, either of which could introduce any number of
> NBCs.
> The background, of course, is that [very important] customers have
> working/validated infrastructure running a specific release and simply
> cannot tolerate any change beyond the very specific one they need *NOW*
> I get it, truly,  but I feel that the ‘m’ / ‘M’ suffixes are both
> inconsistent with general understanding and insufficiently to express what
> is needed.


I also find the granularity of NBC info to be mostly worthless at the
module level.
There is no difference between a 1 leaf bugfix and a complete rewrite of
the module.
Let's say 1 leaf "type string" needs to be changed to add "length 1..max".
This reduces the value set for 1 leaf by 1 value.

This flags the entire module as NBC and you would bump the major revision
The entire premise that one can decide if it is safe to upgrade based on
the version string is flawed.

A possible fix might be to allow for <major>.<minor>.<patch>[-<anystring>],
> thereby enabling vendors to encode any format off a base release…and rely
> on inspection of the “revision” history indicate if/when NBC changes
> occurred.
> But then I question (again) the need for the simplified format at all, as
> opposed to just using revision dates.  For instance, if <anysting>
> represents a long history of NBCs, that they were based on some source
> M.m.p starts to lose relevance.
> Is the expectation that the vendor's module versions will use
> <major>.<minor>.<patch> values mimicking their release numbers?  For
> instance, would FooBar OS version 20.1.2 implement YANG module
> "foobar@20.1.2”?    I can see product mangers pushing for this, but then
> are companies (like Juniper) that use alternate release name-formatting
> strategies disadvantaged?  How is that fair?   To thwart this, would the WG
> be willing to assert that the history MUST start at 0.0.0 and MUST only
> monotonically increment values?
> Note that OpenConfig also hit this problem, but they proposed a different
> solution.  I.e. ship the base module with another module that contains
> deviations to fix any bugs in the base module.  Alas this completely
> decouples the real module history from any revision-date/version number
> contained in the module, since to really understand the version of the
> module you also need to know the set of associated patch modules containing
> any deviations to the base module.
> I’d need to see an illustration of this to be sure I understand, but my
> first impression is that it is yet another attempt to fit a square into a
> circle.

I don't have a solution proposal, but it would be great if a vendor could
issue a patch
to a standard module which says "this is the standard module plus these
known Errata ".
OK if this is in the form of deviations

In the end, I see no substitute to relying on “revision” history which 1)
> perfectly tracks branching history and can flag if/when NBC changes
> occurred.

> Kent // contributor