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

[Martin Björklund <[e-mail]>]

Muly Ilan <[e-mail]> wrote:
> 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."

I meant:

  However, PUT means completely replace or create the target resource,
  but plain PATCH modifies only the given fields in the target
  resource.


/martin


> 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