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

Joe Clarke <jclarke@cisco.com> Wed, 15 November 2017 10:27 UTC

Return-Path: <jclarke@cisco.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 987CB129553 for <netmod@ietfa.amsl.com>; Wed, 15 Nov 2017 02:27:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level:
X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 xpwGuQM1XUcU for <netmod@ietfa.amsl.com>; Wed, 15 Nov 2017 02:27:22 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4C3012954B for <netmod@ietf.org>; Wed, 15 Nov 2017 02:27:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=980; q=dns/txt; s=iport; t=1510741642; x=1511951242; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=dSiNs7ovqCZVb1EeAzn4r5EXyUqIGcpIj7RJDgiQ+AI=; b=QtiC0kC1uiYXnTaKeZ5ijVaYmvlIB9G+oaOuc3uQlNDwV7FITKknciQZ /O3LmwSix3SiaEA4Fw9F4O7IyAa8NuNyT/tfawXDpLxk7My7fjnwndecV t8skTzE9Lp1NLkKGH+/m0haBxYer25Tb+6T6U5hb2Hzoj5kIetkXJqUx8 Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0C1AQD7FQxa/4QNJK1dGQEBAQEBAQEBAQEBAQcBAQEBAYM2gVKEJplAgX2WWoIRCoU7AoUHQRYBAQEBAQEBAQFrKIUfAQUjDwFWCxgCAiYCAlcTCAEBiiCneYInixcBAQEBBgIBJYEPgiWCB4FVghKDAYUCYoJJgmMFkwWPMpUGghWJaodFijKLe4E5JQExgXRVJRWDLoR8I4kXAQEB
X-IronPort-AV: E=Sophos;i="5.44,398,1505779200"; d="scan'208";a="31697972"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Nov 2017 10:27:22 +0000
Received: from [10.24.101.203] ([10.24.101.203]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id vAFARKbh010441 for <netmod@ietf.org>; Wed, 15 Nov 2017 10:27:21 GMT
To: netmod@ietf.org
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>
From: Joe Clarke <jclarke@cisco.com>
Organization: Cisco
Message-ID: <2daae313-cbf1-c26a-c176-a3d31b57092d@cisco.com>
Date: Wed, 15 Nov 2017 05:27:20 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <87inebdff0.fsf@nic.cz>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/76HIYLaDjpNV1MQvmtgbWa2UwYk>
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:27:23 -0000

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?

Joe