[netconf] [Errata Verified] RFC6243 (7426)

RFC Errata System <rfc-editor@rfc-editor.org> Mon, 02 October 2023 12:55 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 4786CC153CA1; Mon, 2 Oct 2023 05:55:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.534
X-Spam-Level:
X-Spam-Status: No, score=0.534 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CTE_8BIT_MISMATCH=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, RDNS_NONE=0.793, SPF_HELO_SOFTFAIL=0.732, SPF_SOFTFAIL=0.665, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no 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 tSPsnj27VQSg; Mon, 2 Oct 2023 05:55:34 -0700 (PDT)
Received: from rfcpa.amsl.com (unknown [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 75C69C1527A0; Mon, 2 Oct 2023 05:55:34 -0700 (PDT)
Received: by rfcpa.amsl.com (Postfix, from userid 499) id 41FA6E7276; Mon, 2 Oct 2023 05:55:34 -0700 (PDT)
To: dylan.sadoun@orange.com, andy@yumaworks.com, balazs.lengyel@ericsson.com
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: rwilton@cisco.com, iesg@ietf.org, netconf@ietf.org, iana@iana.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20231002125534.41FA6E7276@rfcpa.amsl.com>
Date: Mon, 02 Oct 2023 05:55:34 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/-3sO87KUQTwv-_-wd0E6YMnLTXo>
Subject: [netconf] [Errata Verified] 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: Mon, 02 Oct 2023 12:55:38 -0000

The following errata report has been verified for RFC6243,
"With-defaults Capability for NETCONF". 

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7426

--------------------------------------
Status: Verified
Type: Technical

Reported by: Dylan Sadoun <dylan.sadoun@orange.com>
Date Reported: 2023-04-18
Verified by: Rob Wilton (IESG)

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 by the client, even if they contain the
   schema default value.  A conceptual data node that would be set by
   the server to the schema default value MUST NOT be reported.
   Non-configuration data nodes containing the schema default value MUST
   be reported.

Notes
-----
This change brings the text and behavior more in alignment between ‘explicit’ Basic Mode (2.3.1) and ‘explicit’ Retrieval Mode (3.3).

The original errata also proposed that the text be clarified to define the behaviour for configuration explicitly set by a server, but after discussion with members of the WG, the general consensus is that this behaviour is outside the scope of the YANG and related management protocol RFCs that generally define changes to the server datastore contents in terms of explicit client requests to changes to the server’s configuration data.  The terminology definition of “Explicitly set data” in the RFC does give some guidance of the expectations of how server set data should be treated.

Further clarification on server behavior absent of explicit client operations should be specified in new RFCs.

--------------------------------------
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