Re: [Netconf] [Technical Errata Reported] RFC8040 (5565)

[Qin Wu <[e-mail]>]

See data-missing definition in RFC6241:
"
   error-tag:      data-missing
   error-type:     application
   error-severity: error
   error-info:     none
   Description:    Request could not be completed because the relevant
                   data model content does not exist.  For example,
                   a "delete" operation was attempted on
                   data that does not exist.

"
And status code 409 definition in RFC7231
"
6.5.8.  409 Conflict

   The 409 (Conflict) status code indicates that the request could not
   be completed due to a conflict with the current state of the target
   resource.  This code is used in situations where the user might be
   able to resolve the conflict and resubmit the request.  The server
   SHOULD generate a payload that includes enough information for a user
   to recognize the source of the conflict.

6.5.4.  404 Not Found

   The 404 (Not Found) status code indicates that the origin server did
   not find a current representation for the target resource or is not
   willing to disclose that one exists.  A 404 status code does not
   indicate whether this lack of representation is temporary or
   permanent; the 410 (Gone) status code is preferred over 404 if the
   origin server knows, presumably through some configurable means, that
   the condition is likely to be permanent.

"
Which make me feel data missing is more related to 404 instead of 409. Wrong?

-Qin
-----邮件原件-----
发件人: Martin Bjorklund [mailto:[e-mail]] 
发送时间: 2018年12月3日 16:54
收件人: [e-mail]
抄送: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; Qin Wu; [e-mail]
主题: Re: [Technical Errata Reported] RFC8040 (5565)

Hi,

I don't think this errata should be accepted.  404 means that the requested resource doesn't exist, but "data-missing" can be returned e.g. if you try to patch an existing resource of type leafref to point to a non-existing leaf.


/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:
> http://www.rfc-editor.org/errata/eid5565
> 
> --------------------------------------
> Type: Technical
> Reported by: Qin Wu <[e-mail]>
> 
> Section: 7
> 
> Original Text
> -------------
>               +-------------------------+------------------+
>               | error-tag               | status code      |
>               +-------------------------+------------------+
>               | in-use                  | 409              |
>               | lock-denied             | 409              |
>               | resource-denied         | 409              |
>               | data-exists             | 409              |
>               | data-missing            | 409              |
> 
> 
> Corrected Text
> --------------
>               +-------------------------+------------------+
>               | error-tag               | status code      |
>               +-------------------------+------------------+
>               | in-use                  | 409              |
>               | lock-denied             | 409              |
>               | resource-denied         | 409              |
>               | data-exists             | 409              |
>               | data-missing            | 404              |
> 
> 
> Notes
> -----
> The <error-tag> data missing should be mapped to status code '404' instead of '409' to get consistent with the defintion of data-missing in RFC6241.
> 
> 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
>