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

Martin Björklund <mbj+ietf@4668.se> Mon, 23 November 2020 13:38 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 99DB23A0B0D for <netconf@ietfa.amsl.com>; Mon, 23 Nov 2020 05:38:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.779
X-Spam-Level: *
X-Spam-Status: No, score=1.779 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_NAKED_TO_NUMERO=1.999, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=WRfE7d3m; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=G+ML5tJM
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 dkhoM_PsKsgS for <netconf@ietfa.amsl.com>; Mon, 23 Nov 2020 05:38:43 -0800 (PST)
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 C776E3A0B0B for <netconf@ietf.org>; Mon, 23 Nov 2020 05:38:43 -0800 (PST)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 0E3B15C014B; Mon, 23 Nov 2020 08:38:43 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Mon, 23 Nov 2020 08:38:43 -0500
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=fm3; bh= q5aqbz0b1qJxJkKb7Es0JrmvGyq0/GKJ2C36iw1uuIM=; b=WRfE7d3maA9p2sL1 VyHpPJQ77Y7etenTPf4/fOkmsJ5cGqvajvupdUl0CppGOphuqg8VzS6JJtkJ/Etn 7zyl6zzqvCTkpVRl+mnZrIW+GhN9cQp14Zg5FbHDXcHgxSIw+qou+e/vLbT113An ADT81SzkI0w9ATNAEWw29oe7HRSLDcEmibinj2YClRG5+LcqHSWy8nplBZj+hMnN dtdsgq59QYJtFYN44VK4onJm+fc5voItZ5qg/MLkdnjv+/RKJpuHr4ydSQzmQMRk 6+TeUXLhih7WYLPm4tZ2PujxI3rO6BUXljA0Fe+/ahdxDGam1tvHOv4TmaNRC7Lj v4fa3Q==
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=fm1; bh=q5aqbz0b1qJxJkKb7Es0JrmvGyq0/GKJ2C36iw1uu IM=; b=G+ML5tJMxNzmQNUOTBxmEYn26KLCgCS+Ul+egm8c6sfgmgyqNA1Tuwkjm W+FAq2l5s6BmQLfFPheEfZ3cwcmps91/DHc8b9yJpzjr38hnEiz9NvRUqQeR5Kof GpDAxul8FEeTVpECI4aI0VKWxeI43XUE12q52rouVptyT5DY+iesjBd7eubbZwOc 4Iq9OQTlhV0hM4rd+d7j9XV1Tlvh+qL6J6R8X/YFSnrpH9IwgjK+j0Kqe2qbgZMm 5y/C9i581IaZ3p0jB51gR+9EiDwVsKvG73IZbRNv/yKZjJ5gonW3voYwzD2xl5yT u93pmbyXIduYKUCDChJOOg4MBNPhg==
X-ME-Sender: <xms:Yru7X8gG-nkHJkU52egnATZKrKcum178R7aoB0wphoumeiyZtN07VA> <xme:Yru7X1Cv4okrsD9Lx7pgpSKyHM2veMr5ebuF0ZFsigiYN0qTZi4RmqT0Eo-MD-jun rriVjs3pty7OJ7Z2-g>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudegiedgheehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffkffvuffhjghfofggtgfgsehtqh ertdertddunecuhfhrohhmpeforghrthhinhcuuehjnphrkhhluhhnugcuoehmsghjodhi vghtfhesgeeiieekrdhsvgeqnecuggftrfgrthhtvghrnhepieehtedvteetjeekgfffgf dtteevudeileetheeghffhieeuvdeijeegheethfehnecuffhomhgrihhnpeduhhhoshht vgigrghmphhlvgdrtghomhenucfkphepudehkedrudejgedrgedrvdduheenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmsghjodhivghtfhes geeiieekrdhsvg
X-ME-Proxy: <xmx:Yru7X0HdJlTpNi5aTeW3DBKajLZeF8FYQwtApVVnCsqrmHqlEWTLaA> <xmx:Yru7X9QGJFoXtIYpGqqZAkFS7P7JwNLjK9n7rZ_4geqpCvpIh_SWJQ> <xmx:Yru7X5wkLR8_pKcihUEsNnsxD2UHi_ifpFZUXblIrJc89EhuwnxQdg> <xmx:Y7u7X6qY3cLnYJLiRr3PYBEKNpr_p1MwFalW0UX4taQYP6tT3yJZ3A>
Received: from localhost (unknown [158.174.4.215]) by mail.messagingengine.com (Postfix) with ESMTPA id B87E33280059; Mon, 23 Nov 2020 08:38:41 -0500 (EST)
Date: Mon, 23 Nov 2020 14:38:40 +0100 (CET)
Message-Id: <20201123.143840.1300967807479051474.id@4668.se>
To: muly_i@rad.com
Cc: rfc-editor@rfc-editor.org, kent+ietf@watsen.net, netconf@ietf.org
From: Martin =?iso-8859-1?Q?Bj=F6rklund?= <mbj+ietf@4668.se>
In-Reply-To: <AM0PR0302MB334833C570C323DA7E3AEE7AF9FC0@AM0PR0302MB3348.eurprd03.prod.outlook.com>
References: <20201123.131452.2154616412508504559.id@4668.se> <AM0PR0302MB33480674E3CAB4D8AB4DCBB5F9FC0@AM0PR0302MB3348.eurprd03.prod.outlook.com> <AM0PR0302MB334833C570C323DA7E3AEE7AF9FC0@AM0PR0302MB3348.eurprd03.prod.outlook.com>
X-Mailer: Mew version 6.8 on Emacs 26.3
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/sE4S-6rDCAfMmdMC7xP4ia5Y8iA>
Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6342)
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: Mon, 23 Nov 2020 13:38:46 -0000

Muly Ilan <muly_i@rad.com> wrote:
> Hi Martin,
> 
> Putting aside the similarity or not between plain PATCH and PUT, there's another example of inconsistency with plain PATCH in the RFC.
> 
> Please check the plain PATCH example in appendix B.2.5. " Edit a Data Resource".
> This example has keys both in the message header and message body.
> 
> This means that either the example in 4.6.1 or the example in B.2.5 should be modified. 

No, different examples can show different things.

> Section 4.6.1 includes the following text:
> "
> If the target resource represents a YANG list instance, then the key
> leaf values, in message-body representation, MUST be the same as the
> key leaf values in the request URI.
> "
> 
> If keys are not needed in the message body so this "warning text" is not needed either.

It is needed, since keys are *allowed*.  *If* the keys are present,
they MUST match the existing keys.


/martin


> 
> Moreover, since the above "warning text" is part of the RFC, it suggests to me that the RFC assumes that there are keys in both header URI and body.  
> 
> 
> Best,
> 
> Muly
> 
> -----Original Message-----
> From: Muly Ilan 
> Sent: 23/11/2020 14:26
> To: Martin Björklund <mbj+ietf@4668.se>
> Cc: rfc-editor@rfc-editor.org; kent+ietf@watsen.net; netconf@ietf.org
> Subject: RE: [netconf] [Technical Errata Reported] RFC8040 (6342)
> 
> Hi Martin,
> 
> Plain PATCH is defined as a merge operation i.e. it can create a resource.
> It's not limited to editing of existing resources.
> 
> From section 4.6.1:
> " The plain patch mechanism merges the contents of the message-body with the target resource."
> 
> " Plain patch can be used to create or update, but not delete, a child resource within the target resource."
> 
> It's better to have consistent examples.
> I suggest either to modify the plain PATCH example or the PUT example.
> 
> 
> Best,
> 
> Muly
> 
> 
> -----Original Message-----
> From: Martin Björklund [mailto:mbj+ietf@4668.se]
> Sent: 23/11/2020 14:15
> To: Muly Ilan <muly_i@rad.com>
> Cc: rfc-editor@rfc-editor.org; kent+ietf@watsen.net; netconf@ietf.org
> Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6342)
> 
> Hi,
> 
> Muly Ilan <muly_i@rad.com> wrote:
> > Hi,
> > 
> > If list keys are not required in message body for plain PATCH then 
> > they are also not required for the PUT method.
> 
> You are right that the keys are redundant also in PUT.  However, PUT means completely replace or create the resource, but plain PATCH modifies only the given fields.
> 
> 
> /martin
> 
> 
> > But the example for PUT in section 4.5 is:
> > 
> > PUT /restconf/data/example-jukebox:jukebox/\
> > library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1
> > Host: example.com
> > Content-Type: application/yang-data+json { "example-jukebox:album" : [ 
> > { "name" : "Wasting Light", "genre" : "example-jukebox:alternative", 
> > "year" : 2011 } ] }
> > 
> > So, do we want consistency between PUT and plain PATCH?
> > 
> > I believe consistency is important and currently the RFC contains two 
> > inconsistent examples.
> > 
> > 
> > Best,
> > 
> > Muly
> > 
> > 
> > -----Original Message-----
> > From: netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Martin 
> > Bj?rklund
> > Sent: 23/11/2020 10:37
> > To: rfc-editor@rfc-editor.org
> > Cc: kwatsen@juniper.net; netconf@ietf.org
> > Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6342)
> > 
> > Hi,
> > 
> > The issue boils down to if list keys are required in a plain patch.
> > Unfortunately, the RFC doesn't specifucy this.  From a technical pow, 
> > list keys are not necessary.  In fact, if they are present in the 
> > payload, they are redundant (since they are part of the URL) (this is 
> > actually mentioned in the RFC).
> > 
> > Since it isn't clearly specified, I think we must assume that the keys 
> > are not required.  Hence I think that this errata should be rejected.
> > 
> > In a future version of this document, the behaviour should be 
> > clarified.
> > 
> > 
> > /martin
> > 
> > 
> > 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > > rfc-editor.org%2Ferrata%2Feid6342&amp;data=04%7C01%7Cmuly_i%40rad.co
> > > m%
> > > 7Cf7ffd30dde054f875cc608d88f8b0eed%7Cf9047108cc2c4e4897a343fad1b3bf9
> > > d%
> > > 7C1%7C0%7C637417174712193376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
> > > wM
> > > DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=2
> > > nm
> > > LthW5HkwRvJZi%2F2Pj6%2B9qkLV9gV55wiBpIoiC%2FD4%3D&amp;reserved=0
> > > 
> > > --------------------------------------
> > > Type: Technical
> > > Reported by: Muly Ilan <muly_i@rad.com>
> > > 
> > > Section: 4.6.1
> > > 
> > > Original Text
> > > -------------
> > > To replace just the "year" field in the "album" resource (instead of 
> > > replacing the entire resource with the PUT method), the client might 
> > > send a plain patch as follows:
> > > PATCH /restconf/data/example-jukebox:jukebox/\
> > > library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1
> > > Host: example.com
> > > If-Match: "b8389233a4c"
> > > Content-Type: application/yang-data+xml <album
> > > xmlns="https://eur01.safelinks.protection.outlook.com/?url=http%3A%2
> > > F%25
> > > 2Fexample.com%2Fns%2Fexample-jukebox&amp;data=04%7C01%7Cmuly_i%40rad
> > > .c
> > > om%7Cf7ffd30dde054f875cc608d88f8b0eed%7Cf9047108cc2c4e4897a343fad1b3
> > > bf
> > > 9d%7C1%7C0%7C637417174712193376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w
> > > Lj
> > > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdat
> > > a= hxW6LA8t%2BNRka2GGRqRNsTnK2itYH1rRLnOxU7JbNlc%3D&amp;reserved=0">
> > > <year>2011</year>
> > > </album>
> > > 
> > > Corrected Text
> > > --------------
> > > To replace just the "year" field in the "album" resource (instead of 
> > > replacing the entire resource with the PUT method), the client might 
> > > send a plain patch as follows:
> > > PATCH /restconf/data/example-jukebox:jukebox/\
> > > library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1
> > > Host: example.com
> > > If-Match: "b8389233a4c"
> > > Content-Type: application/yang-data+xml <album
> > > xmlns="https://eur01.safelinks.protection.outlook.com/?url=http%3A%2
> > > F%25
> > > 2Fexample.com%2Fns%2Fexample-jukebox&amp;data=04%7C01%7Cmuly_i%40rad
> > > .c
> > > om%7Cf7ffd30dde054f875cc608d88f8b0eed%7Cf9047108cc2c4e4897a343fad1b3
> > > bf
> > > 9d%7C1%7C0%7C637417174712193376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w
> > > Lj
> > > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdat
> > > a= hxW6LA8t%2BNRka2GGRqRNsTnK2itYH1rRLnOxU7JbNlc%3D&amp;reserved=0">
> > > <name>Wasting Light</name>
> > > <year>2011</year>
> > > </album>
> > > 
> > > Notes
> > > -----
> > > Missing key leaf value in the message-body (<name>Wasting
> > > Light</name>)
> > > 
> > > 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > > ietf.org%2Fmailman%2Flistinfo%2Fnetconf&amp;data=04%7C01%7Cmuly_i%40
> > > ra
> > > d.com%7Cf7ffd30dde054f875cc608d88f8b0eed%7Cf9047108cc2c4e4897a343fad
> > > 1b
> > > 3bf9d%7C1%7C0%7C637417174712193376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> > > C4
> > > wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;s
> > > da
> > > ta=GOd8xUYLJ9C69r7aN6rujBhsYFJd05CxiHNXT9YXOZ0%3D&amp;reserved=0
> > 
> > _______________________________________________
> > netconf mailing list
> > netconf@ietf.org
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > ietf.org%2Fmailman%2Flistinfo%2Fnetconf&amp;data=04%7C01%7Cmuly_i%40ra
> > d.com%7Cf5c6b052c9fe4dd9c64308d88fa96449%7Cf9047108cc2c4e4897a343fad1b
> > 3bf9d%7C1%7C0%7C637417304990448682%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> > wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sda
> > ta=SOPMijRWiUHA%2BpJnmxGJ4%2FLWqneTaFwfyIpdpuFl5yU%3D&amp;reserved=0