Re: [netconf] [Technical Errata Reported] RFC8040 (6342)

Kent Watsen <> Mon, 23 November 2020 17:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EEB043A08C5 for <>; Mon, 23 Nov 2020 09:27:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.017
X-Spam-Status: No, score=-0.017 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 jrjzSOQOfORf for <>; Mon, 23 Nov 2020 09:27:41 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E69AB3A08C0 for <>; Mon, 23 Nov 2020 09:27:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono;; t=1606152459; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=fjS0YxsI9Fx+c3AoNHe77w0CuYwhAmX4VOctxNUfuPs=; b=g3og0ysm3r2KHyBWu4pEv9fQde9R02qEMgq8GZd1f1/iE81yGSLUS60l+JN5M3KH 6PYx4gv3qRAaKi7vAKe9Zpm+LIF1r6nZNrspXsSgx66yNxTBAg0Qrgot+dLgOyzvsSK 2czzISqyD/V0YEYWX6rTqWAWKaB3nAlK4Uuy3Vuc=
From: Kent Watsen <>
Message-ID: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_CEE4CA96-64C8-45E9-A743-F6DEA05E3612"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Mon, 23 Nov 2020 17:27:39 +0000
In-Reply-To: <>
Cc: =?utf-8?Q?Martin_Bj=C3=B6rklund?= <>, RFC Editor <>, "" <>
To: Andy Bierman <>
References: <> <> <> <> <>
X-Mailer: Apple Mail (2.3608.
X-SES-Outgoing: 2020.11.23-
Archived-At: <>
Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6342)
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: Mon, 23 Nov 2020 17:27:42 -0000

+1 on rejecting the errata.  PUT replaces the resource, PATCH modifies it.

Any node not present in a PUT representation is assumed to be deleted, but it is not allowed to delete keys, hence why keys MUST always to present in a PUT.

> Although we have several customers that would like to rename list entries,
> and sometimes think RESTCONF allows it.  I do not think any YANG-based protocol
> allows list keys to be modified.  You have to delete and re-create the list entry.
> I think this is something for YANG-next to consider, so it is done consistently across
> all protocols.

YANG-next or RESTCONF-next?

I think that it is unique to RESTCONF since only RC (not considering COAP) targets specific resources.

That said, the feature might be something that could be added via an I-D, as opposed to an 8440-bis.