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

Qin Wu <bill.wu@huawei.com> Mon, 03 December 2018 09:38 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B0A130E2F for <netconf@ietfa.amsl.com>; Mon, 3 Dec 2018 01:38:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgdlB_dB6ieB for <netconf@ietfa.amsl.com>; Mon, 3 Dec 2018 01:38:45 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FCC5130E4A for <netconf@ietf.org>; Mon, 3 Dec 2018 01:38:45 -0800 (PST)
Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 3281C92472129 for <netconf@ietf.org>; Mon, 3 Dec 2018 09:38:28 +0000 (GMT)
Received: from lhreml707-chm.china.huawei.com (10.201.108.56) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 3 Dec 2018 09:38:29 +0000
Received: from lhreml707-chm.china.huawei.com (10.201.108.56) by lhreml707-chm.china.huawei.com (10.201.108.56) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Mon, 3 Dec 2018 09:38:29 +0000
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml707-chm.china.huawei.com (10.201.108.56) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1591.10 via Frontend Transport; Mon, 3 Dec 2018 09:38:28 +0000
Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.69]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0415.000; Mon, 3 Dec 2018 17:38:22 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Martin Bjorklund <mbj@tail-f.com>, "rfc-editor@rfc-editor.org" <rfc-editor@rfc-editor.org>
CC: "andy@yumaworks.com" <andy@yumaworks.com>, "kwatsen@juniper.net" <kwatsen@juniper.net>, "ibagdona@gmail.com" <ibagdona@gmail.com>, "warren@kumari.net" <warren@kumari.net>, "mjethanandani@gmail.com" <mjethanandani@gmail.com>, "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [Technical Errata Reported] RFC8040 (5565)
Thread-Index: AQHUis0fOWI85JR8KUeCGWx7iiB8pKVsL8uAgACRE7A=
Date: Mon, 3 Dec 2018 09:38:21 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA9B177661@nkgeml513-mbs.china.huawei.com>
References: <20181203055737.B72D1B8122E@rfc-editor.org> <20181203.095409.224403340529984673.mbj@tail-f.com>
In-Reply-To: <20181203.095409.224403340529984673.mbj@tail-f.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.33.244]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/wKhSu848x_sop9YK2cpnCNVh6NA>
Subject: Re: [Netconf] [Technical Errata Reported] RFC8040 (5565)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Dec 2018 09:38:48 -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:mbj@tail-f.com] 
发送时间: 2018年12月3日 16:54
收件人: rfc-editor@rfc-editor.org
抄送: andy@yumaworks.com; kwatsen@juniper.net; ibagdona@gmail.com; warren@kumari.net; mjethanandani@gmail.com; Qin Wu; netconf@ietf.org
主题: 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 <rfc-editor@rfc-editor.org> 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 <bill.wu@huawei.com>
> 
> 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
>