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

Andy Bierman <andy@yumaworks.com> Mon, 23 November 2020 16:00 UTC

Return-Path: <andy@yumaworks.com>
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 0A9033A02BC for <netconf@ietfa.amsl.com>; Mon, 23 Nov 2020 08:00:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.013
X-Spam-Level:
X-Spam-Status: No, score=0.013 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 AoiF6PCc7vlg for <netconf@ietfa.amsl.com>; Mon, 23 Nov 2020 08:00:42 -0800 (PST)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E3323A0140 for <netconf@ietf.org>; Mon, 23 Nov 2020 08:00:42 -0800 (PST)
Received: by mail-lj1-x22c.google.com with SMTP id 142so18512270ljj.10 for <netconf@ietf.org>; Mon, 23 Nov 2020 08:00:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FHqWYzRUJKbtKAzPGl8HyofT+DIsJJEyNBSXdjqvLaw=; b=QSbeGW49VbKkAAEkua8sSSpKbW+hoQK6M533RBODdGilNnLmhEsl6jxXyLJaXXFFxJ YvyGF/kzlKd1IYjP1PKSJdHOx82K1m7+60cUhz7AbY2ZnMlJsbOq5vn2xlC+JtXwsgjr U2eVXLHZWBuOOEkAnqC0wBH4OQIUQsXNxBAkfsHZOqtv3bLoc+FU7UQlndVCRfEj/+Ax 6aZTMF37xfrTk7QwZvkfSd/ffS4EOC3i7+gfk70HAyps3xN0VDq9glZ6ufJUafqoYw7/ Zem8ge6qaec5y+Bd/PTTWE+vywgwiMV4JGgEjgJ0Q7LdBwdDkdornnQrQhlsKiGSlSdr vGYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FHqWYzRUJKbtKAzPGl8HyofT+DIsJJEyNBSXdjqvLaw=; b=ZIzay11JymPm+0aeS34TCV7NI0IxdddckQ6PYq3IniF6IeRz6lFBeuRsn0zNIu3FwC 6ECgxKnycwLwSXUwXM6ChteCBY/QVNYvmLZLk0Z0pv8ZxXyHiehABYV0Aylgg/6IKxb3 l7cuGabyVpXQu2cjoI9TwwQZOmytvd7yS1bYe9d8jMcmNCDMPeakCt9kLeVh0dMyo4My qXZhhblqb26S03XvioWy40jhngYDaWcFbJk/uSSagnlA3wZUTxSNwYbPCBMg1i/VjyS0 CLLMg4tN8Achf8XRQf6bztQ+morOZ2Kv/hZ3LVIgWkg1BaIH0lNnnAVdtLcrxxT8ORGl iuKg==
X-Gm-Message-State: AOAM533x5wtxQcUMILg4Mj9iQKbeVw17G0PfaEFEoO/phkrY9B+ICGn8 dNL93GWbKlZ3fu278cjIjWATsKn578taH/b5rumzmQ==
X-Google-Smtp-Source: ABdhPJw7CPlHi/wv+fNi15ZGvlAwuXdIN6eU/LXGmfoTSwOiq35RWfb1MgmTPMMP60A93f77Yp3y3rMsGyxnBnOxxyQ=
X-Received: by 2002:a2e:9f16:: with SMTP id u22mr23188ljk.456.1606147238727; Mon, 23 Nov 2020 08:00:38 -0800 (PST)
MIME-Version: 1.0
References: <20201123.131452.2154616412508504559.id@4668.se> <AM0PR0302MB33480674E3CAB4D8AB4DCBB5F9FC0@AM0PR0302MB3348.eurprd03.prod.outlook.com> <AM0PR0302MB334833C570C323DA7E3AEE7AF9FC0@AM0PR0302MB3348.eurprd03.prod.outlook.com> <20201123.143840.1300967807479051474.id@4668.se>
In-Reply-To: <20201123.143840.1300967807479051474.id@4668.se>
From: Andy Bierman <andy@yumaworks.com>
Date: Mon, 23 Nov 2020 08:00:27 -0800
Message-ID: <CABCOCHSH=sYTK6xsGu-jiE3SWUjRujJ=koh=gein78G-rU=SgQ@mail.gmail.com>
To: =?UTF-8?Q?Martin_Bj=C3=B6rklund?= <mbj+ietf@4668.se>
Cc: muly_i@rad.com, Netconf <netconf@ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
Content-Type: multipart/alternative; boundary="0000000000009f2c3005b4c84b91"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/TuYOsTIquicJqjDaXGDjBO9m6gA>
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 16:00:45 -0000

On Mon, Nov 23, 2020 at 5:38 AM Martin Björklund <mbj+ietf@4668.se> wrote:

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

Although we have several customers that would like to rename list entries,
and sometimes think RESTCONF allows it.  I do not think any YANG-based
protocol
allows list keys to be modified.  You have to delete and re-create the list
entry.
I think this is something for YANG-next to consider, so it is done
consistently across
all protocols.



> /martin
>

Andy


>
>
> >
> > 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
>
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>