Re: [netmod] Last Call: <draft-ietf-netmod-revised-datastores-09.txt> (Network Management Datastore Architecture) to Proposed Standard configuration

Robert Wilton <> Tue, 09 January 2018 17:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B2701129516; Tue, 9 Jan 2018 09:26:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=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 2owArww3v49w; Tue, 9 Jan 2018 09:26:03 -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 3704C127522; Tue, 9 Jan 2018 09:26:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=12176; q=dns/txt; s=iport; t=1515518762; x=1516728362; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=rmMx1fcxKvg111FB9aFT8bvYBy/zUfdVe1I1r2z2h6A=; b=IbZB94rIzrUHzFE4Tqw8QInEBP5yhkP0fo4c6gcwAIGqTlpb+Bv4atq2 AQCS5qMOZf7Dn3AAEwChKmKNeNfiS7Ex8pSIR7N+ZO/qgJYE+7xemkxGJ sLflMLjq6voKn2TUkAgJyU6rurUByfOV3Un2i92gss7HrkBat902b/9AT o=;
X-IronPort-AV: E=Sophos;i="5.46,336,1511827200"; d="scan'208,217";a="1312080"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jan 2018 17:26:00 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id w09HQ0ro026867; Tue, 9 Jan 2018 17:26:00 GMT
To: "tom p." <>, ietf <>
References: <> <002501d3896b$4c17a3c0$>
From: Robert Wilton <>
Message-ID: <>
Date: Tue, 9 Jan 2018 17:26:00 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <002501d3896b$4c17a3c0$>
Content-Type: multipart/alternative; boundary="------------4EB7A8894C3059BBFAE51E41"
Content-Language: en-US
Archived-At: <>
Subject: Re: [netmod] Last Call: <draft-ietf-netmod-revised-datastores-09.txt> (Network Management Datastore Architecture) to Proposed Standard configuration
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 09 Jan 2018 17:26:06 -0000

Hi Tom,

The draft uses this definition for configuration:

    o  configuration: Data that is required to get a device from its
       initial default state into a desired operational state.  This data
       is modeled in YANG using "config true" nodes.  Configuration can
       originate from different sources.

The last sentence means that it encompasses configuration that comes 
from other sources such as protocol interactions.  I.e. by different 
sources it means that configuration may come via DHCP, or be learned 
from a peer protocol (e.g. hello timer values, Ethernet auto-negotiation 

The other sentence that is key is 'This data is modeled in YANG using 
"config true" nodes.'.  This statement applies both ways.  If you want 
to model configuration in YANG then it must be labelled "config true".  
Hence all nodes in the schema marked as "config true" are by definition, 
configuration.  Conversely, all nodes in the schema not marked as 
"config true" are by definition, not configuration.

So, I don't think that the definition for "configuration" changes 
through the definitions at all, it has the same meaning through out, 
i.e. the broader definition that encompasses data learned from other 
sources such as DHCP, peer protocols, etc, as well as conventional 
configuration received via NETCONF/RESTCONF or similar "regular" 
configuration protocols.

I think that the intent of "conventional configuration" probably matches 
your narrower definition of "configuration" that you describe below:


On 09/01/2018 16:38, tom p. wrote:
> This I-D re-arranges the tectonic plates which underly the IETF's
> management technology and is likely to affect all such work for some
> years to come.  As such, I want it to be clear and unambiguous but do
> not find it so.  I find it unclear as to the meaning of the word
> 'configuration'.
> Netconf (and latterly YANG) were instigated to facilitate configuration,
> which was narrowly defined as the values that a user might want to
> change to get a box from its initial state to its desired state.  What
> might have been thought as configuration historically - values learnt
> from hardware or the interactions of protocols - was not configuration
> but state, latterly referred to as operational state.  This narrow
> definition of configuration is reflected in this I-D.
> However, working through the 24 definitions that appear under
> 'Terminology', while the early ones use this narrow definition, by the
> time
> we get to
> "learned configuration: Configuration that has been learned via protocol
> interactions "
> or
> "system configuration: Configuration that is supplied by the device
> itself."
> the meaning has clearly changed to encompass all the different ways in
> which a device can learn a value i.e 'learned configuration' and 'system
> configuration' are not configuration as has been understood up until now
> in this work.
> I think it hard to follow this I-D when this key term seems to have a
> variable meaning. I am uncertain what meaning to attribute the word when
> it appears in the later text.
> Tom Petch
> ----- Original Message -----
> From: "The IESG" <>
> Sent: Thursday, December 21, 2017 7:23 PM
>> The IESG has received a request from the Network Modeling WG (netmod)
> to
>> consider the following document: - 'Network Management Datastore
> Architecture'
>>    <draft-ietf-netmod-revised-datastores-09.txt> as Proposed Standard
>> The IESG plans to make a decision in the next few weeks, and solicits
> final
>> comments on this action. Please send substantive comments to the
>> mailing lists by 2018-01-10. Exceptionally, comments may
> be
>> sent to instead. In either case, please retain the
> beginning of
>> the Subject line to allow automated sorting.
>> Abstract
>>     Datastores are a fundamental concept binding the data models
> written
>>     in the YANG data modeling language to network management protocols
>>     such as NETCONF and RESTCONF.  This document defines an
> architectural
>>     framework for datastores based on the experience gained with the
>>     initial simpler model, addressing requirements that were not well
>>     supported in the initial model.  This document updates RFC 7950.
>> The file can be obtained via
>> IESG discussion can be tracked via
> llot/
>> No IPR declarations have been submitted directly on this I-D.
> .