Re: [netconf] [Technical Errata Reported] RFC8040 (6271)
Martin Björklund <mbj+ietf@4668.se> Wed, 02 September 2020 06:27 UTC
Return-Path: <mbj+ietf@4668.se>
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 10FD73A0DAE for <netconf@ietfa.amsl.com>; Tue, 1 Sep 2020 23:27:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.616
X-Spam-Level:
X-Spam-Status: No, score=-0.616 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_NAKED_TO_NUMERO=1.482, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=xUTh1O42; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MJOPi45W
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 8CL02XYaS1xk for <netconf@ietfa.amsl.com>; Tue, 1 Sep 2020 23:27:22 -0700 (PDT)
Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B33E03A0DAB for <netconf@ietf.org>; Tue, 1 Sep 2020 23:27:22 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 801BDDDC; Wed, 2 Sep 2020 02:27:21 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 02 Sep 2020 02:27:22 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=date :message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm2; bh= zPZkmwSYiRKBwJ5Js9/dkwb+x+e3HLJNgslcd+5Bbw0=; b=xUTh1O420/Nlpwh9 6QQ43yvuVhTISt/1GMyRI0cq3RY8bEy91RaOQFSGDRvm0YbYFy/Tqmd4QizfBJPT dFymacpv2r9wsY3NjD3UYtCFa2NtjxA8JWfM7vL6Xr5iWgu6mPmRwqJ+TPHGR+wS lr5WYzvc7SeqlbVakBthgJpED+NopQqxBKAxNyXzAKUn2sl2Vz2EL/ECV83ZMURO nZW/Qvd0sHgoFDuAhFYWBjwhRO6LpXo4xKOsU6QolC4lHhQxRyMcanQusOiW6k1U Z0+/AZAMp5ruE3lHBQMpRv3jCYA33tAnXEzyB8Qeng5xeIC0v5yqwceAm1Pr6Ajs jQ077Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=zPZkmwSYiRKBwJ5Js9/dkwb+x+e3HLJNgslcd+5Bb w0=; b=MJOPi45WPjuPD2kFHp/Wsq8BN1tqcpwFKaP7ftKwBPJPlYGMqGF9q9hC5 PePjMcr0IDN4i/qQYS0BBls6VVPXjZX4JnKs0QLGUxHdF0PWM4lQyYgIrp7EFTJ3 KUt5NqCGDyxjGdMTtWTI2X/25bvRowI4FvlW+YushtTUIc37r1VFXJ1pygwS7DZN DoZ0tPEznexjijtht5Htpg6T0LvGyLLMYTVyInvfpo7va+lP6qO0TyNTRd0IjmYP mwP4OBsZfsjRwjW45l08vnLg8omnZiZPXUweJ72/jUaCAesPEv+wwcK5rTIHdlx+ 4x3QqqH3KlQPNFisGzomg6lbDutEg==
X-ME-Sender: <xms:SDtPX4zFIeJQ3LHNwVIL7WcmJZ-6N2q7Ku4uQJ-_5zmY0c7gK6i5gQ> <xme:SDtPX8QA42xXz8jpOYJl_3xbi9J6GcSRV8CcpjLu50POu-aoDC3qm6h0RvnZXDQ-d J9JPTmZN-5PQQobu_M>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudefkedguddtkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepfffkvffuhfgjfhfogggtgfesth ejredtredtvdenucfhrhhomhepofgrrhhtihhnuceujhpnrhhklhhunhguuceomhgsjhdo ihgvthhfseegieeikedrshgvqeenucggtffrrghtthgvrhhnpeeufeffudegveffhedtud ekledvgffffedugfethfegieevtddtvdefteefffefjeenucffohhmrghinheprhhftgdq vgguihhtohhrrdhorhhgpdhivghtfhdrohhrghenucfkphepudehkedrudejgedrgedrge egnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgs jhdoihgvthhfseegieeikedrshgv
X-ME-Proxy: <xmx:SDtPX6XDZ_NmwgVFHE_siop1gxD3lpjTSCXkcGxVMiMjB6tMV7xFtg> <xmx:SDtPX2j385OojrXmqdO9x2pufcUncnS_UQFf-mIMKke9TZEdeTbuYQ> <xmx:SDtPX6CLS6-7bMKPV1rNjz2A1NyOynshbQiMtLEbXFLFOWZNIqPmrw> <xmx:STtPXx5MDmMdt1iaOup8Rc3yWcmSCG5eAgposoPr-zbBECOy_0dyMg>
Received: from localhost (unknown [158.174.4.44]) by mail.messagingengine.com (Postfix) with ESMTPA id 5F704306005E; Wed, 2 Sep 2020 02:27:19 -0400 (EDT)
Date: Wed, 02 Sep 2020 08:27:18 +0200
Message-Id: <20200902.082718.1225293218517439729.id@4668.se>
To: rfc-editor@rfc-editor.org
Cc: andy@yumaworks.com, kwatsen@juniper.net, warren@kumari.net, rwilton@cisco.com, kent+ietf@watsen.net, mjethanandani@gmail.com, netconf@ietf.org
From: Martin Björklund <mbj+ietf@4668.se>
In-Reply-To: <20200901173726.8E404F40785@rfc-editor.org>
References: <20200901173726.8E404F40785@rfc-editor.org>
X-Mailer: Mew version 6.8 on Emacs 26.3
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/F-bpOscBsD-2Pjh471NVaTkogmc>
Subject: Re: [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: Wed, 02 Sep 2020 06:27:24 -0000
Hi, RFC Errata System <rfc-editor@rfc-editor.org> wrote: > 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. I don't think this is correct. The new text makes it impossible to move an existing ordered-by user list entry, which should be possible. 4.8.6 says: The "point" query parameter is used to specify the insertion point for a data resource that is being created or moved within an "ordered-by user" list or leaf-list. See below. > 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". I think this is the real problem. It should be (and the intention was): 1. if "insert" isn't present and a new entry is created, the new entry will be appended to the end of the list. 2. if "insert" isn't present a an entry is modified (PUT), the entry keeps its place in the list. /martin > 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 mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf
- [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