IETF Logo Mail Archive

Re: [netmod] rfc7223bis Backward compatibility in YANG - BAD !!!

Andy Bierman <andy@yumaworks.com> Thu, 09 November 2017 17:36 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 02A911243F6 for <netmod@ietfa.amsl.com>; Thu, 9 Nov 2017 09:36:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 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, 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 wGCcPbm2QKHj for <netmod@ietfa.amsl.com>; Thu, 9 Nov 2017 09:36:16 -0800 (PST)
Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (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 7673C12726E for <netmod@ietf.org>; Thu, 9 Nov 2017 09:36:16 -0800 (PST)
Received: by mail-lf0-x235.google.com with SMTP id r129so8124306lff.8 for <netmod@ietf.org>; Thu, 09 Nov 2017 09:36:16 -0800 (PST)
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 :cc; bh=zoauOc7LEktXzqStUA0rrOADj6Qr41KpBe9suGyExrY=; b=dijysABpTuewKY79uopNlSCu4YkG2ijI6fxjuU95v9tCKnvCIHfm4xm4umR0G2fwLD T8bpllgJaBJaQTgb4Bt7cdoD3aEGr2ecI7pkBlQ/T8FVJKx9Q1wau/IXrskPnZmgLcel l2I/PARlR6ts9IIvMmcR0dh3hOXgnT9S9qiKfHCdbfwFMu+C4V2Jun4TdZaizFq5Fo6s ybqRo2c8cmqV5lqMByJF1vHiCaGX8EOv8lUGDEZMXTVLJ0F90n95JIbR3pEkoZsbgQtu P7PAiiyXz7RGFQWC1AmqWGPQChPIIAK2d7Kb0DnIwVNNFttDHQiA68ruC8A4N3GiOC9a e3hA==
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:cc; bh=zoauOc7LEktXzqStUA0rrOADj6Qr41KpBe9suGyExrY=; b=djpm8h8V0F8vRi1NSlokCjzkuV44y3rON2Hzvf91XlYyopP251MUrsDdw/s54vEHrW YNpsRtKOaq5iHocv/AaoWSUFDBwk+wNvN6tdmwSN6q/npOFb8JECirPNNk+mJCsJUOAc XKckENJuoqCsb8DPbXPRaEh0XcJkRk022ORu7EE3/lgRi2pMA4mf2ZDYedrCgtQ4Hk23 EybX2IkJddXB8UMursduuk0j7FpU20SgAPt55PXdRwUzAzV4lM1LDQlIsuR2Gep7OnPn E1QB15o5jDjPDHzhUg2NNfencQhLdYZLLS3dhpQESqPpRgyB2H01n6tKrF2nzUgZmYaw Svjg==
X-Gm-Message-State: AJaThX5pCnvI9KEAC7++nbR2IFPxqQOVkSojNsT8jStbigZBdumquM77 cD4ZcZG0S9mKmKbBo7dW4iTNcvhwB8kUqiFurTOEog==
X-Google-Smtp-Source: AGs4zMbgW1fo7qD4GjIeE8RWNihbe8bgl6MP+rYuAB+SxjusUaAbbSea30O+lBu9o7LLQCo/ydgZKTsMSec4cBilZQU=
X-Received: by 10.25.221.217 with SMTP id w86mr38259lfi.89.1510248974708; Thu, 09 Nov 2017 09:36:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.214.9 with HTTP; Thu, 9 Nov 2017 09:36:13 -0800 (PST)
In-Reply-To: <01a4beef-4a86-fa10-dc81-7dd57e12a9a8@ericsson.com>
References: <01a4beef-4a86-fa10-dc81-7dd57e12a9a8@ericsson.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Thu, 09 Nov 2017 09:36:13 -0800
Message-ID: <CABCOCHR50-rSPnHA=6A7CrWHSGCrmPfiQQV+Vrax10eCBg-JWQ@mail.gmail.com>
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
Cc: "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c0ec71ea91eed055d903dde"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/PNZitZdavYuMQewJkXAffTIAr3k>
Subject: Re: [netmod] rfc7223bis Backward compatibility in YANG - BAD !!!
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: Thu, 09 Nov 2017 17:36:19 -0000

On Thu, Nov 9, 2017 at 8:59 AM, Balazs Lengyel <balazs.lengyel@ericsson.com>
wrote:

> Hello,
> In draft-ietf-netmod-rfc7223bis-00 I read
>
> The "/interfaces-state" subtree with "config false" data nodes is
>    deprecated.  ...
>
>    Servers that do not implement NMDA, or that wish to support clients
>    that do not implement NMDA, MAY implement the deprecated
>    "/interfaces-state" tree.
>
> This means that a server MAY simply remove a big branch
> (interfaces-state). If I have a network management system (NMS) and the
> YANG server upgrades to a new revision of the module suddenly my NMS SW
> breaks.
>
> I find it really strange that, on a one hand YANG has very strict rules
> about updating a module, on the other hand just by deprecating something
> you can remove anything. Are we taking backward compatibility seriously or
> not? It seems not.
>
>

Ironically, the NMDA approach was sold as the solution path without any
disruption to the data models.

Customers will pressure vendors to fix "stuff that used to work" and
generally
vendors avoid breaking it in the first place.  3rd party NMS has never been
a priority
anywhere, including the IETF.


Earlier we had discussions about the definition of deprecated and obsolete
> in https://tools.ietf.org/html/rfc7950#section-7.21.2.
> From an NMS point of view the current definition just states: Anything can
> be deprecated/obsoleted anytime. If something has a status different from
> current there is no guarantee its usable or even that it exists.
>
> IMHO these definitions are unusable for an NMS. Ericsson needed to
> introduce its own rules. IETF should do something about this! I have
> proposals if there are people interested.
>
> As a minimum I would propose, that a server that does not implements a
> fully functional /interfaces-state" subtree MUST obsolete it, not just
> deprecate it.
>


how does this help?
Duplicate read-only data does not break anything.
An old client can keep reading /interfaces-state and a new client
can use <get-data>.

There are some problems with NMDA that break old clients (e.g., rpc and
action)
but this isn't one of them.



> regards Balazs



Andy


>
>
> --
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

v2.23.0 | Report a Bug | By Email