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 (CEST)
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 =?iso-8859-1?Q?Bj=F6rklund?= <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