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

Kent Watsen <kent+ietf@watsen.net> Wed, 02 September 2020 16:24 UTC

Return-Path: <010001744fa1d4f9-c6c34f02-e5c6-4078-9244-c0bd567ae2a2-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 893983A1281 for <netconf@ietfa.amsl.com>; Wed, 2 Sep 2020 09:24:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 8MWhn-DmCyFk for <netconf@ietfa.amsl.com>; Wed, 2 Sep 2020 09:24:03 -0700 (PDT)
Received: from a48-94.smtp-out.amazonses.com (a48-94.smtp-out.amazonses.com [54.240.48.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1A4A3A1254 for <netconf@ietf.org>; Wed, 2 Sep 2020 09:24:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1599063840; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=BZIgsxyt2pw/VT84KdJoChqT0O8jeLbhK5TmWaqj6Fk=; b=OH1MYlpM73RWroiNqHjHlU4YmN/Q2k7B6sb6KnfIMuKi9pNMqmYNrUE29AClcNvc gaYw/Vg453X4jniy1hkxPxGu+lXGAuT08w7ev6OjqvLioX0u3lcux7Kbk+zMe7PotUj nEVvcK5eAgQ7HDU3elm8eJKd+voqBpUHyWWsaXi4=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <010001744fa1d4f9-c6c34f02-e5c6-4078-9244-c0bd567ae2a2-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7499ECD7-36FB-47C5-A4B0-7B4AB60793A6"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Wed, 2 Sep 2020 16:24:00 +0000
In-Reply-To: <CABCOCHRTsyju+3e1jUSTzFswpvG5KzARWyQXM_M8AukxJqPkZw@mail.gmail.com>
Cc: =?utf-8?Q?Martin_Bj=C3=B6rklund?= <mbj+ietf@4668.se>, Kent Watsen <kwatsen@juniper.net>, Warren Kumari <warren@kumari.net>, Robert Wilton <rwilton@cisco.com>, Mahesh Jethanandani <mjethanandani@gmail.com>, "netconf@ietf.org" <netconf@ietf.org>
To: Andy Bierman <andy@yumaworks.com>
References: <20200901173726.8E404F40785@rfc-editor.org> <20200902.082718.1225293218517439729.id@4668.se> <CABCOCHRTsyju+3e1jUSTzFswpvG5KzARWyQXM_M8AukxJqPkZw@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-SES-Outgoing: 2020.09.02-54.240.48.94
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/znJowDyibNpiNPMDFA7HeOgRiws>
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 16:24:05 -0000

[removing RFC Editor]

> RFC Errata System <rfc-editor@rfc-editor.org <mailto: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 <https://www.rfc-editor.org/errata/eid6271>
> > 
> > --------------------------------------
> > Type: Technical
> > Reported by: Kent Watsen <kent+ietf@watsen.net <mailto:kent%2Bietf@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.
> 
> 
> 
> 
> Agreed.  So the errata only applies to the  "insert" query parameter.

We can cancel and resubmit errata as needed.

I think there might be two Errata:

1) for the r/list/list entry/ fix

    NEWER:
        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 an
        entry of an "ordered-by user" list or leaf-list.

2) for the “insert” query parameter

    In Section 4.8.5: The "insert" Query Parameter

    OLD:

       The default value is "last".

       This parameter is only supported for the POST and PUT methods.  It is
       also only supported if the target resource is a data resource, and
       that data represents a YANG list or leaf-list that is
       "ordered-by user”.

    NEW:

       The default value is “last”, with exception to when used with PUT
       and the target resource already exists, in which case the default
       is to replace the target resource without altering its position in the
       "ordered-by user” list or leaf-list.

       This parameter is only supported for the POST and PUT methods.
       It is also only supported if the target resource is a data resource 
       that is an entry of an "ordered-by user" list or leaf-list.

Thoughts?

Separately, but related, is it possible to PUT on an "ordered-by user” leaf-list?   Presumably, the operation changes the implicit “key” field...


K.