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

Martin Björklund <mbj+ietf@4668.se> Mon, 23 November 2020 12:14 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 43C383A099E for <netconf@ietfa.amsl.com>; Mon, 23 Nov 2020 04:14:58 -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=hV73DbDL; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WzRz6YsD
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 6qHE8uyri97k for <netconf@ietfa.amsl.com>; Mon, 23 Nov 2020 04:14:56 -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 603DD3A0997 for <netconf@ietf.org>; Mon, 23 Nov 2020 04:14:56 -0800 (PST)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 873D55C0121; Mon, 23 Nov 2020 07:14:55 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Mon, 23 Nov 2020 07:14:55 -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= aUYUuQEEP6Imk8D2iEslXIQVd2C4bL/z+w2XBbFDczo=; b=hV73DbDLGuvaA44k L18GHy1jtLE9PvT70nH51VYwQCwQ8uA74e+oNCbmg+CJ84G3iExb6jQxIeG8chMI 3falBEQuYr/zH/nA4ii60mrUfivD1+M+El0ZOdDA+UdxfgR0qhkwB0rkC3yZtMqh Y33cVoDA7aP2lfkcckN7GL38pIG+N/TMCCA/dL5NoKADc5N0zbBNyuIp5tN53fMm u73F+65qPQe3XTgTBd5lXiabYF9tQuCKh9gt8ewrQdnx31uQhBxmcfBcv/uWS0B0 VYRF9oMJkMOn4pGBl4Z85Bj5PVzt7Am4mQxPKeEE5mOHd2lbqEuXATPBFHRqsKYX vzC3Og==
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=aUYUuQEEP6Imk8D2iEslXIQVd2C4bL/z+w2XBbFDc zo=; b=WzRz6YsD08WPMu65W+zadRpvPE44vVY865ezBjEPo0bmif0UAFcepMg69 xnu8SCZxKreEaqHyG65sTvY0hsfecCGc4Ol1+CPl+FmcQRwn3Mp0txzksd+n2LcQ Ln5grlWWr3LJ3cmKM6og2p86tbncETjEw/bAL0eX6FSQzPz604/e+74NlfxIVksi vXuc8JMqyeT0XTRMbe2OkOqvASYviRVL5fYxoFVb58vRQPzpp8oUaPiSYWdP2Kkx wwlR3zfnPDP+Tx4Ykoq1lqEABOB0oSUq7zsRhG6iBqNFnZaa2EKZpHALspN9cl7V XbNhWeIaXNTM1mTiMyKf/2QWsOUsA==
X-ME-Sender: <xms:v6e7X5GWM6M9XPky7Nu0dA-CZPSQaYaFH9MbYPoGJ2V4m9pMnKSDUw> <xme:v6e7X-V936mRsG6hM-y3k2653zb2DZ1D9gDEaIwTJLE1hr9KoA6-cra8EOaQYd5a4 KeWDehEd0PSyNWgxPU>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudegiedgfeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffkffvuffhjghfofggtgfgsehtje ertdertddvnecuhfhrohhmpeforghrthhinhcuuehjnphrkhhluhhnugcuoehmsghjodhi vghtfhesgeeiieekrdhsvgeqnecuggftrfgrthhtvghrnhepieehvdfhkeeivdefleelgf duudeftdetjeegjeegudetuedujefgtdetfffhvdfhnecuffhomhgrihhnpeduhhhoshht vgigrghmphhlvgdrtghomhdpohhuthhlohhokhdrtghomhdprhhftgdqvgguihhtohhrrd horhhgpdhivghtfhdrohhrghenucfkphepudehkedrudejgedrgedrvdduheenucevlhhu shhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmsghjodhivghtfh esgeeiieekrdhsvg
X-ME-Proxy: <xmx:v6e7X7KwwLv1_mqTIbNRWArjr5X2vFNhACW-mHAymQ5jpkssFABiNw> <xmx:v6e7X_GTxpTBb1XABlFJC20840M9A496YSYY71VzZeu7KA0xn1Llgw> <xmx:v6e7X_VH5119IxP5QdIjDmzsMQGL6l2-RaCIV1H9G5wbjKnmbrjuUA> <xmx:v6e7X2fMp6_meZ5vK1jg7xgL6BRQywZUF8ULxayDxu_RCyf8Qnd8qQ>
Received: from localhost (unknown [158.174.4.215]) by mail.messagingengine.com (Postfix) with ESMTPA id 724C33280059; Mon, 23 Nov 2020 07:14:54 -0500 (EST)
Date: Mon, 23 Nov 2020 13:14:52 +0100
Message-Id: <20201123.131452.2154616412508504559.id@4668.se>
To: muly_i@rad.com
Cc: rfc-editor@rfc-editor.org, kent+ietf@watsen.net, netconf@ietf.org
From: Martin Björklund <mbj+ietf@4668.se>
In-Reply-To: <AM0PR0302MB3348EBB2C0F57E3B4FD8D7F7F9FC0@AM0PR0302MB3348.eurprd03.prod.outlook.com>
References: <20201122221445.1E11FF4071F@rfc-editor.org> <20201123.093729.325420538444196813.id@4668.se> <AM0PR0302MB3348EBB2C0F57E3B4FD8D7F7F9FC0@AM0PR0302MB3348.eurprd03.prod.outlook.com>
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/Vc9IGuprzUskFJBrNeHEvEkYESI>
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 12:14:58 -0000

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.com%
> > 7Cf7ffd30dde054f875cc608d88f8b0eed%7Cf9047108cc2c4e4897a343fad1b3bf9d%
> > 7C1%7C0%7C637417174712193376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> > DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=2nm
> > 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%2F%
> > 2Fexample.com%2Fns%2Fexample-jukebox&amp;data=04%7C01%7Cmuly_i%40rad.c
> > om%7Cf7ffd30dde054f875cc608d88f8b0eed%7Cf9047108cc2c4e4897a343fad1b3bf
> > 9d%7C1%7C0%7C637417174712193376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
> > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=
> > 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%2F%
> > 2Fexample.com%2Fns%2Fexample-jukebox&amp;data=04%7C01%7Cmuly_i%40rad.c
> > om%7Cf7ffd30dde054f875cc608d88f8b0eed%7Cf9047108cc2c4e4897a343fad1b3bf
> > 9d%7C1%7C0%7C637417174712193376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
> > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=
> > 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%40ra
> > d.com%7Cf7ffd30dde054f875cc608d88f8b0eed%7Cf9047108cc2c4e4897a343fad1b
> > 3bf9d%7C1%7C0%7C637417174712193376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> > wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sda
> > 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%40rad.com%7Cf7ffd30dde054f875cc608d88f8b0eed%7Cf9047108cc2c4e4897a343fad1b3bf9d%7C1%7C0%7C637417174712193376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=GOd8xUYLJ9C69r7aN6rujBhsYFJd05CxiHNXT9YXOZ0%3D&amp;reserved=0