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

[Kent Watsen <[e-mail]>]

The example uses “/data”, i.e., the unified datastore, which may contain operational data.  I guess that, for /data, it could be said that any "ETag" and "Last-Modified” headers only reflect the “config true” data present, in which case Andy’s interpretation makes sense.

But this is not true for NMDA’s <operational>, where said headers likely should never be returned, even if the “content” parameter is “config”.  

For NMDA’s <running>, it seems that the headers should always be returned, even when the “content” parameter is not specified, as Andy states.  I’m assuming content=nonconfig on <running> is an error case, or at least a non-sensical case..

K.


> On Dec 22, 2020, at 9:57 AM, Andy Bierman <[e-mail]> wrote:
> 
> Hi,
> 
> This Errata should be rejected.
> The cited text in non-normative Appendix B.3.1 is actually wrong.
> The parameter content=all can also return these fields for configuration data.
> 
> 
> The normative text in 3.5.2 explains what to do.
> 
> 
> 3.5.2 <https://tools.ietf.org/html/rfc8040#section-3.5.2>.  Entity-Tag
> 
>    For configuration data resources, the server SHOULD maintain a
>    resource entity-tag for each resource and return the "ETag" header
>    field when it is retrieved as the target resource with the GET or
>    HEAD methods.  If maintained, the resource entity-tag MUST be updated
>    whenever the resource or any configuration resource within the
>    resource is altered.  If not maintained, then the resource entity-tag
>    for the datastore MUST be used instead.
> 
> 
> Andy
> 
> On Tue, Dec 22, 2020 at 6:34 AM RFC Errata System <[e-mail] <mailto:[e-mail]>> wrote:
> The following errata report has been submitted for RFC8040,
> "RESTCONF Protocol".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6362 <https://www.rfc-editor.org/errata/eid6362>
> 
> --------------------------------------
> Type: Technical
> Reported by: Muly Ilan <[e-mail] <mailto:[e-mail]>>
> 
> Section: 4.3.
> 
> Original Text
> -------------
>    The client might request the response header fields for an XML
>    representation of a specific "album" resource:
> 
>       GET /restconf/data/example-jukebox:jukebox/\
>          library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1
>       Host: example.com <http://example.com/>
>       Accept: application/yang-data+xml
> 
>    The server might respond as follows:
> 
>       HTTP/1.1 200 OK
>       Date: Thu, 26 Jan 2017 20:56:30 GMT
>       Server: example-server
>       Content-Type: application/yang-data+xml
>       Cache-Control: no-cache
>       ETag: "a74eefc993a2b"
>       Last-Modified: Thu, 26 Jan 2017 14:02:14 GMT
> 
> Corrected Text
> --------------
>    The client might request the response header fields for an XML
>    representation of a specific "album" resource:
> 
>       GET /restconf/data/example-jukebox:jukebox/\
>          library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1
>       Host: example.com <http://example.com/>
>       Accept: application/yang-data+xml
> 
>    The server might respond as follows:
> 
>       HTTP/1.1 200 OK
>       Date: Thu, 26 Jan 2017 20:56:30 GMT
>       Server: example-server
>       Content-Type: application/yang-data+xml
>       Cache-Control: no-cache
> 
> 
> Notes
> -----
> Removed the "ETag" and "Last-Modified" header fields.
> 
> According to Appendix B.3.1. :
>    To retrieve only the configuration child resources, the "content"
>    parameter is set to "config".  Note that the "ETag" and
>    "Last-Modified" headers are only returned if the "content" parameter
>    value is "config".
> 
> 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