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

Ladislav Lhotka <lhotka@nic.cz> Wed, 15 November 2017 10:37 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 654A4126CC7 for <netmod@ietfa.amsl.com>; Wed, 15 Nov 2017 02:37:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level:
X-Spam-Status: No, score=-6.999 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, URIBL_BLOCKED=0.001] 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 QIwx7uO7ReJV for <netmod@ietfa.amsl.com>; Wed, 15 Nov 2017 02:37:31 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 37B6D126C0F for <netmod@ietf.org>; Wed, 15 Nov 2017 02:37:31 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:67c:1232:144:1a4f:a84b:2bfd:c611]) by mail.nic.cz (Postfix) with ESMTPSA id 0A07D6423B for <netmod@ietf.org>; Wed, 15 Nov 2017 11:37:28 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1510742249; bh=QF/X0dbKK7JFFSv3qcvvgISkFV2wQ/tkw807L7YWPto=; h=From:To:Date; b=YftvQOdYTItaBnduSTIKqvVCKKlNXu9NEvlv0zmY3YEZNhIz0i+SfKZjpfZNe8cdD NNULZ5aSyz7IxJx5qKH5COaZKO6pmE5ikwyg90s6esbJWHQGT+mEY58GKd+RYjJHek YnUdnoI/8L09hkEfkG5ZZKfOoVaGHoAtVBhmQbl0=
Message-ID: <1510742316.21877.6.camel@nic.cz>
From: Ladislav Lhotka <lhotka@nic.cz>
To: netmod@ietf.org
Date: Wed, 15 Nov 2017 18:38:36 +0800
In-Reply-To: <2daae313-cbf1-c26a-c176-a3d31b57092d@cisco.com>
References: <19a4129f-84b4-2d6b-8405-37b85952f53a@ericsson.com> <20171114212210.7b2g3t3nqzrhcgrs@elstar.local> <20171115053046.nr33ypoibdn4jufv@elstar.local> <9094b945-366f-145d-fbc1-5cf116f4a3bc@cisco.com> <87inebdff0.fsf@nic.cz> <2daae313-cbf1-c26a-c176-a3d31b57092d@cisco.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/eaS7fGmoe-9YcbDa7OM35YiJimU>
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:37:33 -0000

On Wed, 2017-11-15 at 05:27 -0500, Joe Clarke wrote:
> On 11/15/17 05:06, Ladislav Lhotka wrote:
> > > I suppose my gut reaction to Lou's question as to whether a server
> > > should support multiple versions was, "no."  A client may have multiple
> > > versions loaded to support servers that support different versions.  I
> > > may be convinced otherwise, but I feel that this will become untenable
> > > over time (even if module names change).
> > 
> > There are use cases for modules that are imported (i.e. not
> > implemented): it could be that a module author wants to use some
> > definitions from an old version of an imported module while, at the same
> > time, other definitions from a new version.
> > 
> > The semver-aware "import" statement should be able to deal with this.
> 
> I think it could be, but I also think importing from different versions
> of the same module feels messy.  How would this work with different
> module names today?  Just use different prefixes?  Are there defined use
> cases for this in the wild today?

Let's say a new version of a module adds new enums to two different enumeration
types, but an implementor (for some reason) is only able to update one of them
in the back-end and not the other.

Lada

> 
> Joe
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67