[netconf] [Technical Errata Reported] RFC6243 (7426)
RFC Errata System <rfc-editor@rfc-editor.org> Tue, 18 April 2023 12:35 UTC
Return-Path: <wwwrun@rfcpa.amsl.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 2F371C1782D5 for <netconf@ietfa.amsl.com>; Tue, 18 Apr 2023 05:35:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.947
X-Spam-Level:
X-Spam-Status: No, score=-3.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xK6bAZCLswmL for <netconf@ietfa.amsl.com>; Tue, 18 Apr 2023 05:35:49 -0700 (PDT)
Received: from rfcpa.amsl.com (rfc-editor.org [50.223.129.200]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57C20C1782D7 for <netconf@ietf.org>; Tue, 18 Apr 2023 05:35:49 -0700 (PDT)
Received: by rfcpa.amsl.com (Postfix, from userid 499) id 303B655E92; Tue, 18 Apr 2023 05:35:49 -0700 (PDT)
To: andy@yumaworks.com, balazs.lengyel@ericsson.com, warren@kumari.net, rwilton@cisco.com, mjethanandani@gmail.com, kent+ietf@watsen.net
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: dylan.sadoun@orange.com, netconf@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20230418123549.303B655E92@rfcpa.amsl.com>
Date: Tue, 18 Apr 2023 05:35:49 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/zJYGaSYVo7ooyT_tHkpIWB2mQWw>
Subject: [netconf] [Technical Errata Reported] RFC6243 (7426)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: NETCONF WG 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: Tue, 18 Apr 2023 12:35:53 -0000
The following errata report has been submitted for RFC6243, "With-defaults Capability for NETCONF". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid7426 -------------------------------------- Type: Technical Reported by: Dylan Sadoun <dylan.sadoun@orange.com> Section: 2.3.1 Original Text ------------- When data is retrieved from a server using the 'explicit' basic mode, and the <with-defaults> parameter is not present, data nodes MUST be reported if explicitly set by the client, even if they contain the schema default value. Non-configuration data nodes containing the schema default value MUST be reported. Corrected Text -------------- When data is retrieved from a server using the 'explicit' basic mode, and the <with-defaults> parameter is not present, data nodes MUST be reported if explicitly set. This means that data nodes containing the schema default value MUST be reported if set by a NETCONF client, but MUST NOT be reported if set by the NETCONF server. Data nodes set by the NETCONF server to values other than their schema default values MUST be reported. Non-configuration data nodes containing the schema default value MUST be reported. Notes ----- The RFC defines "Explicitly set data" for the sole purpose of defining the explicit retrieval mode. This definition is clear about when data set by the server should be considered "explicitly set" i.e. when not set to the schema default value. However, the 2.3.1 and 3.3 sections are ambiguous and prone to misunderstanding, as they only emphasise the "set by the client" case, which leads to think that data set by the server to a value different from its schema default value should not be reported. This erratum is for the 2.3.1 section. 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. -------------------------------------- RFC6243 (draft-ietf-netconf-with-defaults-14) -------------------------------------- Title : With-defaults Capability for NETCONF Publication Date : June 2011 Author(s) : A. Bierman, B. Lengyel Category : PROPOSED STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG
- [netconf] [Technical Errata Reported] RFC6243 (74… RFC Errata System
- Re: [netconf] [Technical Errata Reported] RFC6243… Andy Bierman
- Re: [netconf] [Technical Errata Reported] RFC6243… Rob Wilton (rwilton)
- Re: [netconf] [Technical Errata Reported] RFC6243… Andy Bierman