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

[Andy Bierman <[e-mail]>]

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]> 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,
>
>
>
>
>
> *Dylan SADOUN*
>
> [phone]
>
> [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
>
>
>