Re: [netmod] [EXTERNAL] Re: Question on RFC8342 + RESTCONF extension (draft-ietf-netconf-nmda-restconf)

Robert Wilton <> Tue, 11 December 2018 16:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B29FE130DDB for <>; Tue, 11 Dec 2018 08:05:40 -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 05ktHG__CWYM for <>; Tue, 11 Dec 2018 08:05:34 -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 C57D712DDA3 for <>; Tue, 11 Dec 2018 08:05:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=5599; q=dns/txt; s=iport; t=1544544334; x=1545753934; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=0SLPDpj6EHxBQHCKEWAE8w13s2hvYQBSCH5vw+0m54M=; b=AMyExzCliGoafN7Dd+hZoUxEHHsp4a99VmYg6461ujD2BTJ5cUQslM3r xWr13XNKhn4rGtp3LVXVIATij5afHkJk7Kmty4Jbe6nUNPh8IryX+ieJy QfmqGWvQEWWeOB5tJujeNGNL0T7JFAGDs42yHIrP2KCx2ZwWr3NcW+h2W w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAACo3w9c/xbLJq1hAxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVEEAQEBAQELAYJpcBIng3uIGV+NEQgll1KBeg0YC4Q?= =?us-ascii?q?DRgKDDjQJDQEDAQECAQECbRwMhTwBAQEBAgEBASEPAQU2Cw4CCxAIAgIfBAM?= =?us-ascii?q?CAhsMHxEGDQYCAQGDHQGBeQgPpVaBL4VAhGwFgQaLR4FAP4ERJwyCX4FBgV0?= =?us-ascii?q?BAYFLNyaCPYJXAqAmVQmHCYM8hwYGGIFcTYRKgwMmhySSSoZpgUY4gVYzGgg?= =?us-ascii?q?bFTuCbAmCKh2DOIUUhT8/AzCLaAEB?=
X-IronPort-AV: E=Sophos;i="5.56,342,1539648000"; d="scan'208";a="8772404"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Dec 2018 16:05:31 +0000
Received: from [] ( []) by (8.15.2/8.15.2) with ESMTP id wBBG5VPS010506; Tue, 11 Dec 2018 16:05:31 GMT
To: "Seehofer, Markus" <>
Cc: "" <>
References: <dee9854618dc46088972a34926c104c1@DCRIC1EXC03PA.mcp.local> <> <9d40f9ad4b494e67ba2808341dc82e4d@DCRIC1EXC03PA.mcp.local>
From: Robert Wilton <>
Message-ID: <>
Date: Tue, 11 Dec 2018 16:05:30 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3
MIME-Version: 1.0
In-Reply-To: <9d40f9ad4b494e67ba2808341dc82e4d@DCRIC1EXC03PA.mcp.local>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [netmod] [EXTERNAL] Re: Question on RFC8342 + RESTCONF extension (draft-ietf-netconf-nmda-restconf)
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: Tue, 11 Dec 2018 16:05:41 -0000

Hi Seehofer,

Please see inline ...

On 11/12/2018 14:55, Seehofer, Markus wrote:
> Hello Juergen,
> see my comments inline below. As being quite new to the topic, going through all the old and current RFCs and drafts is quite challenging.
> So please apologize for "simple" questions or ones maybe already raised.
> -----Ursprüngliche Nachricht-----
> Von: Juergen Schoenwaelder []
> Gesendet: Dienstag, 11. Dezember 2018 15:33
> An: Seehofer, Markus
> Cc:
> Betreff: [EXTERNAL] Re: [netmod] Question on RFC8342 + RESTCONF extension (draft-ietf-netconf-nmda-restconf)
> On Tue, Dec 11, 2018 at 02:17:07PM +0000, Seehofer, Markus wrote:
>> Hello,
>> Reading RFC 8342 along with draft-ietf-netconf-nmda-restconf-05 I've some questions or comprehension problems with the text.
>> 1.       RFC 8342 (NMDA)
>> Chapter 5.3.  The Operational State Datastore (<operational>) says:
>> "The operational state datastore (<operational>) is a read-only datastore ...."
>> Chapter 6.2. Invocation of Actions and RPCs says:
>> "Actions are always invoked in the context of the operational state datastore. The node for which the action is invoked MUST exist in the operational state datastore."
>> Chapter 3.1 in says:
>> "YANG actions can only be invoked in {+restconf}/ds/ietf-datastores:operational."
>> Question: How can one invoke an action in a as read-only defined datastore? Or am I missing something?
> Why do you expect that a datastore has to be writable in order to invoke an action? RFC 7950 has the example of a ping action tied to an interface. (You ping a remote system from that specific interface.) In general, actions are understood as being tied to real resources and hence to the operational datastore. (For example, you can't ping from an interface that is configured but not physically present.)
> [MSEE]: I do not expect that a datastore has to be writeable to invoke an action, but I do expect that a "read-only" datastore is not writeable and RFC 8342 says clearly operational state datastore is "read-only".

RPCs and actions don't modify the operational state datastore as such, 
instead they modify the properties of the underlying system, and the 
operational state datastore provides a read-only view onto the state of 
the system.  So <operational> is only being updated as a side effect of 
reflecting the changes to the underlying system.

This contrasts with writable configuration datastores (e.g. <candidate> 
or <running>), where the client can modify the configuration in those 
datastores directly which will then attempt to change the behavior of 
the system as the config is applied.

>> 2.       The NMDA is a huge step forward for NC and RC, thanks for that. NMDA in combination with the new RESTCONF extensions let one now select one of the named datastores
>> in RFC 8342. Reading the RFC and draft I'm still missing (or even more overlook I guess) the following. RFC 8040 Chapter 4.5 says:
>> "A PUT on the datastore resource is used to replace the entire
>> contents of the datastore...". So does this mean one can have the same behavior as in NETCONF where you can copy the "running" config to "startup" or "candidate" config to "running" if a RESTCONF server would support them? Is there any example how this would look like if it is allowed?
> A PUT does not really get you there, to copy a datastore to another you want an operation on the server.
> [MSEE]: Exactly this is what I want. NETCONF specifies this clearly in the RFCs with <copy-config> but how does one trigger this with RESTCONF? I had the hope with NMDA + RESTCONF extensions this would
>                 be possible too. Or do I still miss something?

I think that it is theoretically possible to invoke the NETCONF RPCs 
(e.g. the copy-config RPC defined in ietf-netconf.yang, RFC 6241) from 
RESTCONF (e.g. section 3.6 of RFC 8040).

Whether this is actually a good thing to do/encourage I'm not so sure.


>> 3.       Typo in Chapter 3.1 "the server would implement the resource {+restconf}/ds/example- ds-ephemeral:ds-ephemeral."
>> There is a space in between "example-" and "ds-ephemeral:ds-ephemeral".
> Lets hope we get this fixed with the help of the RFC editor.
> /js
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <>
> _______________________________________________
> netmod mailing list