Re: [netmod] Datastore leaf for yang instance data

Robert Wilton <> Wed, 28 November 2018 15:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 57F5E12D4E6 for <>; Wed, 28 Nov 2018 07:43:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.96
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GEop7c2quH2W for <>; Wed, 28 Nov 2018 07:43:05 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 58496128CF3 for <>; Wed, 28 Nov 2018 07:43:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; 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-AV: E=Sophos;i="5.56,291,1539648000"; d="scan'208";a="8449908"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Nov 2018 15:43:03 +0000
Received: from [] ( []) by (8.15.2/8.15.2) with ESMTP id wASFh1rF022341; Wed, 28 Nov 2018 15:43:02 GMT
To: Balázs Lengyel <>, Ladislav Lhotka <>, Martin Bjorklund <>, "" <>
References: <> <> <> <> <> <> <> <> <> <> <>
From: Robert Wilton <>
Message-ID: <>
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: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [netmod] Datastore leaf for yang instance data
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


> /js