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

Martin Björklund <mbj+ietf@4668.se> Wed, 02 September 2020 19:57 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 7928C3A0EDA for <netconf@ietfa.amsl.com>; Wed, 2 Sep 2020 12:57:01 -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_H3=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=MumjCpjd; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=N1KGM7sr
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 HFhrbNh_Jtm9 for <netconf@ietfa.amsl.com>; Wed, 2 Sep 2020 12:56:59 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90F073A0EB5 for <netconf@ietf.org>; Wed, 2 Sep 2020 12:56:55 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id C80065C01B7; Wed, 2 Sep 2020 15:56:54 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 02 Sep 2020 15:56:54 -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= rdheuAnu8LL5kU+/Mxq/5vGI0mIO+Wkj524/r5Fiid8=; b=MumjCpjdzbxTU5N7 SNS52A89xj9Cmw0qf4zNyW5yc6T+iNNJs23W/chyaMSY63VXC0vMrtM7e014Yceq vgWRNZNcKNpOPadv9HL4Zq7/c2O2480UUb0kjTx66j47qz3xxjCcPrQpou23REel Nm7zaB4h30Uxw/buyWQfdFRRHZbWn8G3c12/WYv4y3WKVNyulwgHy2k71AK0vTyJ 4RriAsaJn89x1MDztMbRqvVNjtV7/YjHM0nocwHZizbowcA9ERXJu9jiNDDzDg9e eyK+t8J0hnMObNkzyV65XvyejRTlq75gmnNpVAkFgkhI6cljOFVT2gje8tdLH7qE QcodsA==
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=rdheuAnu8LL5kU+/Mxq/5vGI0mIO+Wkj524/r5Fii d8=; b=N1KGM7sr3fDtA8TbV6I8zMcWWCBENmrxO0LeRODG/u7JaeC5xE2h1NIkY 7DS0B8Jm5AuNK8Wp9No0HlQEacoCGCd6sHSdm8QVzOIwBGQYWDspiA3rg++zxgoy rJ+oA1mcz9yqAQlv5DCLaibyvlE4OP94VobdxRfkXsLGLGUZ2HxN9r1HPS4ta8Zd yP5J0+k1YdmS0owHe9B5RYZYOPiT/pb6cyJkc1VvffBZxSgLNzn1vtahTLp65/5j f91ajkmpIL482gzZe5n3S7VNyzOCJzQ6OPxjxE8M0GBYhsgKfxUPmmyY8yPUVXok s9yX0r1ytmknX9Uv+l6/Xx1AQ4HCg==
X-ME-Sender: <xms:BvlPXxkdecyutqKoYY2qAGMaDL5ESfrdoVS2Bc-ddeIoosge3egDRg> <xme:BvlPX831t6jCqeL1Qta_nqcZmByhJrKtO_Gobteu0E8F84V-H43R9dFCC-RE9DAR_ xPv307RD5ySWR1-Gn4>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudefledgudegfecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepfffkvffuhfgjfhfogggtgfesth gsredtredtjeenucfhrhhomhepofgrrhhtihhnuceujhpnrhhklhhunhguuceomhgsjhdo ihgvthhfseegieeikedrshgvqeenucggtffrrghtthgvrhhnpeejleekieeufefftdevud egueehteektdduleegkeeuteefjefgueelieejgfdtjeenucffohhmrghinheprhhftgdq vgguihhtohhrrdhorhhgnecukfhppeduheekrddujeegrdegrdeggeenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmsghjodhivghtfhesgeei ieekrdhsvg
X-ME-Proxy: <xmx:BvlPX3ouhnMqK4b82N2sKRxqdQ2O0Pi6SHxBOHbAvUNitACUdU8vdw> <xmx:BvlPXxnSPqe0zAIjrFxBPeZ-5GnlEVQaeI9MROg_7ATcIf8SkcL7ug> <xmx:BvlPX_2u0T851G1KcbZk5wyef1nji0ts6Pxdrx3Fh7E-B7GhF81SPg> <xmx:BvlPX__3yXRCuuFztetZvzGDR_hvChvReYFFHiOZoUGPA5aZQ0aaeA>
Received: from localhost (unknown [158.174.4.44]) by mail.messagingengine.com (Postfix) with ESMTPA id 12A14306005F; Wed, 2 Sep 2020 15:56:52 -0400 (EDT)
Date: Wed, 02 Sep 2020 21:56:51 +0200 (CEST)
Message-Id: <20200902.215651.2161361777301988365.id@4668.se>
To: kent+ietf@watsen.net
Cc: andy@yumaworks.com, mbj+ietf@4668.se, kwatsen@juniper.net, warren@kumari.net, rwilton@cisco.com, mjethanandani@gmail.com, netconf@ietf.org
From: Martin =?iso-8859-1?Q?Bj=F6rklund?= <mbj+ietf@4668.se>
In-Reply-To: <010001744fa1d4f9-c6c34f02-e5c6-4078-9244-c0bd567ae2a2-000000@email.amazonses.com>
References: <20200902.082718.1225293218517439729.id@4668.se> <CABCOCHRTsyju+3e1jUSTzFswpvG5KzARWyQXM_M8AukxJqPkZw@mail.gmail.com> <010001744fa1d4f9-c6c34f02-e5c6-4078-9244-c0bd567ae2a2-000000@email.amazonses.com>
X-Mailer: Mew version 6.8 on Emacs 26.3
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/eehSryZbBizSIcuKMV6lCO1UCQ8>
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 19:57:08 -0000

Kent Watsen <kent+ietf@watsen.net> wrote:
> [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.

This isn't quite correct (the target resource in POST is not a list
entry), and it isn't needed IMO.  The text in 4.8.5 and 4.8.6 says the
same thing already, so we don't need to say it here as well.  Esp. not
in an errata.

> 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.

Ok, but is the grammar correct "with exception to when..."?


>        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.

I prefer the old text over this.

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

Section 4.5 says:

   If the target resource represents a YANG leaf-list, then the PUT
   method MUST NOT change the value of the leaf-list instance.


/martin