Re: [netconf] restconf collections

Kent Watsen <> Fri, 25 September 2020 16:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4C7DE3A0FEB for <>; Fri, 25 Sep 2020 09:56:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] 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 KT2vOAjNczZJ for <>; Fri, 25 Sep 2020 09:56:33 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DD3673A0FF2 for <>; Fri, 25 Sep 2020 09:56:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono;; t=1601052991; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=uUFPDzeqWQIv2XyN/dDZ5ERK80TRljAMQaXOiLi/ESw=; b=jb5DYPAomK8wRJhHHOaJU4BS1XWC+3T13jTtTHrDlko/6v6MFI7SC7xqMIoGTS7J lGkShF6msuU/3oUUBwgqEsXzRW/DCqoLI5hbrBvnvasSONIlyhJfPXoh7SYrRR1Ppmr 0MHplYUIQK0+ma1V5zNrbzdCIUxDSMKv1u3z62SI=
From: Kent Watsen <>
Message-ID: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_1CAA350F-2E28-4390-902B-4A12C3FD5E6A"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Fri, 25 Sep 2020 16:56:31 +0000
In-Reply-To: <>
Cc: "" <>
To: Andy Bierman <>
References: <> <>
X-Mailer: Apple Mail (2.3608.
X-SES-Outgoing: 2020.09.25-
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: Fri, 25 Sep 2020 16:56:34 -0000

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...

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.

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?

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.

> Andy