Re: [netmod] adoption poll for yang-versioning-reqs-02

Andy Bierman <> Wed, 20 March 2019 20:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F3E5212796D for <>; Wed, 20 Mar 2019 13:59:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 V5N1xgOAEkzf for <>; Wed, 20 Mar 2019 13:59:36 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ACBEF124BF6 for <>; Wed, 20 Mar 2019 13:59:35 -0700 (PDT)
Received: by with SMTP id m13so2988167lfb.6 for <>; Wed, 20 Mar 2019 13:59:35 -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=j9yZOIU30SvWF2dzpCsgIOAqB4VcatFz8N3qIMlWDEo=; b=kxNA0M8gcW2z+6HllbujavQvyW1jCh9F33K1Xf8/HufgsAXK9gHZRAbQUYX3gyVSbl L3YfFCVjB7UXj1qLyZyWafmQhR1sXrVR+iCUJHwknmcLQ5MMFX+9+fq512pVnuo4ER2q 9Lv9mOsHz5iV6PAX4j/Pg611jwL1pnPAecd/TLTrPqFTUgM0HDtc26EpfWwr957EQjYP XoOyBHGsQCP4zdLvDejlrtNfUkZCvO44hwXJUpmAVS8Kcng/9rtG348euCf94WxSTMES wlTZrVkYXJ03Cdqqpe65phhPp1df+jvwXOau9uC1iXg8HifohhmegwUN4om/XEv7AYxQ /3ZQ==
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=j9yZOIU30SvWF2dzpCsgIOAqB4VcatFz8N3qIMlWDEo=; b=Ijj7tspTgNxJC+H9WVaHMAa4LcwO2TRCz8e4wFrItw+ZyMkA6QCeshedmHFS8llQbA WIt4TMogOCFSbudKEB2YKA+Vyrj10WkdzIT6d7Gd2vlhjpFdyEqH0ec4aIW9HAuhNvER kDnExRKiu44wtAhWBeT1SfERllReCS/PAS/xHIznxaB3sLcwC79J2/Dre/FPyNgYXNMn 5EBH2wyvGheQeUl1EtdAOO+t3EMGTCkZOSaWXZ6xo5tV/gnjKFFoVftVmqU2S1nr7enR rFBn2T3dmrd5x3ffVfyA0yROixUdZnqEu2XDbFR6BXn42zT9GkNejNuHmINnDm9pQwkc 7U8w==
X-Gm-Message-State: APjAAAUsFqMvstfoNCKR6g8EqNUxAlz4+TuM+hQzw+r/YSLSTYn1wh7W +7sySxArjd2oidPgmihtxiuImWQiLfm6EBGFr/aUhw==
X-Google-Smtp-Source: APXvYqxXKTiv1WD3Tz8nSnuf0bJ54Ea3I5SasJbEsiDAYBJnVKktKD76iu+V9peGJ7sWtdSBNY1UNVj6u2m/8QVGgGI=
X-Received: by 2002:ac2:569b:: with SMTP id 27mr18344714lfr.24.1553115573681; Wed, 20 Mar 2019 13:59:33 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
From: Andy Bierman <>
Date: Wed, 20 Mar 2019 13:59:22 -0700
Message-ID: <>
To: Kent Watsen <>
Cc: "Rob Wilton (rwilton)" <>, Martin Bjorklund <>, "" <>
Content-Type: multipart/alternative; boundary="0000000000001091c805848ce621"
Archived-At: <>
Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02
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: Wed, 20 Mar 2019 20:59:38 -0000

On Wed, Mar 20, 2019 at 12:24 PM Kent Watsen <> wrote:

> I don't think the versioning data nodes is a good idea.
> I have seen entire REST APIs be versioned, but not individual parameters
> within the API.
> FWIW, I have seen individual resources versioned within a REST API, in
> lieu of a version number in the beginning of the URL.  The REST API
> presented resources for versioned "objects", each having a distinct media
> type for content negotiation
> (e.g., application/vnd.<company>.<object>+[xml/json];v=2).
> Clients asked for what they could support (including older versions, in
> case the server didn't support the latest).  Server's up/down-converted
> objects through a chain of converters.  Each release only had converters
> to/from the previous release, but only for the objects that changed.
> It worked well.  The API was stable. Clients did not have to support all
> the new object versions in one go.  Incremental transition was common.

This is much simpler because the REST APIs are like RPC operations in YANG
-- they do not interact with each other.
In fact, it is impossible in YANG to have the XPath/leafref
cross-references in 1 RPC access another RPC.

It is easy to support many revisions of an RPC operation.
Not so easy for the contents of a YANG datastore.

Changing the data type, config-stmt, or data definition type are drastic
changes that will affect cross-references.
These might be the only NBC changes that really matter. Anything else you
could call a bugfix
and it would be better to fix than replace (e.g., add/modify/delete

I agree with Martin that NBC changes cannot be allowed and a new definition
is required to replace the broken one.

Perhaps Lada is right that the YANG update rules are too strict.
There are many things that could be considered a bugfix that are not
But I don't think a version string format fixes any of the hard problems.
More YANG statements, extensions, and annotations (in NETCONF) are needed
to really address the problem, (E.g., where is the 301 Redirect for