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

[Ignas Bagdonas <[e-mail]>]

Let's split the discussion into two parts - 8040 and 8072.

For RFC 8072 a separate errata would need to be raised. Or likely a
document on error handling clarifications, or a -bis to a base document.

For RFC 8040 section 7 status codes, it does not appear to be practical to
require full equivalence of protocol semantics and error handling between
8040 and 6241 at the cost of additional ambiguities and complexity. What
might be of value is to look at the existing implementations and how do
they treat such error cases, and publish either an implementation
recommendation document, or a -bis for a base specification. Errata is not
a suitable mechanism for this.

Rejected if no objections?





On Tue, Dec 18, 2018 at 11:46 AM Martin Bjorklund <[e-mail]> wrote:

> Qin Wu <[e-mail]> wrote:
> > -----邮件原件-----
> > 发件人: Martin Bjorklund [mailto:[e-mail]]
> > 发送时间: 2018年12月3日 17:48
> > 收件人: Qin Wu
> > 抄送: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> > 主题: Re: [Technical Errata Reported] RFC8040 (5565)
> >
> > Qin Wu <[e-mail]> wrote:
> > > 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?
> >
> > 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           |
> >
> > [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.
> > "
>
> 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
>
>
>
> >
> > /martin
> >
> >
> >
> > >
> > > -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
> > > >
>