Re: [netmod] Datastore leaf for yang instance data

Robert Wilton <rwilton@cisco.com> Wed, 28 November 2018 15:43 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 57F5E12D4E6 for <netmod@ietfa.amsl.com>; Wed, 28 Nov 2018 07:43:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.96
X-Spam-Level:
X-Spam-Status: No, score=-15.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 GEop7c2quH2W for <netmod@ietfa.amsl.com>; Wed, 28 Nov 2018 07:43:05 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58496128CF3 for <netmod@ietf.org>; Wed, 28 Nov 2018 07:43:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2717; q=dns/txt; s=iport; t=1543419785; x=1544629385; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=8/sWFS21+N5ZEq+3WEn8EBFci4lgO+g5DqW4jFPmtnY=; b=LHG5WP5oKlWh/2o39P8KYcKZIGN50qSn/CGcAbeBq4eZyO/PbicFylI8 3iMPOdkSrw1oTxghhlQRvcICF1rSYAnCDds2E5h+TFl2S127+HUofKPp3 oU3J3CjyIYw7T9w6ro7Y6b/ZdoITw3VkhYVeI74oNdZQpfqO3wlyGHxZH s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAABAtv5b/xbLJq1bCRkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVEEAQEBAQELAYM4IRKEIIgYX40KCCWXQoF6DYF3gnU?= =?us-ascii?q?Cg040CQ0BAwEBAgEBAm0ohT0BBSMPAQVRCxgCAiYCAlcGAQwIAQGDHYICpm6?= =?us-ascii?q?BL4VAhHyBC4sigUA/gREnDIIxLoRXgy6CVwKVRYpWCZErBhiJaIctiHaIboZ?= =?us-ascii?q?kgUY4gVUzGggbFYMokFo/A45qAQE?=
X-IronPort-AV: E=Sophos;i="5.56,291,1539648000"; d="scan'208";a="8449908"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Nov 2018 15:43:03 +0000
Received: from [10.63.23.68] (dhcp-ensft1-uk-vla370-10-63-23-68.cisco.com [10.63.23.68]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id wASFh1rF022341; Wed, 28 Nov 2018 15:43:02 GMT
To: =?UTF-8?Q?Bal=c3=a1zs_Lengyel?= <balazs.lengyel@ericsson.com>, Ladislav Lhotka <lhotka@nic.cz>, Martin Bjorklund <mbj@tail-f.com>, "netmod@ietf.org" <netmod@ietf.org>
References: <87y3a6izap.fsf@nic.cz> <20181106063648.jjf2scqzoack5l3z@anna.jacobs.jacobs-university.de> <58740c15bf3277e04329546476f60c1d12516594.camel@nic.cz> <20181106.104157.239419955739949818.mbj@tail-f.com> <866ff105cf8fda7eadbdce5b344f4cd734fd99b8.camel@nic.cz> <1f4103c1-4953-3df4-d50d-aed1961fbc50@ericsson.com> <20181123154951.anviss5nllq6gwrn@anna.jacobs.jacobs-university.de> <d1716b42-12d0-072a-76b7-74b9a8efcbe9@ericsson.com> <20181128102050.37iyrx2xhdohnepb@anna.jacobs.jacobs-university.de> <bff9a787-f9fd-1bbc-e6f2-e0dfe3fbad63@cisco.com> <20181128153215.og7yweannmux35ti@anna.jacobs.jacobs-university.de>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <f60b0d28-0747-2478-a1c4-07924151d30d@cisco.com>
Date: Wed, 28 Nov 2018 15:43:01 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1
MIME-Version: 1.0
In-Reply-To: <20181128153215.og7yweannmux35ti@anna.jacobs.jacobs-university.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.68, dhcp-ensft1-uk-vla370-10-63-23-68.cisco.com
X-Outbound-Node: aer-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/ccd4bqbJxT1Q88uubt4h1B5qzLI>
Subject: Re: [netmod] Datastore leaf for yang instance data
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
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, 28 Nov 2018 15:43:08 -0000

On 28/11/2018 15:32, Juergen Schoenwaelder wrote:
> On Wed, Nov 28, 2018 at 03:27:26PM +0000, Robert Wilton wrote:
>> On 28/11/2018 10:20, Juergen Schoenwaelder wrote:
>>> On Wed, Nov 28, 2018 at 09:41:12AM +0000, Balázs Lengyel wrote:
>>>>> I do not buy this story. Your software needs to decide somehow what
>>>>> instance data means. A config true leaf in candidate means something
>>>>> different than the same config true leaf in running and this yet again
>>>>> means something different than the same config true leaf in operational.
>>>>>
>>>>> /js
>>>> BALAZS: As I understood the WG decided that this draft should only be about
>>>> the format of the yang instance data. What the SW does with it is out of
>>>> scope. So considerations whether instance data should be loaded into running
>>>> or candidate or not at all, are outside the scope.
>>> If you do not know what the instance data means, any attempt to use it
>>> is kind of broken.
>>>> I want to provide a datastore indicator, but how that should be used (and
>>>> thus what is exactly means) is out of scope.
>>> I disagree. The datastore indicator is needed to understand what the
>>> data means, i.e., to do anything meaningful with it.
>> I think that a datastore indicator is useful sometimes.  E.g. it might be
>> helpful in some cases to know that the data was associated with a particular
>> datastore.
>>
>> But in the general case I think that this is just "data at rest", and
>> probably the key thing to know is whether (i) the data relates to
>> configuration, or (ii) the data relates to operational state.
>>
>> This could potentially be inferred from a datastore leaf, or perhaps this
>> distinction could more explicitly be made by a separate field, which I would
>> make an enumeration or identity, since there might be other types of data in
>> future, such as capability information or diagnostics.
>>
> I do not understand why a datastore leaf is not sufficient and why we
> need yet something new. If ever needed, NMDA does allow us to define
> new datastores.

Because a distinction between "candidate" vs "running" vs "intended" 
won't necessarily be that useful.  Although knowing "running" vs 
"intended" would allow the client to know whether it is pre/post 
template expansion and that might be useful.

The second reason is that I don't know whether things like capabilities 
and diagnostics will be new datastores or just part of operational.  I 
don't think that either of these two areas have really been properly 
worked out yet.  I presume that they will come over time, once more 
network management becomes more automated.

Thanks,
Rob


>
> /js
>