[netconf] [Errata Rejected] RFC8040 (6271)

RFC Errata System <rfc-editor@rfc-editor.org> Fri, 12 January 2024 14:48 UTC

Return-Path: <wwwrun@rfcpa.amsl.com>
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 226EDC14F60A; Fri, 12 Jan 2024 06:48:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.659
X-Spam-Level:
X-Spam-Status: No, score=-6.659 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2vLfJrNErj4; Fri, 12 Jan 2024 06:47:56 -0800 (PST)
Received: from rfcpa.amsl.com (rfcpa.amsl.com [50.223.129.200]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49436C14CE2E; Fri, 12 Jan 2024 06:47:56 -0800 (PST)
Received: by rfcpa.amsl.com (Postfix, from userid 499) id 27E491B65DC9; Fri, 12 Jan 2024 06:47:56 -0800 (PST)
To: kent+ietf@watsen.net, andy@yumaworks.com, mbj@tail-f.com, kwatsen@juniper.net
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: rwilton@cisco.com, iesg@ietf.org, netconf@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20240112144756.27E491B65DC9@rfcpa.amsl.com>
Date: Fri, 12 Jan 2024 06:47:56 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/EJIyY_Ef6Nqkdt9_NxhP0Zwo3W8>
Subject: [netconf] [Errata Rejected] RFC8040 (6271)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 12 Jan 2024 14:48:00 -0000

The following errata report has been rejected for RFC8040,
"RESTCONF Protocol".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6271

--------------------------------------
Status: Rejected
Type: Technical

Reported by: Kent Watsen <kent+ietf@watsen.net>
Date Reported: 2020-09-01
Rejected by: Robert Wilton (IESG)

Section: 4.5

Original Text
-------------
   The "insert" (Section 4.8.5) and "point" (Section 4.8.6) query
   parameters MUST be supported by the PUT method for data resources.
   These parameters are only allowed if the list or leaf-list is
   "ordered-by user".


Corrected Text
--------------
   The "insert" (Section 4.8.5) and "point" (Section 4.8.6) query
   parameters MUST be supported by the PUT method for data resources.
   These parameters are only allowed if the target resource is a
   non-existent entry of an "ordered-by user" list or leaf-list.

Notes
-----
First, Section 3.5 (Data Resource) says that "list" and "leaf-leaf" are not a data resources:

  A data resource represents a YANG data node that is a descendant node
  of a datastore resource. Each YANG-defined data node can be uniquely
  targeted by the request-line of an HTTP method. Containers, leafs,
  leaf-list entries, list entries, anydata nodes, and anyxml nodes are
  data resources.

Second, these query parameters only make sense when targeting a non-existent entry.   If the entry does not exist, then PUT is being used like a POST: to create and place an item in an ordered list.  However, if the entry exists, then PUT is being used to both replace the contents and (presumably) re-place the order in the list; but this doesn't make sense because:

  1) "insert" defaults to "last".
  2) there is no "insert" value to indicate "keep existing placement".
  3) having to concoct valid "insert" and "point" values is hard.

Thus indiscriminate PUTs would move entries to the end, which can't be desired...
 --VERIFIER NOTES-- 
Replaced by errata 6277.

--------------------------------------
RFC8040 (draft-ietf-netconf-restconf-18)
--------------------------------------
Title               : RESTCONF Protocol
Publication Date    : January 2017
Author(s)           : A. Bierman, M. Bjorklund, K. Watsen
Category            : PROPOSED STANDARD
Source              : Network Configuration
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG