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

[Andy Bierman <[e-mail]>]

Hi,

All these Errata should be rejected.

There is a 2 word correction needed in 1 place.

Andy


On Tue, Apr 18, 2023 at 5:52 AM <[e-mail]> wrote:

> I submitted 3 errata just now:
>
>    1. One technical for the 2.3.1 section
>    2. One technical for the 3.3 section
>    3. One editorial (following advice from
>    https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/,
>    please change its classification if needed) for providing a supplementary
>    example illustrating the case of a NETCONF server setting data to values
>    other than their schema defaults
>
>
>
> I remain reachable by e-mail or telephone for any request.
>
>
>
> Cordialement / Regards.
>
>
>
> *Dylan SADOUN*
>
> [phone]
>
> [e-mail]
>
>
>
>
>
> Orange Restricted
>
> *De :* SADOUN Dylan DTSI/DTR
> *Envoyé :* mardi 18 avril 2023 10:42
> *À :* Jason Sterne (Nokia) <[e-mail]>; Andy Bierman <
> [e-mail]>
> *Cc :* [e-mail]; [e-mail]
> *Objet :* RE: [netconf] Regarding RFC 6243 "With-defaults Capability for
> NETCONF" … the devil is in the defaults
>
>
>
> Hello everyone
>
>
>
> OK, thank you, I am submitting an erratum right now.
>
>
>
> Cordialement / Regards.
>
>
>
> *Dylan SADOUN*
>
> [phone]
>
> [e-mail]
>
>
>
>
>
> Orange Restricted
>
> *De :* Jason Sterne (Nokia) <[e-mail]>
> *Envoyé :* mardi 18 avril 2023 00:57
> *À :* Andy Bierman <[e-mail]>; SADOUN Dylan DTSI/DTR <
> [e-mail]>
> *Cc :* [e-mail]; [e-mail]
> *Objet :* RE: [netconf] Regarding RFC 6243 "With-defaults Capability for
> NETCONF" … the devil is in the defaults
>
>
>
> 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]> 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/
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fprocessing-errata-ietf-stream%2F&data=05%7C01%7Cdylan.sadoun%40orange.com%7Cb86705da7f9540b7694708db3f970c36%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638173690201161442%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=oicNgtoiLC5VjCYFQC22n3dmHhjHoxBq95XK34C7E7A%3D&reserved=0>
> 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
>
>
>
>