Re: [netmod] Comment on draft-clacla-netmod-yang-model-update-02

Ladislav Lhotka <lhotka@nic.cz> Wed, 15 November 2017 10:52 UTC

Return-Path: <lhotka@nic.cz>
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 27DD4128D2E for <netmod@ietfa.amsl.com>; Wed, 15 Nov 2017 02:52:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level:
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 4pkpw9tRlm-d for <netmod@ietfa.amsl.com>; Wed, 15 Nov 2017 02:52:04 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1B0E124BE8 for <netmod@ietf.org>; Wed, 15 Nov 2017 02:52:03 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:67c:1232:144:1a4f:a84b:2bfd:c611]) by mail.nic.cz (Postfix) with ESMTPSA id CADB864262 for <netmod@ietf.org>; Wed, 15 Nov 2017 11:52:00 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1510743121; bh=bIU6pJU7ZbofYdP6Msw6igkq5oE0RMSlVivX9Md9BDc=; h=From:To:Date; b=cTVhknjAeog1r1dg0ko3UB6zIZ+6XueQ+TXvUxl5IWx1vYWPK8SfRVmgxDTSiw+Nn ec6BitjznZkWs7EdleQSpGG3suzsJaBx5hAj18OIsJTrS+mwInCPa8CvM2o+c+NZlc uJwfzMscM/Rxef6PfETMzCa7nuut0HS29ZYdwq14=
Message-ID: <1510743187.21877.13.camel@nic.cz>
From: Ladislav Lhotka <lhotka@nic.cz>
To: netmod@ietf.org
Date: Wed, 15 Nov 2017 18:53:07 +0800
In-Reply-To: <55fcf67e-6e27-4bd9-cdd6-62f3fbe11bff@ericsson.com>
References: <20171114212210.7b2g3t3nqzrhcgrs@elstar.local> <20171115053046.nr33ypoibdn4jufv@elstar.local> <9094b945-366f-145d-fbc1-5cf116f4a3bc@cisco.com> <20171115.095341.1585161898755400575.mbj@tail-f.com> <55fcf67e-6e27-4bd9-cdd6-62f3fbe11bff@ericsson.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.2
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/vo69n3bycSMHYLQKvpHsoJQECNQ>
Subject: Re: [netmod] Comment on draft-clacla-netmod-yang-model-update-02
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: Wed, 15 Nov 2017 10:52:05 -0000

On Wed, 2017-11-15 at 18:12 +0800, Balazs Lengyel wrote:
> The server MAY implement obsoleted nodes or MAY NOT. This may or may 
> not  is not good enough as a contract for the management client.  My 
> problem is that the current solution is just not good enough. IMHO we 
> need to change it.

I agree. My observation has been that the YANG contract is often interpreted in
a very server-centric way: clients just have to be prepared to any surprises.
(This reminds me of the contracts I have with insurance companies.)

Yet I think it is quite important to also support dumb clients that are written
to do some job, and may easily break if a node suddenly disappears.

Lada

> 
> Even after semver you can still obsolete the old stuff and provide the 
> new stuff with a new name, although that might not be the common 
> practice.  Which is a good thing, as I believe it is sometimes better to 
> correct existing definitions then to replace them.
> 
> regards Balazs
> 
> 
> On 2017-11-15 16:53, Martin Bjorklund wrote:
> > Exactly.  With the current solution, the sever can still implement the
> > deprecated or obsolete nodes in order to support old clients.
> > 
> > With a MAJOR update in a semver world, it means that the old nodes are
> > removed (or rather, possibly, that the old nodes have new syntax
> > and/or semantics).
> > 
> > 
> > 
> 
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67