Re: [netmod] Query about draft-ietf-netconf-rfc7895bis-06

Robert Wilton <rwilton@cisco.com> Wed, 09 May 2018 16:15 UTC

Return-Path: <rwilton@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 27398126E01 for <netmod@ietfa.amsl.com>; Wed, 9 May 2018 09:15:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.611
X-Spam-Level:
X-Spam-Status: No, score=-12.611 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 kRvea-Gn9_2Y for <netmod@ietfa.amsl.com>; Wed, 9 May 2018 09:15:15 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEFB5126C83 for <netmod@ietf.org>; Wed, 9 May 2018 09:15:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3756; q=dns/txt; s=iport; t=1525882515; x=1527092115; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=KdQhZdNCloK/4pKNkYz4Kr3xhtyCo0w3J+AzY0yd1Yw=; b=A9SHXhvveYW44CUdfAdg63+XkNUmF8u4M+Orz7la8Y99fqRibV0N/cpM XOHvufYnDlQGqSl4WZPkuQBrZB4BUi34LgkY5rDErXdQhSdu5fT3JLWBk Ev4s+o1bku8VgGc/zetYEQ60X67B00Uy+3lI0zbLga55ucU3lZGhTbg5N o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CSAwB7HfNa/xbLJq1cGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYUehBeIYI1jKYEPkz6BZAuEbAKDDjcVAQIBAQEBAQECbCiFKAE?= =?us-ascii?q?BAQECASMPAQU1HAsYAgImAgJXBgEMCAEBF4MIgXkIpzkRgSCCHIRYg2yCSIE?= =?us-ascii?q?JiHA/gQ8jgmiEW4MYglQCmCwIjkkGgTWDYII9hRGLK4UkgSUyIoFSMxoIGxU?= =?us-ascii?q?7gkSCHxeOGD6RVAEB?=
X-IronPort-AV: E=Sophos;i="5.49,382,1520899200"; d="scan'208";a="3682284"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 May 2018 16:15:13 +0000
Received: from [10.63.23.78] (dhcp-ensft1-uk-vla370-10-63-23-78.cisco.com [10.63.23.78]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w49GFCSA022480; Wed, 9 May 2018 16:15:12 GMT
To: Rohit R Ranade <rohitrranade@huawei.com>, "netmod@ietf.org" <netmod@ietf.org>
References: <991B70D8B4112A4699D5C00DDBBF878A6B203A98@DGGEMA502-MBS.china.huawei.com> <20180509063034.iclb6vbbua5nqu6p@elstar.local> <991B70D8B4112A4699D5C00DDBBF878A6B204D26@DGGEMA502-MBS.china.huawei.com> <20180509095352.zahi7yuljb7ucd4x@elstar.local>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <1e103670-31e9-0c20-0cfa-86526e7486d8@cisco.com>
Date: Wed, 9 May 2018 17:15:12 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <20180509095352.zahi7yuljb7ucd4x@elstar.local>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/Ib6sPfHsF5gyYFZ699jcjYYYq9c>
Subject: Re: [netmod] Query about draft-ietf-netconf-rfc7895bis-06
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, 09 May 2018 16:15:17 -0000

Hi Juergen,


On 09/05/2018 10:53, Juergen Schoenwaelder wrote:
> On Wed, May 09, 2018 at 09:12:12AM +0000, Rohit R Ranade wrote:
>> On Wed, May 09, 2018 at 02:31:15AM +0000, Rohit R Ranade wrote:
>>> Hi All,
>>>
>>>
>>> 1.       "import-only-module" is currently under the "module-set" list. How does the client benefit by learning which module-set imports which modules ?
>>                All non import-only modules of the schema are implemented
>>                with their associated features and deviations.
>>
>> Modules in module-set/module are modules a datastore referencing the module set implements, modules in module-set/import-only-module are modules a datastore referencing the module set only imports from.
>>   
>>> 2.       Whether we can keep the "import-only-module" as a sibling to module-set. And let it list all the imported modules.
>> A module set is a self contained set of modules and import only modules.
>>
>> [Rohit R Ranade] One use-case I thought of was that a client was concerned with only some data-stores. So they can download the schema of only those modules and their imported modules of their data-stores of interest. But if this was the case, then the "checksum" is of no use to them, as they will not know whether their intended data-store changed or not. Is there any other use-case for the import-only-module being part of module-set ?
> The checksum indicates a change in YANG library. If a client is only
> interested in some datastore schemas, then the client may reload data
> even though the specific datastore schema did not change. There were
> versions with more checksum objects but at the end we removed them and
> kept only the one that is essential to keep. Note, if you use
> RESTCONF, then ETAGS may help with more granular checks. (In fact,
> instead of spreading checksum objects all over, it seems RESTCONF does
> not really need them and if NETCONF needs more granular chance checks,
> it seems a generic solution that can work on arbitrary subtrees is a
> better solution than spreading checksum objects everywhere.
+1 for a generic solution.

At the moment RFC 8040 states that ETAGS only apply to configuration, so 
they don't necessarily help with operational data.

Perhaps we should be introducing something like ETAG support for 
operational as well.  Although, we would need to careful consider the 
implementation performance impact.  Given that operational data may come 
from multiple daemons, it may be very hard to efficiently generate 
reliable ETAGs that span across large chunks of operational data.

Thanks,
Rob


>
> The use-case for import-only-modules being part of a module set is to
> allow a module-sets to be referential complete, i.e., different
> module-sets may have diffferent import-only-modules.
>   
>>> 4.       Also I feel the text about "netconf-capability-change" notification based on yang-library checksum should be moved to the NETCONF NMDA draft.  Is it not more suitable there ?
>> The reason is that NMDA is a very generic architectural document and as such it should not detail specifics of concrete notifications.
>> These details belong into the specific documents. The NMDA document is a root of a document dependency tree, we should not create a mesh of document dependencies.
>> [Rohit R Ranade] Please note I mentioned " should be moved to the NETCONF NMDA draft ", by which I meant draft-ietf-netconf-nmda-netconf-05, not the RFC 8342
> Sorry for my mis-understanding. YANG library defines the checksum and
> the checksum may trigger a netconf-capability-change notification, so
> this is likely why talk about the netconf-capability-change notification
> in YANG library.
>
> /js
>