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

"Seehofer, Markus" <Markus.Seehofer@belden.com> Tue, 11 December 2018 17:11 UTC

Return-Path: <prvs=2883d11db5=markus.seehofer@belden.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 73D91130EA1 for <netmod@ietfa.amsl.com>; Tue, 11 Dec 2018 09:11:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 fLW0YXLM8XJ8 for <netmod@ietfa.amsl.com>; Tue, 11 Dec 2018 09:11:19 -0800 (PST)
Received: from mail3.belden.com (mail3.belden.com [12.168.192.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 271BC130E9E for <netmod@ietf.org>; Tue, 11 Dec 2018 09:11:19 -0800 (PST)
Received: from pps.filterd (dcric1ppa03pa.mcp.local [127.0.0.1]) by dcric1ppa03pa.mcp.local (8.16.0.22/8.16.0.22) with SMTP id wBBH7LIw026967; Tue, 11 Dec 2018 12:11:18 -0500
Received: from dcric1exc01pa.mcp.local (dcric1exc01pa.mcp.local [10.10.181.21]) by dcric1ppa03pa.mcp.local with ESMTP id 2pag538e2k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 11 Dec 2018 12:11:17 -0500
Received: from DCRIC1EXC03PA.mcp.local (10.10.181.23) by DCRIC1EXC01PA.mcp.local (10.10.181.21) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 11 Dec 2018 12:11:17 -0500
Received: from DCRIC1EXC03PA.mcp.local ([172.16.254.23]) by DCRIC1EXC03PA.mcp.local ([172.16.254.23]) with mapi id 15.00.1367.000; Tue, 11 Dec 2018 12:11:17 -0500
From: "Seehofer, Markus" <Markus.Seehofer@belden.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
CC: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [EXTERNAL] Re: [netmod] Question on RFC8342 + RESTCONF extension (draft-ietf-netconf-nmda-restconf)
Thread-Index: AdSRW5qHNYi/eHfrTieT+mUbUnzcbQALMCKAAAo1hoD//8q0gIAAS0Xg
Date: Tue, 11 Dec 2018 17:11:16 +0000
Message-ID: <5527d148dc3d4a9996a1e2298537105f@DCRIC1EXC03PA.mcp.local>
References: <dee9854618dc46088972a34926c104c1@DCRIC1EXC03PA.mcp.local> <20181211143313.xouvshwdtakmkdz4@anna.jacobs.jacobs-university.de> <9d40f9ad4b494e67ba2808341dc82e4d@DCRIC1EXC03PA.mcp.local> <20181211161447.2pvfug5q6z3iqvam@anna.jacobs.jacobs-university.de>
In-Reply-To: <20181211161447.2pvfug5q6z3iqvam@anna.jacobs.jacobs-university.de>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [46.5.19.128]
x-c2processedorg: 157cf0a0-3349-4636-89a5-bb6917ccdf3c
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-12-11_05:, , signatures=0
Content-Type: text/plain; charset="iso-8859-1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/FWIke-r8jzNWaxs7PYUZMUtDnks>
Subject: Re: [netmod] Question on RFC8342 + RESTCONF extension (draft-ietf-netconf-nmda-restconf)
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: Tue, 11 Dec 2018 17:11:21 -0000

Hello Juergen,

comments inline below.

-----Ursprüngliche Nachricht-----
Von: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] 
Gesendet: Dienstag, 11. Dezember 2018 17:15
An: Seehofer, Markus
Cc: netmod@ietf.org
Betreff: Re: [EXTERNAL] Re: [netmod] Question on RFC8342 + RESTCONF extension (draft-ietf-netconf-nmda-restconf)

On Tue, Dec 11, 2018 at 02:55:10PM +0000, 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.
> 
> > 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."
> >
> > "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".
>

Is your question 'how do I do actuall invoke an operation/action'?
Well, RFC 8040 talks about 'operation resource' and that you POST to them. What NMDA RESTCONF I think says is that such an invocation is executed in the context of the operational state datastore.

[MSEE]: No I guess I understood how to invoke an operation/action but I'm stuck with the following statements:
               - draft-ietf-netconf-nmda-restconf-05 says in Chapter 3.1: "YANG actions can only be invoked in {+restconf}/ds/ietf-datastores:operational" with
                  "The resource {+restconf}/ds/ietf-datastores:operational refers to the operational state datastore" and "The operational state datastore (<operational>) is a read-only datastore"
               - RFC 8040 says in Chapter 3.6 " Operation resources representing YANG actions are not identified in this subtree, since they are invoked using a URI within the '{+restconf}/data' subtree" and
                 "An action is invoked as: POST {+restconf}/data/<data-resource-identifier>/<action>"

               So without NMDA it was clear, invoke an action using {+restconf}/data}. With NMDA what is the correct way to trigger an action as the draft says "YANG actions can only be invoked in {+restconf}/ds/ietf-datastores:operational"?
              
> > 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 this was discussed at some point but then dropped. It may work to implement ietf-netconf (or the copy-config defined in there) to get direct access to NETCONF operations.

[MSEE]: Thanks, this could work. Haven't thought about that.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-2Duniversity.de_&d=DwIBAg&c=Bg5XULDZR8GiOSSWNlpkCsRePnGDkKcI6oYL9xv1MnQ&r=2XEKVYkQjmLHi2TOJp1VSzieLZVqewIpj-RxmRgPfsM&m=iyd1IgmqNVNO9Nlyjn_0i4tRy8l_6sfEwqtRJvqEtPA&s=TFP1iqry2-5IRNGuTpQGZ_O4zo3yvwU823NqKOPSSZ0&e=>

**********************************************************************
DISCLAIMER:
Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You.