Re: [netconf] restconf collections

Qin Wu <> Sat, 26 September 2020 04:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0900E3A0FB5 for <>; Fri, 25 Sep 2020 21:30:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jmF7YfSyL8n6 for <>; Fri, 25 Sep 2020 21:30:13 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 343D83A0FB3 for <>; Fri, 25 Sep 2020 21:30:13 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id 6D2DEDC7B05FD9DE2E6A for <>; Sat, 26 Sep 2020 05:30:08 +0100 (IST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Sat, 26 Sep 2020 05:30:08 +0100
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Sat, 26 Sep 2020 05:30:07 +0100
Received: from ([]) by ([fe80::fca6:7568:4ee3:c776%31]) with mapi id 14.03.0487.000; Sat, 26 Sep 2020 12:30:02 +0800
From: Qin Wu <>
To: Andy Bierman <>, Kent Watsen <>
CC: "" <>
Thread-Topic: [netconf] restconf collections
Thread-Index: AdaTu7oM6Ull5jqeThCPAKA7zO9G3A==
Date: Sat, 26 Sep 2020 04:30:01 +0000
Message-ID: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAADA1006Edggeml511mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [netconf] restconf collections
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 26 Sep 2020 04:30:16 -0000

发件人: netconf [] 代表 Andy Bierman
发送时间: 2020年9月26日 1:22
收件人: Kent Watsen <>
主题: Re: [netconf] restconf collections

On Fri, Sep 25, 2020 at 9:56 AM Kent Watsen <<>> wrote:
Hi Andy,

This has been discussed a few times by the WG.

Perhaps a testament to it being a real problem?

The co-authors never agreed on the set of bells and whistles that should be supported.

True, but it's more like we lost interest / time to work on least that's my story!  ;)

There was an objection from Phil Shafer at the time that pagination was not needed
at all and handling large responses from the server was just a minor implementation detail.

Clearly Phil is in the rough, as many APIs support pagination for a reason.   Even if constraining the solution to networking gear, interfaces and logs may be numerous, and on-box cli/web UIs can only show a screen at a time...

Our customers agree with you.  Some of them only use our <get-bulk>, and stopped using <get> and <get-config>.
Since it is implemented as an RPC, all YANG-based protocols can use it.
Obviously you need XPath filtering (XSLT-style) to select the list entries of interest.
Count and depth and other parameters from <get> are also useful.

(My concern is that the IETF version will be too complex to implement or use as the feature list grows.)
[Qin]:That’s the issue we try to address in our customer’s scenarios. If the solution only focuses on list, the complexity is controllable. If the scope is not limited to list, XAPTH filtering and query actually provides a good solution to navigate from root node to leaf node.

IMO, it's okay if we don't support for CT-lists (i.e., interfaces).  As you write above, and I wrote in before, it seems like a nice-to-have.   FYI, I'm asking Per in a fork of this thread to justify if supporting CT-lists is a "must-have"...hopefully he'll come back with something compelling.

There is no extra complexity to support config vs. operational data.
I don't see the value in restricting the operation.

CF-lists, on the other hand, can be much so that trying to return all could exhaust server and/or client resources.   I think supporting CF-lists is a must-have.

The most significant objection was that this is a RESTCONF-only solution and that
was not acceptable to ignore NETCONF (since <get> and GET end being the same
in the end, so the problem also exists for NETCONF)

True.  If we can find a way to extend support to NETCONF, all the better.   Of course, the solutions would be wildly different, much like how NMDA had separate solutions for NC and RC (RFCs 8526 and 8527, respectively).  Perhaps Per or Martin can clue us into if they have a NC-equivalent solution?

It is easy. Use RPC operations which map to RESTCONF POST automatically.

[Qin]: Agree, NETCONF fragment provide an example on what RPC operations look like
which is similar to getbulk operation.

However, if NC-support cannot be achieved, then I don't think it means we don't do it for RC.   Much like NC supports somethings RC doesn't (e.g., confirmed commit), each protocol plays into its strengths.   So mote it be.