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

From: RFC Errata System <[email-masked]>
Date: Sun, 2 Dec 2018 21:57:37 -0800 (PST)

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 <[email-masked]>

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

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 03 Dec 2018 09:54:09 +0100 (CET)

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

---

From: Qin Wu <[email-masked]>
Date: Mon, 3 Dec 2018 09:38:21 +0000

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:[email-masked]] 
发送时间: 2018年12月3日 16:54
收件人: [email-masked]
抄送: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Qin Wu; [email-masked]
主题: 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 <[email-masked]> wrote:
> The following errata report has been submitted for RFC8040, "RESTCONF 
> Protocol".
> 
> 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.
>

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 03 Dec 2018 10:48:08 +0100 (CET)

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

404 means that *the requested resource* doesn't exist.

The example "delete" operation in 6241 refers to an edit-config with
operation "delete".  The corresponding RESTCONF operation is "delete"
within a YANG PATCH.  In this case, the requested resource exists, so
a 404 would not be correct.

So there are certainly cases where "data-missing" does not mean 404.

But I guess there are also cases where "data-missing" will actually
correspond to a 404.  For example an edit-config that just tries to
delete a non-existing node will be a "data-missing", and if the
corresponding RESTCONF request is a DELETE on the resource, it will be
404 - but if the corresponding RESTCONF request is a YANG PATCH with a
"delete" edit, it will be 409.

So, maybe the proper fix is

               | data-missing            | 404, 409           |

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 3 Dec 2018 11:14:00 +0100

>                | data-missing            | 404, 409           |

And then you hope that different implementors will come to the same
conclusions when to return 404 or 409. I have some doubts that this
will work well...

Are there implementations that return 404 for data-missing today?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 03 Dec 2018 11:20:21 +0100 (CET)

> conclusions when to return 404 or 409. I have some doubts that this

Yes, I started to write that we also need additional text to explain
this.  But that would probably be too much for an errata.

> Are there implementations that return 404 for data-missing today?

I'm pretty sure that all implementations return 404 if someone tries
to DELETE a non-existing resource, which in NETCONF would be a
"data-missing" reply to an edit-config.

But it is not quite clear if the table in section 7 of RFC 8040 is
supposed to be used in this case...

/martin

---

From: Qin Wu <[email-masked]>
Date: Mon, 3 Dec 2018 10:26:23 +0000

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

Qin Wu <[email-masked]> wrote:
> And status code 409 definition in RFC7231 "
> 6.5.8.  409 Conflict
> 

The example "delete" operation in 6241 refers to an edit-config with operation "delete".  The corresponding RESTCONF operation is "delete"
within a YANG PATCH.  In this case, the requested resource exists, so a 404 would not be correct.

But I guess there are also cases where "data-missing" will actually correspond to a 404.  For example an edit-config that just tries to delete a non-existing node will be a "data-missing", and if the corresponding RESTCONF request is a DELETE on the resource, it will be
404 - but if the corresponding RESTCONF request is a YANG PATCH with a "delete" edit, it will be 409.

/martin

[Qin]: Looks like status code 404 is given a different meaning in RFC8040
See the following quoted text:
"
4.  RESTCONF Methods
The resource must exist or the DELETE method will fail. 

4.6.  PATCH
If the user is not authorized to alter the target resource, an error
   response containing a "403 Forbidden" status-line SHOULD be returned.
   A server MAY return a "404 Not Found" status-line, as described in
   Section 6.5.4 in [RFC7231].  The error-tag value "invalid-value" is
   used in this case. 

4.7.  DELETE
   If the user is not authorized to delete the target resource, then an
   error response containing a "403 Forbidden" status-line SHOULD be
   returned.  The error-tag value "access-denied" is returned in this
   case.  A server MAY return a "404 Not Found" status-line, as
   described in Section 6.5.4 in [RFC7231].  The error-tag value
   "invalid-value" is returned in this case.
"
If we allow mapping data-missing into 404, it seems to me more changes are required.
> 抄送: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; Qin Wu; [email-masked]

---

From: Qin Wu <[email-masked]>
Date: Mon, 3 Dec 2018 10:29:02 +0000

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

> conclusions when to return 404 or 409. I have some doubts that this 

Yes, I started to write that we also need additional text to explain this.  But that would probably be too much for an errata.

[Qin]: Correct.

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 03 Dec 2018 11:38:12 +0100 (CET)

> If we allow mapping data-missing into 404, it seems to me more

No, this is a different thing.  If "data-missing" can be mapped
to 404 it doesn't imply that 404 always means "data-missing".

See 6.5.4 in RFC 7231:

   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.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 03 Dec 2018 11:41:19 +0100

> conclusions when to return 404 or 409. I have some doubts that this

data-missing is a misleading error tag, if it is used for validity
problem.

> Are there implementations that return 404 for data-missing today?

Yes, JetConf returns 404 if the client attempts to delete a non-existent
resource.

An edit leading to invalid data doesn't apply to JetConf because
validation is only performed at commit, i.e. not after every edit.

Lada

> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Qin Wu <[email-masked]>
Date: Tue, 18 Dec 2018 08:50:42 +0000

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

[Qin]: Tend to agree, but YANG patch supporting the ability to delete child resources defined in RFC8072 also support return 404,
See section 2.2 of RFC8072:
"
   If the edit does not identify
   any existing resource instance and the operation for the edit is not
   "create", then the request MUST NOT be processed and a "404 Not
   Found" error response MUST be sent by the server. 
"

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 18 Dec 2018 12:46:53 +0100 (CET)

>    Found" error response MUST be sent by the server. 

This seems to be an error.  RFC 5789 (HTTP PATCH) has this:

   Conflicting state:  Can be specified with a 409 (Conflict) status
      code when the request cannot be applied given the state of the
      resource.  For example, if the client attempted to apply a
      structural modification and the structures assumed to exist did
      not exist (with XML, a patch might specify changing element 'foo'
      to element 'bar' but element 'foo' might not exist).

/martin