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

[Muly Ilan <[e-mail]>]

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:[e-mail]] 
Sent: 23/11/2020 14:15
To: Muly Ilan <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6342)

Hi,

Muly Ilan <[e-mail]> 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:[e-mail]] On Behalf Of Martin 
> Bj?rklund
> Sent: 23/11/2020 10:37
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> 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 <[e-mail]> 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 <[e-mail]>
> > 
> > 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
> > [e-mail]
> > 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
> [e-mail]
> 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