Re: [netconf] [Technical Errata Reported] RFC6243 (7427)

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Andy, Dylan,

On this one, I agree with Andy, and I propose that we reject this errata.

I may be wrong, but I don’t think that the IETF YANG and NETCONF/RESTCONF standards formally define how configuration can be set outside of a client operation (perhaps except bootup or sZTP), except when conceptually set to a default value, which is already covered by the text.

Hence, if a server is setting some of the configuration to a non default-value then one could perhaps argue that is out of scope for the IETF drafts, or that logically, the server is also internally acting as a NETCONF/RESTCONF client, and hence Andy’s statement: “It is not possible for a node to have a value other than the YANG default and not be explicitly set.” seems correct.

Given that my interpretation may be going out on a limb, are there any other opinions here?

Regards,
Rob


From: Andy Bierman <[e-mail]>
Sent: 18 April 2023 17:54
To: RFC Errata System <[e-mail]>
Cc: [e-mail]; [e-mail]; Rob Wilton (rwilton) <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [Technical Errata Reported] RFC6243 (7427)

Hi,

This Errata should be rejected.
The additional sentence is not needed and was not left out of the original text by error.

This sentence refers to a node without an instance so the YANG default is used instead.

     A conceptual data node that would be set by the server to the schema default value MUST NOT be reported.

The key text is "would be set". A better clarification is "would be used"
The intent is that the node is not explicitly set.

It is not possible for a node to have a value other than the YANG default and not be explicitly set.

Andy

On Tue, Apr 18, 2023 at 5:37 AM RFC Errata System <[e-mail]<mailto:[e-mail]>> wrote:
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/eid7427

--------------------------------------
Type: Technical
Reported by: Dylan Sadoun <[e-mail]<mailto:[e-mail]>>

Section: 3.3

Original Text
-------------
When data is retrieved with a <with-defaults> parameter equal to 'explicit', a data node that was set by a client to its schema default value MUST be reported.  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.

Corrected Text
--------------
When data is retrieved with a <with-defaults> parameter equal to 'explicit', a data node that was set by a client to its schema default value MUST be reported. A conceptual data node that would be set by the server to the schema default value MUST NOT be reported. A conceptual data node that would be set by the server to a value other than its schema default value 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 3.3 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