Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

Andy Bierman <> Thu, 25 October 2018 17:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BA91A130EC9 for <>; Thu, 25 Oct 2018 10:07:59 -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, 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, 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 Quenb4Fc5LmJ for <>; Thu, 25 Oct 2018 10:07:57 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 670D0130EC7 for <>; Thu, 25 Oct 2018 10:07:57 -0700 (PDT)
Received: by with SMTP id s15-v6so8951221lji.3 for <>; Thu, 25 Oct 2018 10:07:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JuyI4uDur2JN1Q+HiE7cTQ/9M+8ZzsTQXGvpAv4nO2E=; b=YHwK6s73nsmU9bOtqn6evSvuZSWiPyVFJWYjPctfNEZypnNaSzuQYO9KHUjweRmYBO RJhgZNvHPTrJFTxVMJsPrmbSdVjA2/Q+kswWq3VLOX9f+/lqRUryOA+fmbGcUhn0Ll5Y SYl3Q+1KSWte64wHONEKI05raPSt+0yMPTwU8WXS4oQOeir6Ivypu7X1VTXLuLCcGKyE qyi7fJ7l44nBGoxIHMb6XaemIpYOkmCBpngvBQuVgtWTLdVRsjxFPoBH1ixRuUSmp16i dROilHeJZrDHib8Ox9QXLU5CyXMMHzLV8lUbJ90fYudNPsWm1CqmTG+OJGh2AoDVXzNX 0Tdg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JuyI4uDur2JN1Q+HiE7cTQ/9M+8ZzsTQXGvpAv4nO2E=; b=XD9fux0QWOEYh5nLsrfSR9IdFtOYvBo1b9mIGhOsfhd9lWWQ+RK5y6TmtPqfobdLEl fGhgeivYqdUb7vMq9StcPwmabuEzS1/ZXmIOoSgO5PCwiI90qkR+9xI/TLM35a0VP0KH n+0ja0M7Zxa5eDicMLnZauk3SqFOxFx67f549A2m+n6nopxGP7Xw2AyOVNEqHkGE99Zu kWU8KmgB2BoGyb90Ztwmnq0Bx1o6JvwQaD7ACscX8+CWZf+BPGH1x02a1KUORm1RkWFY 5n/IBnurTuA4m9UKR+1kz4zi/nqoHR+u69Ba2V3YHVODV/JervHRhvDIZqeiWw7Y7HJs 5qzQ==
X-Gm-Message-State: AGRZ1gKvlIKNroX5sRt/bWsunXaPxG2ROFI1OqYWYIbuuPA8ZkBUA2XS zEckTZ+W3DNUkbgfLEeTDubFFiRLO9Re8lfyNU48QA==
X-Google-Smtp-Source: AJdET5co7htbJUH6QrN9zxUunzC4BWgIVOkbCz3DoSbPcYcVmjLdYA+QXsJmxbolYV4xf95axlr9bQpnLbcco2q+xQ8=
X-Received: by 2002:a2e:4408:: with SMTP id r8-v6mr43818lja.21.1540487275310; Thu, 25 Oct 2018 10:07:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:1f87:0:0:0:0:0 with HTTP; Thu, 25 Oct 2018 10:07:54 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Andy Bierman <>
Date: Thu, 25 Oct 2018 10:07:54 -0700
Message-ID: <>
To: Christian Hopps <>
Cc: Joe Clarke <>, "" <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000d3832f057910a471"
Archived-At: <>
Subject: Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
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: Thu, 25 Oct 2018 17:08:00 -0000

On Thu, Oct 25, 2018 at 8:26 AM, Christian Hopps <> wrote:

> > On Oct 20, 2018, at 1:55 PM, Joe Clarke <> wrote:
> >
> > * New requirement 1.4 for supporting over-arching software releases
This text?

       1.4  The solution MUST allow for modules to be versioned by
            software release.  In particular, backwards-compatible
            enhancements and bug fixes MUST be allowed in any non-latest

IMO these requirements are mostly intended to legitimize bad practices be
server vendors,
entirely at the expense of client developers.

It is clear that SEMVER is required to support this requirement to
treat every platform as an isolated release of what are supposed to be
shared modules.
The revision date no longer identifies the latest (e.g, 1.6.1 could have a
newer date than 1.9.0)
However, SEMVER becomes less useful if 1.6.1 actually has more features
than 1.9.0.

YANG clients already have to deal with different variants (revision,
features, deviations) on every server,
so it would be easy to think that all these server variants are not a new
However, this only applies to parsing incoming data.  A client that is
designed to
formulate requests against specific data models is greatly harmed by a lack
of server

If YANG is ever going to grow up, the 3rd party client development needs to
be taken more seriously.


[ I read this as supporting various different module versions based on a
> vendor's different software release trains. If this is wrong then the rest
> of this doesn't apply and I would just ask for the text to be update to
> clarify what it means. ]
> How many operators/users have asked for this or indicated it's a
> requirement for them?
> What problem is intractable without this requirement being met, and what
> is the cost of this requirement on the actual users?
> I have pushed back multiple times on this b/c I believe this "requirement"
> is really being pushed to make it easier for vendors (a small affected
> group) to develop their software at the cost of their users (the much
> larger affected group) who would then have to deal with multiple trains of
> the same module.
> Here is what I am afraid the vendors want here: A developer on release
> train X can easily change some data structure and then push the change into
> an automated system which generates a new YANG module definition and revs a
> version number -- all done! They don't have to deal with the inertia of
> making this change in their release train Y or Z and they don't have to
> treat modules as a stable API they are exporting, b/c they now have these
> new wonderful versions from this work. Meanwhile we the users now have to
> deal with N forks with all the various little incompatible changes random
> developers at the company wanted to make without having to coordinate with
> their coworkers/other internal teams. Now multiply this by M vendors. It's
> a nightmare. It shouldn't be what we are optimizing for, let alone making a
> requirement.
> We already have features and deviations why are they not enough to deal
> with functionality that is present or not in various software
> release/devices?
> FWIW I'm not against making it easier to develop software, but we have to
> be mindful if we are just pushing the cost (and magnifying it greatly) to
> other people in the community.
> Thanks,
> Chris.
> _______________________________________________
> netmod mailing list