[netconf] [Technical Errata Reported] RFC8040 (6271)
RFC Errata System <rfc-editor@rfc-editor.org> Tue, 01 September 2020 17:37 UTC
Return-Path: <wwwrun@rfc-editor.org>
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 8AF953A0CCD for <netconf@ietfa.amsl.com>; Tue, 1 Sep 2020 10:37:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 tK7bLHFsNECw for <netconf@ietfa.amsl.com>; Tue, 1 Sep 2020 10:37:38 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F1743A0CCC for <netconf@ietf.org>; Tue, 1 Sep 2020 10:37:38 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 8E404F40785; Tue, 1 Sep 2020 10:37:26 -0700 (PDT)
To: andy@yumaworks.com, mbj@tail-f.com, kwatsen@juniper.net, warren@kumari.net, rwilton@cisco.com, kent+ietf@watsen.net, mjethanandani@gmail.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: kent+ietf@watsen.net, netconf@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20200901173726.8E404F40785@rfc-editor.org>
Date: Tue, 01 Sep 2020 10:37:26 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/C9FNeOVJrWR1x5Qkj4l-y3a8g8s>
Subject: [netconf] [Technical Errata Reported] RFC8040 (6271)
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: Tue, 01 Sep 2020 17:37:40 -0000
The following errata report has been submitted for RFC8040, "RESTCONF Protocol". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6271 -------------------------------------- Type: Technical Reported by: Kent Watsen <kent+ietf@watsen.net> 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... Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- 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
- [netconf] [Technical Errata Reported] RFC8040 (62… RFC Errata System
- Re: [netconf] [Technical Errata Reported] RFC8040… Andy Bierman
- Re: [netconf] [Technical Errata Reported] RFC8040… Kent Watsen
- Re: [netconf] [Technical Errata Reported] RFC8040… Martin Björklund
- Re: [netconf] [Technical Errata Reported] RFC8040… Andy Bierman
- Re: [netconf] [Technical Errata Reported] RFC8040… Kent Watsen
- Re: [netconf] [Technical Errata Reported] RFC8040… Martin Björklund
- Re: [netconf] [Technical Errata Reported] RFC8040… Kent Watsen
- Re: [netconf] [Technical Errata Reported] RFC8040… Kent Watsen
- Re: [netconf] [Technical Errata Reported] RFC8040… Kent Watsen
- Re: [netconf] [Technical Errata Reported] RFC8040… Martin Björklund
- Re: [netconf] [Technical Errata Reported] RFC8040… Kent Watsen