Re: [netconf] Regarding RFC 6243 "With-defaults Capability for NETCONF" … the devil is in the defaults

["Jason Sterne (Nokia)" <[e-mail]>]

I agree that any data that is set should be returned.  (note there is plenty of debate as to whether/how a *server* sets data in its own running, and several associated RFCs/drafts around this topic).

From: netconf <[e-mail]> On Behalf Of Andy Bierman
Sent: Friday, April 14, 2023 11:08 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re: [netconf] Regarding RFC 6243 "With-defaults Capability for NETCONF" … the devil is in the defaults


CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.


Hi,

I think the text in 2.3.1 is an omission.

"set by client" should be "set by client or server"

Andy


On Fri, Apr 14, 2023 at 7:53 AM <[e-mail]<mailto:[e-mail]>> wrote:

Hello



I am reaching you about a potential technical erratum in RFC 6243, although I am not accustomed to the IETF process. I read https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/ but I am still not sure if that qualifies for an erratum request. Let me share my observations with you, please tell me if I should report an erratum and in that case I will do accordingly.



The RFC defines 3 ways for NETCONF servers (most commonly routers for a service provider such as my employer) to deal with default data for "get and set" NETCONF operations. Each router implementation must choose one of the 3 ways as its implicit/default/basic mode, and can also support other modes if asked to by a NETCONF client.



My concern is about the explicit mode (when the NETCONF server supports it, with no distinction if it is the router's basic mode or not) and configuration data reports by NETCONF servers.



The RFC defines:


Explicitly set data
Data that is set to any value by a NETCONF client or other management application by the way of an explicit management operation, including any data model schema default value.  Any value set by the NETCONF server that is not the schema defined default value is also considered explicitly set data.



(emphasis mine. Please refer to the RFC for additional definitions).



First, let me dive into the previous drafts to highlight the importance of the highlighted text. In the draft-ietf-netconf-with-defaults-04, the definition was different:


Explicitly set default data
Is default data that is set by a NETCONF client or other external management application/user by the way of an actual management operation to the value specified as its default in the data model schema.  Some servers MAY treat explicitly set default data as simple default data, as they may not be able to differentiate between them. Data, that is set to a value other then its default value, is not default data, so its handling is outside the scope of this document.



but as soon as the draft-ietf-netconf-with-defaults-05, the definition was changed to its final RFC form (except for one word: "actual" instead of "explicit"). Thus we can infer the early importance of the highlighted text:

Indeed, if a NETCONF server sets some data that are NOT schema default data, these data are consired explicitly set data.



The whole point of this definition and its only purpose is to later define the 'explicit' mode, the term being only used in the 2.3.  'explicit' Basic Mode and the 3.3.  'explicit' Retrieval Mode paragraphs (or in other paragraphs, when refering to the explicit mode).

The 2.3.1.  'explicit' Basic Mode Retrieval paragraph states:
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.



(emphasis mine).



This is where I think there is a mistake in the RFC. Why would only data nodes explicitly set by the client be reported? Why not explictly set data by the server as well? There are at least 3 arguments to qualify that as a mistake:

  1.  Firstly, what is the point of the definition highlighting that if a NETCONF server defines data (to values that are not the schema default ones) it is also explicitly set data, if that specific case is then excluded from the explicit mode paragraph?
  2.  Secondly, if the NETCONF server does not report this data which is not in the YANG schema, where should one be aware of the existence of this data? (other than by using another mode). Having read the RFC multiple times, it seems logical and intuitive to me that, in any mode, one should be able to find all data on the server by combining the NETCONF server report after a get AND the corresponding YANG schema.
  3.  Thirdly, in the trim mode, this data would indeed be reported. Isn't it weird and counter-intuitive that the trim mode be more verbose than the explicit mode?

Please note that the RFC examples fails to address this particular situation. Maybe they should be expanded as well?



To me, a correct and simpler formulation of the paragraph would be to remove "by the client":

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.  Non-configuration data nodes containing the schema default value MUST be reported.



the reader can then read the definition for precisions.



Or, if one wants to be more precise and paraphrase the "explicitly set data" definition:

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. Data nodes containing the schema default value MUST be reported if set by the a NETCONF client or other management application by the way of an explicit management operation, and MUST NOT be reported if set by the NETCONF server. Non-configuration data nodes containing the schema default value MUST be reported.



Additionaly, the 3.3.  'explicit' Retrieval Mode paragraph is also ambiguous:
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.



What about data that was set by the NETCONF server to a value other than the schema default value? I believe it should be reported, according to the "explicitly set data" definition, and for the same reasons as the cricicism of the 2.3.1 paragraph. Thus, this part too could be expanded, e.g. to:

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 MUST be reported, expect if set to the schema default value, in which case it MUST NOT be reported. Non-configuration data nodes containing the schema default value MUST be reported.



I hope I was clear enough in my explanations. Please note that this ambiguity is not only problematic in theory but also in practice, for various reasons that I can detail further if necessary.



Best regards,

[cid:image001.png@01D9715E.5D8CBFB0]

Dylan SADOUN
[phone]
[e-mail]<mailto:[e-mail]>

OF/DTSI/DTR/RSB/DIP/TAC CO
DTR : Direction Technique des Réseaux
RSB : Réseaux et Services Broadband
DIP : Département IP
TAC CO : TAC Collecte