Re: [netconf] [Editorial Errata Reported] RFC6243 (7426, 7427 and 7428) combined, with attachments

[tom petch <[e-mail]>]

From: [e-mail]
Sent: Friday, April 28, 2023 10:11


Hello Tom



Could you please explain why removing “by a/the client” would be a mistake? To me, directly referring to the “explicit set data” in the 2.3.1 and 3.3 sections is the simplest and least error-prone formulation to solve the problem. The definition could then be changed (separately) if the consensus is that a server cannot set data on its own.


<tp>

As Andy said, Robert has probably seen enough by now for him to make a judgement on this.


I would refer you to RFC6241 et seq. where the basis of NETCONF, RESTCONF and such like is an implicit architecture of client and server communicating via a protocol.  The word 'client' is a key component in any description; removing it could have all sorts of consequences (but I am not going to delve into what they might be).  The word has served us well.


Tom Petch



Also, I did not find any subtlety on considering a client generic (as opposed to strictly NETCONF) or RFC8040 or RFC8342 changing the soundness of my errata.



Cordialement / Regards.



Dylan SADOUN

[phone]

[e-mail]<mailto:[e-mail]>





Orange Restricted

De : tom petch <[e-mail]>
Envoyé : mercredi 26 avril 2023 18:12
À : SADOUN Dylan DTSI/DTR <[e-mail]>; Andy Bierman <[e-mail]>; [e-mail]
Cc : Jürgen Schönwälder <[e-mail]>; Rob Wilton (rwilton) <[e-mail]>; RFC Errata System <[e-mail]>; Jan Lindblad <[e-mail]>
Objet : Re: [netconf] [Editorial Errata Reported] RFC6243 (7426, 7427 and 7428) combined, with attachments



From: [e-mail]<mailto:[e-mail]>

Sent: Wednesday, April 26, 2023 14:20



Hello



Andy, according to the "1.1.  Terminology" section of RFC 6243, "client" is RFC 6241's definition, which is a NETCONF client, not *any* client.



<tp>

'was' a NETCONF client



You need to consider RFC8040 where the definition of a client is a RESTCONF client and leans on RFC6243, in

part, for its handling of defaults.  I mentioned NMDA and RFC8342 defines a client as

   o  client: An entity that can access YANG-defined data on a server,

      over some network management protocol.

which I would see as a more recent and so relevant definition.



Underlying this, however, is the concept that a user should be able to download the coniguration, upload to a new box and be where it started so it is the changes made by the client that matter.  I would have to dig into the history to see where the text that talks of server setting data comes from but I am convinced that removing the word 'client' is a mistake and that if any change is needed it is where the impression may be given that a server can set data in a manner equivalent to  that of a client (as defined above).



Tom Petch









Then, you say that:

This RFC does not say anywhere "set by server".

It says "that would be set by the server".

Cases 3 and 4 do not exist in this RFC.





I must disagree. Even if the RFC does not define how the NETCONF server MUST or SHOULD apply values on its own in its datastores, it very clearly says that the NETCONF server **can**, and that the values can be other than the schema default ones:



Explicitly set data definition:

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.



2.3.3.  'explicit' <edit-config> and <copy-config> Behavior

[…] A valid 'create' operation attribute for a

   data node that has been set by the server to its schema default value

   MUST succeed. […]

   A valid 'delete' operation attribute for a data node that

   has been set by the server to its schema default value MUST fail with

   a 'data-missing' error-tag.



3.3.  'explicit' Retrieval Mode

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



A.2.  Example Data Set

[…]

In this example, the 'mtu' field for each interface entry is set in
   the following manner:

              +--------------+--------------+--------------+
              | name         | set by       | mtu          |
              +--------------+--------------+--------------+
             | eth0         | client       | 8192         |
              | eth1         | server       | 1500         |
              | eth2         | client       | 9000         |
              | eth3         | client       | 1500         |
              +--------------+--------------+--------------+



Some of your previous responses are also clear on this matter.





To sum up, we are at a crossroad, with 2 possibilities:

1 - EITHER, according to the other RFCs, NETCONF servers CANNOT set values in their datastores on their own, then RFC 6243 is erroneous on this matter and needs correction (I will gladly suggest the errata) (NB: not talking about "a server acting as a client");

2 - OR, NETCONF servers CAN set values in their datastores on their own, in which case I have already made my point about the RFC errors on my errata propositions.



So far, it seems Rob, Jürgen and Jan believes 1 (servers cannot), while at least Andy and me thought 2 (that it was possible for servers).

(Note: on my part, I am fine with 1, but this needs to be clearly written in RFC 6243 among other corrections.)



We must find a consensus on this question to progress further.



Rob, about your last proposals: I must say I prefer mines (the short ones, in the table).





Tom Petch says:

Many of our documents predate the expansion in datastores so I think that you need to specify which datastore(s) you have in mind.  Servers do not set values or perhaps they do in Operational or perhaps they do not.



I am talking about configuration datastores.





Jan says:

I sort of doubt that any server implementor that has made this choice will care much about any clarifying RFC language for those cases.



I beg to differ: it depends on the vendor and your relation with it. In my job, RFCs are the last resort to argue for a complex vendor behaviour change. Thes is why I am trying to correct and clarify the RFC.





Looking forward for discussions about the capacity of NETCONF servers to set values.



Cordialement / Regards.



Dylan SADOUN

[phone]

[e-mail]<mailto:[e-mail]>



De : Andy Bierman <[e-mail]<mailto:[e-mail]>>
Envoyé : vendredi 21 avril 2023 16:34
À : Rob Wilton (rwilton) <[e-mail]<mailto:[e-mail]>>
Cc : Jürgen Schönwälder <[e-mail]<mailto:[e-mail]>>; SADOUN Dylan DTSI/DTR <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; RFC Errata System <[e-mail]<mailto:[e-mail]>>
Objet : Re: [netconf] [Editorial Errata Reported] RFC6243 (7426, 7427 and 7428) combined, with attachments







On Fri, Apr 21, 2023 at 6:29 AM Rob Wilton (rwilton) <[e-mail]<mailto:[e-mail]>> wrote:

Hi,

I also conceptually see this as Jürgen describes.  I.e., even if the device/system chooses to modify the configuration (e.g., due to a linecard insertion) then logically I see that as being equivalent to a system-controlled client that is acting equivalently to an external client.



Note that changes to the server configuration do not have to be done with NETCONF.

Any protocol (internal, proprietary) counts as a client.





But I also agree that the terminology of RFC 6243 states:

   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.


Based on that I would propose the following change for section 3.3: deleting "by a client":

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

NEW:
   When data is retrieved with a <with-defaults> parameter equal to
   'explicit', a data node that was set 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.


For section, 2.3.1, I would propose: copying the sentence from 3.3 regarding conceptual data nodes and deleting "by a client":

OLD:
   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.

NEW:
   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, 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.

I.e., we rely on the definition of "Explicitly set data" in the terminology.  Would everyone be okay with that?





These changes look fine to me (although not really needed at all).

This RFC does not say anywhere "set by server".

It says "that would be set by the server".

Cases 3 and 4 do not exist in this RFC.





Regards,
Rob



Andy




-----Original Message-----
From: Jürgen Schönwälder <[e-mail]<mailto:[e-mail]>>
Sent: 21 April 2023 10:53
To: [e-mail]<mailto:[e-mail]>
Cc: Andy Bierman <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; RFC Errata System <[e-mail]<mailto:[e-mail]>>; Rob Wilton (rwilton) <[e-mail]<mailto:[e-mail]>>
Subject: Re: [netconf] [Editorial Errata Reported] RFC6243 (7426, 7427 and 7428) combined, with attachments

Once again, servers do not arbitrarily set values on their own. They
set values based on client requests, i.e., your cases 3. and 4. do not
really make sense.

/js

On Fri, Apr 21, 2023 at 09:03:43AM +0000, [e-mail]<mailto:[e-mail]> wrote:
> Hello
>
>
>
> I a think that the RFC sections 2.3.1 and 3.3 are contradictory to the "explicitly set data" definition and the RFC intent (as reminded by Andy) and that Rob's suggestion (to copy one sentence from section 3.3 to section 2.3.1) is incomplete.
>
>
>
> Let me go back to the 6 possible cases for a data node's value to:
>
> 1. explicitly set by a NETCONF *client* to a value OTHER than the schema default value
>
> 2. explicitly set by a NETCONF *client* to the *schema default* value
>
> 3. explicitly set by a NETCONF _server_ to a value OTHER than the schema default value
>
> 4. explicitly set by a NETCONF _server_ to the *schema default* value
>
> 5. not explicitly set (neither by NETCONF clients nor the server) and with a schema default value defined in the YANG schema (for the node, or the node's type)
>
> 6. not explicitly set (neither by NETCONF clients nor the server) and without any schema default defined in YANG (neither for the node nor the node's type). That case is trivial, the node is not valued. One could argue this is not the RFC subject. I will skip this case entirely afterwards.
>
>
>
> It is clear that cases 1 to 4 are explicilty set data (as per the RFC definition), and NOT cases 5 and 6.
>
>
>
> Here is a table summarizing the different versions of section 2.3.1 and 3.3:
>
>
>
>
> Erratum number
>
> 7246
>
> 7247
>
>
> RFC section
>
> 2.3.1
>
> 3.3
>
>
> 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.
>
> 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.
>
>
> Problem with the original text
>
> Only cases 1, 2 and 5 are covered, but cases 3 and 4 are NOT covered.
>
> The implied meaning is contradictory to the "explicitly set data" definition and the RFC intent (cf. my previous e-mails).
> Therefore the section is currently erroneous.
>
> Only cases 2, 4 and 5 are covered, but cases 1 and 3 are NOT covered.
>
> Note: case 1 is the most important one!
>
> Therefore the section is currently erroneous.
>
>
> Andy's suggestion (e-mail before the errata)
>
> 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 or the server, even if they contain the schema default value. Non-configuration data nodes containing the schema default value MUST be reported.
>
> n/a
>
>
> Problems with Andy's suggestion
>
> This only adds a faulty case 4, because data set by the server to the schema default value MUST NOT be reported (cf. the "explicitly set data" definition).
>
> Case 3 is not covered.
>
> Therefore this version is (more) erroneous too.
>
> n/a
>
>
> Rob's suggestion
>
> 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.
>
> n/a
>
>
> Problems with Rob's suggestion
>
> In addition to cases 1, 2 and 5, this version adds case 4, BUT it still misses case 3 (just like the original 3.3 section).
>
> Therefore the section is still erroneous.
>
> n/a
>
>
> My previous suggestion
>
> 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. This means that data nodes containing the schema default value MUST be reported if set by a NETCONF client, but MUST NOT be reported if set by the NETCONF server. Data nodes set by the NETCONF server to values other than their schema default values MUST be reported. Non-configuration data nodes containing the schema default value MUST be reported.
>
> 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.
>
>
> Why I think my suggestion is necessary
>
> In addition to cases 1, 2 and 5, this version adds cases 3 and 4, making it complete and correct in regard to the "explicitly set data" definition and the RFC intent.
>
> In addition to cases 2, 4 and 5, this version adds case 3. One could argue that case 1 is still not covered…
>
>
> My new suggestion (alternative)
>
> 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.
>
> When data is retrieved with a <with-defaults> parameter equal to 'explicit', data nodes MUST be reported if explicitly set. Non-configuration data nodes containing the schema default value MUST be reported.
>
>
> Goal of the new suggestion
>
> To be clear and brief, minimize the erratum, and maximize sections 2.3.1 and 3.3 harmony. The reader must then report to the "explicitly set data" definition which covers all cases (in one place).
>
> To be clear and brief, minimize the erratum, and maximize sections 2.3.1 and 3.3 harmony. The reader must then report to the "explicitly set data" definition which covers all cases (in one place).
>
>
>
> I believe to have proven that sections 2.3.1 and 3.3 of the RFC on the explicit mode are erroneous and that the errata are legitimate. Also, that Rob's suggestion is incomplete and Andy's in erroneous.
>
>
>

> Please not, my point is not to re-litigate or re-write the RFC but to fix its "bugs" (cf.  <https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/> https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/).

>
> Andy, you said:
>
> "The intent in section 2.3.1 is that all explicitly set data is returned."
>
> I think that my proposed corrections are exactly "a clear resolution in line with the original intent" (cf. the 4th point of the guidelines for review).
>
>
>
> Andy, Rob, if you do not agree, could you please explain how the existing text or Rob's suggestion cover all cases properly and why my propositions do not?
>
>
>
> I appreciate your attention to this matter and look forward to hearing back from you.
>
>
>
> PS: I will be back on my e-mails on Wednesday.
>
>
>
> Dylan SADOUN
>
> [phone]
>
>  <mailto:[e-mail]<mailto:[e-mail]>> [e-mail]<mailto:[e-mail]>
>
>
>
> De : Andy Bierman <[e-mail]<mailto:[e-mail]>>
> Envoyé : mercredi 19 avril 2023 21:44
> À : Jürgen Schönwälder <[e-mail]<mailto:[e-mail]>>; SADOUN Dylan DTSI/DTR <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
> Objet : Re: [netconf] [Editorial Errata Reported] RFC6243 (7426, 7427 and 7428) combined, with attachments
>
>
>
>
>
>
>
> On Wed, Apr 19, 2023 at 12:21 PM Jürgen Schönwälder < <mailto:[e-mail]<mailto:[e-mail]>> [e-mail]<mailto:[e-mail]>> wrote:
>
> The original design was that the NETCONF sets values based on client
> requests to modify configuration datastores. As the name suggests, its
> a configuration management protocol and it is not the server's job to
> create configuration on its own.
>
> Yes, there are corner cases where a server may fill in values,
> but this does not change the general idea that clients control
> the manipulation of configuration data.
>
>
>
> I think the small update from Rob fixes the ambiguity in sec. 2.3.1.
>
>
>
> A YANG default is the value that is used if no instance of the data node exists.
>
> The major vendors never really agreed on EXACTLY what it means for a data node instance to exist.
>
> It is very implementation-specific.
>
> It is also not really a problem if "merge" and "remove" are used instead of "create" and "delete",
>
>
>
> This RFC distinguishes between the 2 implementation-specific cases (instance and no-instance).
>
> The Errata process should not be used to re-litigate and re-write the RFC.
>
>
>
> /js
>
>
>
> Andy
>
>
>
>
> On Wed, Apr 19, 2023 at 05:35:54PM +0000, [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>  wrote:
> > Hello
> >
> >
> >
> > Thank you all for your quick answers but I must say that I mostly disagree.
> >
> >
> >
> > All three errata are linked and twisted and therefore I propose to answer
> > all of them globally, before diving in each erratum distinctly later if
> > necessary.
> >
> > Also, bear with me, I struggle to be brief in English.
> >
> >
> >
> > There are 6 possible cases for a data node's value:
> >
> > 1. explicitly set by a NETCONF *client* to a value OTHER than the schema
> > default value
> >
> > 2. explicitly set by a NETCONF *client* to the *schema default* value
> >
> > 3. explicitly set by a NETCONF _server_ to a value OTHER than the schema
> > default value <== this is the killer one!!
> >
> > 4. explicitly set by a NETCONF _server_ to the *schema default* value
> >
> > 5. not explicitly set (neither by NETCONF clients nor the server) and with a
> > schema default value defined in the YANG schema (for the node, or the node's
> > type)
> >
> > 6. not explicitly set (neither by NETCONF clients nor the server) and
> > without any schema default defined in YANG (neither for the node nor the
> > node's type). That case is trivial, the node is not valued. One could argue
> > this is not the RFC subject. I will skip this case entirely afterwards.
> >
> >
> >
> > Note 1: Rob is rightly questioning a NETCONF server being able to set data.
> > Please read further on this matter.
> >
> > Note 2: a schema default value might be the node's or the node's type's, I
> > will not differentiate, and just say "schema default value".
> >
> >
> >
> > According to the "explicitly set data" RFC definition, cases 1, 2 and 3 are
> > explicitly set data, while others are not (4, 5 and 6).
> >
> > Sections 2.3.1 and 3.3 (and appendix A examples) are not clear on case 3
> > (and sometimes others as well).
> >
> >
> >
> >
> >
> >
> >
> > On section 2.3.1.
> >
> >
> >
> >
> >
> > Andy, in your 3.3 erratum response (7247), you argue that:
> >
> >             "It is not possible for a node to have a value other than the
> > YANG default and not be explicitly set."
> >
> > I agree with you (I wish this would be in the RFC!), this is true based
> > solely on the "explicitly set" definition, BUT I also believe that the 2.3.1
> > section, by partially paraphrasing the definition, is ambiguous, if not
> > prone to misunderstanding.
> >
> >
> >
> > >From section 2.3.1:
> >
> >             "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"
> >
> > Andy, in your 2.3.1 (7246) erratum response, you first say:
> >
> >             "The intent in section 2.3.1 is that all explicitly set data is
> > returned."
> >
> > This is also how I understood the intent. However, the section formulation
> > seems wrong.
> >
> > Let us review the different cases:
> >
> > - cases 1 and 2 are directly covered
> >
> > - cases 4 and 5 are not directly covered in that section, but may be
> > inferred from the definition
> >
> > The main problem is for case 3. Indeed, by precising:
> >
> >             "*if* explicitly set **by the client**, *even if* they contain
> > the schema default value"
> >
> > (emphasis and notes mine)
> >
> > it leads to think that the opposite it NOT true, which is that if explicitly
> > set **by the server**, there is no absolute requirement for the NETCONF
> > server to report this data. To put it otherwise, this section is open to
> > interpretation on case 3: should the data be reported or not? We know the
> > answer thanks to the "schema default data" definition: it depends! If set to
> > the schema default value (case 4): NO, otherwise (case 3): YES.
> >
> >
> >
> > Although it is indeed the intent of this section, it is never clearly
> > written in the RFC that the explicit mode means reporting only explicitly
> > set data. This is why I propose to be more explicit (in the formulation).
> >
> >
> >
> > Note: you add "There is a subtle difference between a server using the YANG
> > default value because no instance exists and a server creating an instance
> > that equals the YANG default value.". I agree with you, but I fail to
> > understand why my addendum would be in contradiction.
> >
> >
> >
> >
> >
> > Rob, in your 2.3.1 (7426) erratum response, you rightly point out that the
> > section is ambiguous about
> >
> >             "default values that haven’t been explicit set by the client"
> >
> > (cases 4 and 5)
> >
> > I agree, this is my point and why I propose to add:
> >
> >             "This means that data nodes containing the schema default value
> > MUST be reported if set by a NETCONF client but MUST NOT be reported if set
> > by the NETCONF server."
> >
> > (cases 2 and 4)
> >
> > in accordance with the "explicitly set data" definition. One might say that
> > the RFC is not ambiguous as the definition is clear, however the section
> > partially paraphrasing the definition seems odd, and I believe the clearer
> > the better, even at the expense of (very small) redundancy.
> >
> >
> >
> > You ask:
> >
> >             "Dylan, is this what you were trying to clarify?"
> >
> > Well, yes but partially (again, cases number!). I think the section is also
> > ambiguous on values set by the server to values other than the schema
> > default values (case 3), hence I also add:
> >
> >             "Data nodes set by the NETCONF server to values other than their
> > schema default values MUST be reported."
> >
> > This is also why I would push for my proposed version over yours (or the
> > original text).
> >
> > Note : case 5 seems obvious enough not be added.
> >
> >
> >
> >
> >
> >
> >
> > On section 3.3 now.
> >
> >
> >
> >
> >
> > Andy, in your 3.3 erratum response (7247), you argue that the case of a node
> > that is not explicitly set is clear (case number 5). I agree with you.
> > However, I believe that case number 3 is NOT, hence my erratum which adds
> > for clarity's sake:
> >
> >             "A conceptual data node that would be set by the server to a
> > value other than its schema default value MUST be reported."
> >
> > Maybe, it is the "conceptual" part of my sentence that is wrong? I am not
> > quite sure what it means in the RFC. I only paraphrased the previous
> > sentence for harmony. Is a "conceptual data node" a node that is not
> > instantiated, but implicitly bears a value as defined in the YANG schema
> > "default"? In that case, let me rephrase the added sentence of the erratum
> > by removing "conceptual":
> >
> >             "A data node that would be set by the server to a value other
> > than its schema default value MUST be reported."
> >
> >
> >
> > Is it better this way?
> >
> >
> >
> > Note: A proposed alternative (by e-mail from Andy) was to remove "by the
> > client", but that would be wrong for case 4!!
> >
> >
> >
> >
> >
> >
> >
> > On both sections.
> >
> >
> >
> > Rob, in your 3.3 erratum response (7247), you rightly point out that a
> > NETCONF server setting configuration is a bit odd in NETCONF. I must agree
> > with you... however RFC 6243 "explicitly set data" definition states that:
> >
> >             "Any value set by the NETCONF server that is not the schema
> > defined default value is also considered explicitly set data.".
> >
> > Also, some other bits of the RFC also speak of NETCONF servers setting data:
> >
> > - section 2.3.3: "data node that has been set by the server" (twice)
> >
> > - section 3.3: "A conceptual data node that would be set by the server"
> >
> > Therefore, I think the NETCONF server being able to set data makes sense in
> > this RFC. In practice.
> >
> >
> >
> > You add that
> >
> >             "Hence, if a server is setting some of the configuration to a
> > non default-value then one could perhaps argue [...] that logically, the
> > server is also internally acting as a NETCONF/RESTCONF client"
> >
> > While I understand how one might indeed turn things in this convoluted way
> > in some particular use cases, I also think that, based on the definition, a
> > server setting data by itself must be considered first.
> >
> >
> >
> >
> >
> >
> >
> > As for the Appendix A. examples section (7428) erratum: this is to showcase
> > the case 3. I believe it to enrich the RFC, given the complexity of the
> > whole thing. Please refer to them if the present explanations are too
> > cryptic.
> >
> >
> >
> >
> >
> > As a conclusion, please acknowledge that the RFC makes it *really* difficult
> > to prove (to someone that would think otherwise) that case 3 IS explicitly
> > set data and therefore should be reported by the NETCONF server in the
> > explicit mode. One needs to discuss the whole RFC intent, rather than simply
> > having to point to the right section. This is very problematic and led some
> > manufacturers to implement the explicit mode differently.
> >
> >
> >
> >
> >
> > As a finishing note, I must admit that my errata notes are vague and
> > imprecise. I can, of course, rewrite them if necessary. I was trying to be
> > brief given my preceding explanatory e-mails and the fact that I struggle to
> > explain these subtleties briefly.
> >
> >
> >
> >
> >
> > Attached:
> >
> > - the 3 errata submissions with answers
> >
> > - the preceding e-mails
> >
> >
> >
> > If you are still not convinced, I would be glad to understand how case 3 is
> > correctly covered in section 2.3.1 and 3.3.
> >
> >
> >
> > Thank you for taking the time to review this and share your thoughts before
> > I propose errata editions.
> >
>
> > Date: Tue, 18 Apr 2023 19:52:04 +0200
> > From: Andy Bierman <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> >
> > To: RFC Errata System <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> >
> > Cc: SADOUN Dylan DTSI/DTR <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> >,
> >  [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> , [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
> > Subject: Re: [Editorial Errata Reported] RFC6243 (7428)
> > Message-ID: <CABCOCHQ8m=A37p=[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> >
> > X-Mailer: Microsoft Outlook 16.0
> >
> > Hi,
> >
> > This Errata should be rejected.
> > There is no need to add an additional "eth4" interface entry to the examples
> > in Appendix A.
> >
> >
> > Andy
> >
> >
> > On Tue, Apr 18, 2023 at 5:38 AM RFC Errata System <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
> > <mailto:[e-mail]<mailto:[e-mail]> <mailto:[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/eid7428 <https://www.rfc-editor.org/errata/eid7428>
> > <https://www.rfc-editor.org/errata/eid7428 <https://www.rfc-editor.org/errata/eid7428> >
> >
> > --------------------------------------
> > Type: Editorial
> > Reported by: Dylan Sadoun <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
> > <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> > >
> >
> > Section: Appendix A
> >
> > Original Text
> > -------------
> > A.2.  Example Data Set
> >
> > [...]
> >
> >   <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> >     <interfaces xmlns="http://example.com/ns/interfaces <http://example.com/ns/interfaces>
> > <http://example.com/ns/interfaces <http://example.com/ns/interfaces> >
> > ">
> >       <interface>
> >         <name>eth0</name>
> >         <mtu>8192</mtu>
> >         <status>up</status>
> >       </interface>
> >       <interface>
> >         <name>eth1</name>
> >         <mtu>1500</mtu>
> >         <status>up</status>
> >       </interface>
> >       <interface>
> >         <name>eth2</name>
> >         <mtu>9000</mtu>
> >         <status>not feeling so good</status>
> >       </interface>
> >       <interface>
> >         <name>eth3</name>
> >         <mtu>1500</mtu>
> >         <status>waking up</status>
> >       </interface>
> >     </interfaces>
> >   </data>
> >
> >   In this example, the 'mtu' field for each interface entry is set in
> >    the following manner:
> >
> >               +--------------+--------------+--------------+
> >               | name         | set by       | mtu          |
> >               +--------------+--------------+--------------+
> >               | eth0         | client       | 8192         |
> >               | eth1         | server       | 1500         |
> >               | eth2         | client       | 9000         |
> >               | eth3         | client       | 1500         |
> >               +--------------+--------------+--------------+
> >
> > [...]
> >
> > A.3.1.  <with-defaults> = 'report-all'
> >
> >    The behavior of the <with-defaults> parameter handling for the value
> >    'report-all' is demonstrated in this example.
> >
> >     <rpc message-id="101"
> >          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> >       <get>
> >         <filter type="subtree">
> >           <interfaces xmlns="http://example.com/ns/interfaces <http://example.com/ns/interfaces>
> > <http://example.com/ns/interfaces <http://example.com/ns/interfaces> >
> > "/>
> >         </filter>
> >         <with-defaults
> >          xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults">
> >           report-all
> >         </with-defaults>
> >       </get>
> >     </rpc>
> >
> >     <rpc-reply message-id="101"
> >                xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> >       <data>
> >         <interfaces xmlns="http://example.com/ns/interfaces <http://example.com/ns/interfaces>
> > <http://example.com/ns/interfaces <http://example.com/ns/interfaces> >
> > ">
> >           <interface>
> >             <name>eth0</name>
> >             <mtu>8192</mtu>
> >             <status>up</status>
> >           </interface>
> >           <interface>
> >             <name>eth1</name>
> >             <mtu>1500</mtu>
> >             <status>up</status>
> >           </interface>
> >           <interface>
> >             <name>eth2</name>
> >             <mtu>9000</mtu>
> >             <status>not feeling so good</status>
> >           </interface>
> >           <interface>
> >             <name>eth3</name>
> >             <mtu>1500</mtu>
> >             <status>waking up</status>
> >           </interface>
> >         </interfaces>
> >       </data>
> >     </rpc-reply>
> >
> > A.3.2.  <with-defaults> = 'report-all-tagged'
> >
> > [...]
> >
> >     <rpc message-id="102"
> >          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> >       <get>
> >         <filter type="subtree">
> >           <interfaces xmlns="http://example.com/ns/interfaces <http://example.com/ns/interfaces>

> > <http://example.com/ns/interfaces <http://example.com/ns/interfaces> >

> > "/>
> >         </filter>
> >         <with-defaults
> >          xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults">
> >           report-all-tagged
> >         </with-defaults>
> >       </get>
> >     </rpc>
> >
> >     <rpc-reply message-id="102"
> >                xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
> >                xmlns:wd="urn:ietf:params:xml:ns:netconf:default:1.0">
> >       <data>
> >         <interfaces xmlns="http://example.com/ns/interfaces <http://example.com/ns/interfaces>
> > <http://example.com/ns/interfaces <http://example.com/ns/interfaces> >
> > ">
> >           <interface>
> >             <name>eth0</name>
> >             <mtu>8192</mtu>
> >             <status wd:default="true">up</status>
> >           </interface>
> >           <interface>
> >             <name>eth1</name>
> >             <mtu wd:default="true">1500</mtu>
> >             <status wd:default="true">up</status>
> >           </interface>
> >           <interface>
> >             <name>eth2</name>
> >             <mtu>9000</mtu>
> >             <status>not feeling so good</status>
> >           </interface>
> >           <interface>
> >             <name>eth3</name>
> >             <mtu wd:default="true">1500</mtu>
> >             <status>waking up</status>
> >           </interface>
> >         </interfaces>
> >       </data>
> >     </rpc-reply>
> >
> > A.3.3.  <with-defaults> = 'trim'
> >
> >    The behavior of the <with-defaults> parameter handling for the value
> >    'trim' is demonstrated in this example.
> >
> >     <rpc message-id="103"
> >          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> >       <get>
> >         <filter type="subtree">
> >           <interfaces xmlns="http://example.com/ns/interfaces <http://example.com/ns/interfaces>
> > <http://example.com/ns/interfaces <http://example.com/ns/interfaces> >
> > "/>
> >         </filter>
> >         <with-defaults
> >          xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults">
> >           trim
> >         </with-defaults>
> >       </get>
> >     </rpc>
> >
> >     <rpc-reply message-id="103"
> >                xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> >       <data>
> >         <interfaces xmlns="http://example.com/ns/interfaces <http://example.com/ns/interfaces>
> > <http://example.com/ns/interfaces <http://example.com/ns/interfaces> >
> > ">
> >           <interface>
> >             <name>eth0</name>
> >             <mtu>8192</mtu>
> >           </interface>
> >           <interface>
> >             <name>eth1</name>
> >           </interface>
> >           <interface>
> >             <name>eth2</name>
> >             <mtu>9000</mtu>
> >             <status>not feeling so good</status>
> >           </interface>
> >           <interface>
> >             <name>eth3</name>
> >             <status>waking up</status>
> >           </interface>
> >         </interfaces>
> >       </data>
> >     </rpc-reply>
> >
> > A.3.4.  <with-defaults> = 'explicit'
> >
> >    The behavior of the <with-defaults> parameter handling for the value
> >    'explicit' is demonstrated in this example.
> >
> >     <rpc message-id="104"
> >          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> >       <get>
> >         <filter type="subtree">
> >           <interfaces xmlns="http://example.com/ns/interfaces <http://example.com/ns/interfaces>
> > <http://example.com/ns/interfaces <http://example.com/ns/interfaces> >
> > "/>
> >         </filter>
> >         <with-defaults
> >          xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults">
> >           explicit
> >         </with-defaults>
> >       </get>
> >     </rpc>
> >
> >     <rpc-reply message-id="104"
> >                xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> >       <data>
> >         <interfaces xmlns="http://example.com/ns/interfaces <http://example.com/ns/interfaces>
> > <http://example.com/ns/interfaces <http://example.com/ns/interfaces> >
> > ">
> >           <interface>
> >             <name>eth0</name>
> >             <mtu>8192</mtu>
> >             <status>up</status>
> >           </interface>
> >           <interface>
> >             <name>eth1</name>
> >             <status>up</status>
> >           </interface>
> >           <interface>
> >             <name>eth2</name>
> >             <mtu>9000</mtu>
> >             <status>not feeling so good</status>
> >           </interface>
> >           <interface>
> >             <name>eth3</name>
> >             <mtu>1500</mtu>
> >             <status>waking up</status>
> >           </interface>
> >         </interfaces>
> >       </data>
> >     </rpc-reply>
> >
> > Corrected Text
> > --------------
> > A.2.  Example Data Set
> >
> > [...]
> >
> >   <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> >     <interfaces xmlns="http://example.com/ns/interfaces <http://example.com/ns/interfaces>
> > <http://example.com/ns/interfaces <http://example.com/ns/interfaces> >
> > ">
> >       <interface>
> >         <name>eth0</name>
> >         <mtu>8192</mtu>
> >         <status>up</status>
> >       </interface>
> >       <interface>
> >         <name>eth1</name>
> >         <mtu>1500</mtu>
> >         <status>up</status>
> >       </interface>
> >       <interface>
> >         <name>eth2</name>
> >         <mtu>9000</mtu>
> >         <status>not feeling so good</status>
> >       </interface>
> >       <interface>
> >         <name>eth3</name>
> >         <mtu>1500</mtu>
> >         <status>waking up</status>
> >       </interface>
> >       <interface>
> >         <name>eth4</name>
> >         <mtu>9112</mtu>
> >         <status>better call for help</status>
> >       </interface>
> >     </interfaces>
> >   </data>
> >
> >   In this example, the 'mtu' field for each interface entry is set in
> >    the following manner:
> >
> >               +--------------+--------------+--------------+
> >               | name         | set by       | mtu          |
> >               +--------------+--------------+--------------+
> >               | eth0         | client       | 8192         |
> >               | eth1         | server       | 1500         |
> >               | eth2         | client       | 9000         |
> >               | eth3         | client       | 1500         |
> >               | eth4         | server       | 9112         |
> >               +--------------+--------------+--------------+
> >
> > [...]
> >
> > A.3.1.  <with-defaults> = 'report-all'
> >
> >    The behavior of the <with-defaults> parameter handling for the value
> >    'report-all' is demonstrated in this example.
> >
> >     <rpc message-id="101"
> >          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> >       <get>
> >         <filter type="subtree">
> >           <interfaces xmlns="http://example.com/ns/interfaces <http://example.com/ns/interfaces>
> > <http://example.com/ns/interfaces <http://example.com/ns/interfaces> >
> > "/>
> >         </filter>
> >         <with-defaults
> >          xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults">
> >           report-all
> >         </with-defaults>
> >       </get>
> >     </rpc>
> >
> >     <rpc-reply message-id="101"
> >                xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> >       <data>
> >         <interfaces xmlns="http://example.com/ns/interfaces <http://example.com/ns/interfaces>
> > <http://example.com/ns/interfaces <http://example.com/ns/interfaces> >
> > ">
> >           <interface>
> >             <name>eth0</name>
> >             <mtu>8192</mtu>
> >             <status>up</status>
> >           </interface>
> >           <interface>
> >             <name>eth1</name>
> >             <mtu>1500</mtu>
> >             <status>up</status>
> >           </interface>
> >           <interface>
> >             <name>eth2</name>
> >             <mtu>9000</mtu>
> >             <status>not feeling so good</status>
> >           </interface>
> >           <interface>
> >             <name>eth3</name>
> >             <mtu>1500</mtu>
> >             <status>waking up</status>
> >           </interface>
> >           <interface>
> >             <name>eth4</name>
> >             <mtu>9112</mtu>
> >             <status>better call for help</status>
> >           </interface>
> >         </interfaces>
> >       </data>
> >     </rpc-reply>
> >
> > A.3.2.  <with-defaults> = 'report-all-tagged'
> >
> > [...]
> >
> >     <rpc message-id="102"
> >          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> >       <get>
> >         <filter type="subtree">
> >           <interfaces xmlns="http://example.com/ns/interfaces <http://example.com/ns/interfaces>
> > <http://example.com/ns/interfaces <http://example.com/ns/interfaces> >
> > "/>
> >         </filter>
> >         <with-defaults
> >          xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults">
> >           report-all-tagged
> >         </with-defaults>
> >       </get>
> >     </rpc>
> >
> >     <rpc-reply message-id="102"
> >                xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
> >                xmlns:wd="urn:ietf:params:xml:ns:netconf:default:1.0">
> >       <data>
> >         <interfaces xmlns="http://example.com/ns/interfaces <http://example.com/ns/interfaces>
> > <http://example.com/ns/interfaces <http://example.com/ns/interfaces> >
> > ">
> >           <interface>
> >             <name>eth0</name>
> >             <mtu>8192</mtu>
> >             <status wd:default="true">up</status>
> >           </interface>
> >           <interface>
> >             <name>eth1</name>
> >             <mtu wd:default="true">1500</mtu>
> >             <status wd:default="true">up</status>
> >           </interface>
> >           <interface>
> >             <name>eth2</name>
> >             <mtu>9000</mtu>
> >             <status>not feeling so good</status>
> >           </interface>
> >           <interface>
> >             <name>eth3</name>
> >             <mtu wd:default="true">1500</mtu>
> >             <status>waking up</status>
> >           </interface>
> >           <interface>
> >             <name>eth4</name>
> >             <mtu>9112</mtu>
> >             <status>better call for help</status>
> >           </interface>
> >         </interfaces>
> >       </data>
> >     </rpc-reply>
> >
> > A.3.3.  <with-defaults> = 'trim'
> >
> >    The behavior of the <with-defaults> parameter handling for the value
> >    'trim' is demonstrated in this example.
> >
> >     <rpc message-id="103"
> >          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> >       <get>
> >         <filter type="subtree">
> >           <interfaces xmlns="http://example.com/ns/interfaces <http://example.com/ns/interfaces>
> > <http://example.com/ns/interfaces <http://example.com/ns/interfaces> >
> > "/>
> >         </filter>
> >         <with-defaults
> >          xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults">
> >           trim
> >         </with-defaults>
> >       </get>
> >     </rpc>
> >
> >     <rpc-reply message-id="103"
> >                xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> >       <data>
> >         <interfaces xmlns="http://example.com/ns/interfaces <http://example.com/ns/interfaces>
> > <http://example.com/ns/interfaces <http://example.com/ns/interfaces> >
> > ">
> >           <interface>
> >             <name>eth0</name>
> >             <mtu>8192</mtu>
> >           </interface>
> >           <interface>
> >             <name>eth1</name>
> >           </interface>
> >           <interface>
> >             <name>eth2</name>
> >             <mtu>9000</mtu>
> >             <status>not feeling so good</status>
> >           </interface>
> >           <interface>
> >             <name>eth3</name>
> >             <status>waking up</status>
> >           </interface>
> >           <interface>
> >             <name>eth4</name>
> >             <mtu>9112</mtu>
> >             <status>better call for help</status>
> >           </interface>
> >         </interfaces>
> >       </data>
> >     </rpc-reply>
> >
> > A.3.4.  <with-defaults> = 'explicit'
> >
> >    The behavior of the <with-defaults> parameter handling for the value
> >    'explicit' is demonstrated in this example.
> >
> >     <rpc message-id="104"
> >          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> >       <get>
> >         <filter type="subtree">
> >           <interfaces xmlns="http://example.com/ns/interfaces <http://example.com/ns/interfaces>
> > <http://example.com/ns/interfaces <http://example.com/ns/interfaces> >
> > "/>
> >         </filter>
> >         <with-defaults
> >          xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults">
> >           explicit
> >         </with-defaults>
> >       </get>
> >     </rpc>
> >
> >     <rpc-reply message-id="104"
> >                xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> >       <data>
> >         <interfaces xmlns="http://example.com/ns/interfaces <http://example.com/ns/interfaces>
> > <http://example.com/ns/interfaces <http://example.com/ns/interfaces> >
> > ">
> >           <interface>
> >             <name>eth0</name>
> >             <mtu>8192</mtu>
> >             <status>up</status>
> >           </interface>
> >           <interface>
> >             <name>eth1</name>
> >             <status>up</status>
> >           </interface>
> >           <interface>
> >             <name>eth2</name>
> >             <mtu>9000</mtu>
> >             <status>not feeling so good</status>
> >           </interface>
> >           <interface>
> >             <name>eth3</name>
> >             <mtu>1500</mtu>
> >             <status>waking up</status>
> >           </interface>
> >           <interface>
> >             <name>eth4</name>
> >             <mtu>9112</mtu>
> >             <status>better call for help</status>
> >           </interface>
> >         </interfaces>
> >       </data>
> >     </rpc-reply>
> >
> > Notes
> > -----
> > This erratum expands existing examples to include the case of a server setting
> > data nodes to values other than their default schema values. This echoes the
> > other errata about sections 2.3.1 and 3.3 and the explicit retrieval mode.
> >
> > 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
> >
> >
>
> > Date: Tue, 18 Apr 2023 19:42:31 +0200
> > From: Andy Bierman <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> >
> > To: "Rob Wilton (rwilton)" <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> >
> > Cc: RFC Errata System <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> >,
> >  [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> , [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> , [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> ,
> >  [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> , SADOUN Dylan DTSI/DTR <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> >,
> >  [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
> > Subject: Re: [Technical Errata Reported] RFC6243 (7426)
> > Message-ID: <CABCOCHRvVLBaWUqZ88O5iPsfc9bXYOO7tT2Yh0=[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> >
> > X-Mailer: Microsoft Outlook 16.0
> >
> >
> >
> > On Tue, Apr 18, 2023 at 9:55 AM Rob Wilton (rwilton) <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
> > <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> > > wrote:
> >
> >
> > Hi Andy, Dylan,
> >
> >
> >
> > I don’t think that the proposed text is quite right, but there might be
> > something worth clarifying here.
> >
> >
> >
> > I.e., I believe that I understand what section 2.3.1 is meaning, but it doesn’t
> > define what to do for default values that haven’t been explicit set by the
> > client.  I.e., arguably, it looks servers are free to choose whether to
> > include or not include data nodes with a default value that haven’t been set
> > by the client (which I don’t think is the intent).  Note, the logically
> > equivalent section in 3.3 is more explicit that they MUST NOT be reported:
> >
> >
> >
> > <quote>
> >
> >  <https://www.rfc-editor.org/rfc/rfc6243#section-3.3 <https://www.rfc-editor.org/rfc/rfc6243#section-3.3> >
> > 3.3.  'explicit' Retrieval Mode
> >
> >
> >
> >    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.
> >
> > <end quote>
> >
> >
> >
> > Hence, I’m wondering whether section 2.3.1 should take this sentence from
> > section 3.3:  “A conceptual data node that would be
> >
> >    set by the server to the schema default value MUST NOT be reported.”, i.e.,
> > actually read something like:
> >
> >
> >
> > <proposed>
> >
> >  <https://www.rfc-editor.org/rfc/rfc6243#section-2.3.1 <https://www.rfc-editor.org/rfc/rfc6243#section-2.3.1> >
> > 2.3.1.  'explicit' Basic Mode Retrieval
> >
> >    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.
> >
> > <end proposed>
> >
> >
> >
> > Dylan, is this what you were trying to clarify?  Andy, does this change your
> > opinion?
> >
> >
> >
> >
> >
> > Your change to 2.3.1 is consistent with WG intent, so no objection.
> >
> >
> >
> >
> >
> > Thanks,
> >
> > Rob
> >
> >
> > Andy
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > From: Andy Bierman <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>  <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> > >
> > Sent: 18 April 2023 17:18
> > To: RFC Errata System <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
> > <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> > >
> > Cc: [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>  <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> > ;
> > [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>  <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> > ; Rob Wilton (rwilton)
> > <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>  <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> > >; [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
> > <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> > ; [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
> > <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> > ; [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
> > <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> > ; [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>  <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> >
> > Subject: Re: [Technical Errata Reported] RFC6243 (7426)
> >
> >
> >
> > Hi,
> >
> >
> >
> > This Errata should be rejected.
> >
> > The intent in section 2.3.1 is that all explicitly set data is returned.
> >
> > The proposed new text does not reflect this intent.
> >
> >
> >
> > There is a subtle difference between a server using the YANG default value
> > because no instance exists
> >
> > and a server creating an instance that equals the YANG default value.  The
> > server implementation
> >
> > needs to distinguish between them. The "create" and "delete" edit operations
> > are impacted by this distinction.
> >
> >
> >
> >
> >
> > Andy
> >
> >
> >
> >
> >
> > On Tue, Apr 18, 2023 at 5:35 AM RFC Errata System <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
> > <mailto:[e-mail]<mailto:[e-mail]> <mailto:[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/eid7426 <https://www.rfc-editor.org/errata/eid7426>
> > <https://www.rfc-editor.org/errata/eid7426 <https://www.rfc-editor.org/errata/eid7426> >
> >
> > --------------------------------------
> > Type: Technical
> > Reported by: Dylan Sadoun <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
> > <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> > >
> >
> > 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. This means that data nodes containing the schema default value
> > MUST be reported if set by a NETCONF client, but MUST NOT be reported if set
> > by the NETCONF server. Data nodes set by the NETCONF server to values other
> > than their schema default values 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 2.3.1 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
> >
>
> > Date: Tue, 18 Apr 2023 19:11:39 +0200
> > From: "Rob Wilton (rwilton)" <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> >
> > To: Andy Bierman <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> >, RFC Errata System
> >  <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> >, SADOUN Dylan DTSI/DTR
> >  <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> >, [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
> > Cc: [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> , [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> ,
> >  [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> , [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
> > Subject: RE: [Technical Errata Reported] RFC6243 (7427)
> > Message-ID: <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> >
> > X-Mailer: Microsoft Outlook 16.0
> >
> > 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]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> >
> > Sent: 18 April 2023 17:54
> > To: RFC Errata System <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> >
> > Cc: [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> ; [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> ; Rob Wilton (rwilton)
> > <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> >; [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> ; [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> ;
> > [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> ; [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[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]> <mailto:[e-mail]<mailto:[e-mail]>>
> > <mailto:[e-mail]<mailto:[e-mail]> <mailto:[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 <https://www.rfc-editor.org/errata/eid7427>
> > <https://www.rfc-editor.org/errata/eid7427 <https://www.rfc-editor.org/errata/eid7427> >
> >
> > --------------------------------------
> > Type: Technical
> > Reported by: Dylan Sadoun <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
> > <mailto:[e-mail]<mailto:[e-mail]> <mailto:[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
> >
>
> > Date: Tue, 18 Apr 2023 14:52:50 +0200
> > From: [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
> > To: "Jason Sterne (Nokia)" <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> >, Andy Bierman
> >  <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> >
> > Cc: [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> , [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
> > Subject: RE: [netconf]  Regarding RFC 6243 "With-defaults Capability for
> >  NETCONF" … the devil is in the defaults
> > Message-ID: <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> >
> > X-Mailer: Microsoft Outlook 16.0
> >
> > 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/ <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]
> >
> >  <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> > [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
> >
> >
> >
> >
> >
> > Orange Restricted
> >
> > De : SADOUN Dylan DTSI/DTR
> > Envoyé : mardi 18 avril 2023 10:42
> > À : Jason Sterne (Nokia) <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> >; Andy Bierman <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> >
> > Cc : [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> ; [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[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]
> >
> >  <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> > [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
> >
> >
> >
> >
> >
> > Orange Restricted
> >
> > De : Jason Sterne (Nokia) <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>  <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> > >
> > Envoyé : mardi 18 avril 2023 00:57
> > À : Andy Bierman <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>  <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> > >; SADOUN Dylan DTSI/DTR <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>  <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> > >
> > Cc : [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>  <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> > ; [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>  <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[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]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>  <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> > > On Behalf Of Andy Bierman
> > Sent: Friday, April 14, 2023 11:08 AM
> > To: [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>  <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> >
> > Cc: [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>  <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> > ; [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>  <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[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<http://nok.it/ext> <http://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]> <mailto:[e-mail]<mailto:[e-mail]>>  <mailto:[e-mail]<mailto:[e-mail]> <mailto:[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/ <https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/> > https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/ <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]
> >
> >  <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> > [e-mail]<mailto:[e-mail]> <mailto:[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
> >


> --
> Jürgen Schönwälder              Constructor University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://constructor.university/ <https://constructor.university/> >
>>

>
> Orange Restricted
>



--
Jürgen Schönwälder              Constructor University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://constructor.university/>



Orange Restricted