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

[Qin Wu <[e-mail]>]

I agree to move this Errata issue to RESTCONF-next issue tracker
The issue is filed here:
https://github.com/netconf-wg/restconf-next/issues/2

-Qin
发件人: Kent Watsen [mailto:[e-mail]]
发送时间: 2019年6月24日 22:40
收件人: Andy Bierman <[e-mail]>
抄送: Qin Wu <[e-mail]>; RFC Errata System <[e-mail]>; Martin Bjorklund <[e-mail]>; Kent Watsen <[e-mail]>; Ignas Bagdonas <[e-mail]>; Warren Kumari <[e-mail]>; Mahesh Jethanandani <[e-mail]>; [e-mail]
主题: Re: [Technical Errata Reported] RFC8040 (5761)

The suggested fix is better.  Too bad we didn't catch it during publication.  Changing it in an Errata isn't appropriate.  Please file an issue for RESTCONF-next here: https://github.com/netconf-wg/restconf-next/issues.

Kent




On Jun 24, 2019, at 10:26 AM, Andy Bierman <[e-mail]<mailto:[e-mail]>> wrote:



On Mon, Jun 24, 2019 at 6:27 AM Qin Wu <[e-mail]<mailto:[e-mail]>> wrote:
Thanks for the quick reply, can you clarify the reason behind? Thanks!



RFC 8040 specifies an error-tag to use.
The claim that RFC 6241 specifies something else is no proof the
WG intended to use that error-tag in RFC 8040.

An errata means that implementations that conform to the RFC are wrong
and need to be corrected.  IMO the change being proposed is not a typo and
there is no other text in RFC 8040 that contradicts the specified error-tag.

A change of this technical significance that impacts conformance needs to go
through the normal RFC publication/approval process.

Andy

-Qin
发件人: Andy Bierman [mailto:[e-mail]<mailto:[e-mail]>]
发送时间: 2019年6月24日 20:59
收件人: RFC Errata System <[e-mail]<mailto:[e-mail]>>
抄送: Martin Bjorklund <[e-mail]<mailto:[e-mail]>>; Kent Watsen <[e-mail]<mailto:[e-mail]>>; Ignas Bagdonas <[e-mail]<mailto:[e-mail]>>; Warren Kumari <[e-mail]<mailto:[e-mail]>>; Kent Watsen <[e-mail]<mailto:[e-mail]>>; Mahesh Jethanandani <[e-mail]<mailto:[e-mail]>>; Qin Wu <[e-mail]<mailto:[e-mail]>>; Netconf <[e-mail]<mailto:[e-mail]>>
主题: Re: [Technical Errata Reported] RFC8040 (5761)

Hi,

The cited text is in 4.4.1 (there is no 4.1.1).

I do not see any evidence that the WG intended to write the word "data-exists" but
wrote "resource-denied" instead. Therefore this cannot be changed with an errata.


Andy


On Sun, Jun 23, 2019 at 6:08 PM 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/eid5761

--------------------------------------
Type: Technical
Reported by: Qin WU <[e-mail]<mailto:[e-mail]>>

Section: 4.1.1

Original Text
-------------
If the data resource already exists, then the POST request MUST fail
and a "409 Conflict" status-line MUST be returned.  The error-tag
value "resource-denied" is used in this case

Corrected Text
--------------
If the data resource already exists, then the POST request MUST fail
and a "409 Conflict" status-line MUST be returned.  The error-tag
value "data-exists" is used in this case

Notes
-----
The error-tag value should be corrected as "data-exists" in this case
based on the context. According to error-tag definition in RFC6241:

   error-tag:      resource-denied
   error-type:     transport, rpc, protocol, application
   error-severity: error
   error-info:     none
   Description:    Request could not be completed because of
                   insufficient resources.

It is apparent error-tag value "data-exists" should be corresponding
to the data resource already exists condition.

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