IETF Logo Mail Archive

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

Kent Watsen <kent@watsen.net> Mon, 23 November 2020 17:27 UTC

Return-Path: <01000175f62594b1-4d3a5350-4f4d-43c3-9b8c-22fe14d0b36b-000000@amazonses.watsen.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEB043A08C5 for <netconf@ietfa.amsl.com>; Mon, 23 Nov 2020 09:27:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.017
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com
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 jrjzSOQOfORf for <netconf@ietfa.amsl.com>; Mon, 23 Nov 2020 09:27:41 -0800 (PST)
Received: from a48-110.smtp-out.amazonses.com (a48-110.smtp-out.amazonses.com [54.240.48.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E69AB3A08C0 for <netconf@ietf.org>; Mon, 23 Nov 2020 09:27:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; 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 <kent@watsen.net>
Message-ID: <01000175f62594b1-4d3a5350-4f4d-43c3-9b8c-22fe14d0b36b-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_CEE4CA96-64C8-45E9-A743-F6DEA05E3612"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 23 Nov 2020 17:27:39 +0000
In-Reply-To: <CABCOCHSH=sYTK6xsGu-jiE3SWUjRujJ=koh=gein78G-rU=SgQ@mail.gmail.com>
Cc: Martin Björklund <mbj+ietf@4668.se>, RFC Editor <rfc-editor@rfc-editor.org>, "netconf@ietf.org" <netconf@ietf.org>
To: Andy Bierman <andy@yumaworks.com>
References: <20201123.131452.2154616412508504559.id@4668.se> <AM0PR0302MB33480674E3CAB4D8AB4DCBB5F9FC0@AM0PR0302MB3348.eurprd03.prod.outlook.com> <AM0PR0302MB334833C570C323DA7E3AEE7AF9FC0@AM0PR0302MB3348.eurprd03.prod.outlook.com> <20201123.143840.1300967807479051474.id@4668.se> <CABCOCHSH=sYTK6xsGu-jiE3SWUjRujJ=koh=gein78G-rU=SgQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-SES-Outgoing: 2020.11.23-54.240.48.110
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/5UPXfcoH5kWqwxSTv_1Bp7nes7Y>
Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6342)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=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.

K.

v2.23.0 | Report a Bug | By Email