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

[Andy Bierman <[e-mail]>]

On Wed, Apr 19, 2023 at 12:21 PM Jürgen Schönwälder
<[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] 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]>
> > To: RFC Errata System <[e-mail]>
> > Cc: SADOUN Dylan DTSI/DTR <[e-mail]>,
> >  [e-mail], [e-mail]
> > Subject: Re: [Editorial Errata Reported] RFC6243 (7428)
> > Message-ID: <CABCOCHQ8m=A37p=
> [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]> > 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>
> >
> > --------------------------------------
> > Type: Editorial
> > Reported by: Dylan Sadoun <[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>
> > ">
> >       <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>
> > "/>
> >         </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>
> > ">
> >           <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>
> > "/>
> >         </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>
> > ">
> >           <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>
> > "/>
> >         </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>
> > ">
> >           <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>
> > "/>
> >         </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>
> > ">
> >           <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>
> > ">
> >       <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>
> > "/>
> >         </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>
> > ">
> >           <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>
> > "/>
> >         </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>
> > ">
> >           <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>
> > "/>
> >         </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>
> > ">
> >           <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>
> > "/>
> >         </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>
> > ">
> >           <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]>
> > To: "Rob Wilton (rwilton)" <[e-mail]>
> > Cc: RFC Errata System <[e-mail]>,
> >  [e-mail], [e-mail], [e-mail]
> ,
> >  [e-mail], SADOUN Dylan DTSI/DTR <[e-mail]>,
> >  [e-mail]
> > Subject: Re: [Technical Errata Reported] RFC6243 (7426)
> > Message-ID: <CABCOCHRvVLBaWUqZ88O5iPsfc9bXYOO7tT2Yh0=
> [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]> > 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>
> > 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>
> > 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]> >
> > Sent: 18 April 2023 17:18
> > To: RFC Errata System <[e-mail]
> > <mailto:[e-mail]> >
> > Cc: [e-mail] <mailto:[e-mail]> ;
> > [e-mail] <mailto:[e-mail]> ; Rob Wilton (rwilton)
> > <[e-mail] <mailto:[e-mail]> >; [e-mail]
> > <mailto:[e-mail]> ; [e-mail]
> > <mailto:[e-mail]> ; [e-mail]
> > <mailto:[e-mail]> ; [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]> > 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>
> >
> > --------------------------------------
> > Type: Technical
> > Reported by: Dylan Sadoun <[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]>
> > To: Andy Bierman <[e-mail]>, RFC Errata System
> >  <[e-mail]>, SADOUN Dylan DTSI/DTR
> >  <[e-mail]>, [e-mail]
> > Cc: [e-mail], [e-mail],
> >  [e-mail], [e-mail]
> > Subject: RE: [Technical Errata Reported] RFC6243 (7427)
> > Message-ID: <
> [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]>
> > Sent: 18 April 2023 17:54
> > To: RFC Errata System <[e-mail]>
> > Cc: [e-mail]; [e-mail]; Rob Wilton
> (rwilton)
> > <[e-mail]>; [e-mail]; [e-mail];
> > [e-mail]; [e-mail]
> > Subject: Re: [Technical Errata Reported] RFC6243 (7427)
> >
> >
> >
> > Hi,
> >
> >
> >
> > This Errata should be rejected.
> >
> > The additional sentence is not needed and was not left out of the
> original
> > text by error.
> >
> >
> >
> > This sentence refers to a node without an instance so the YANG default
> is used
> > instead.
> >
> >
> >
> >      A conceptual data node that would be set by the server to the
> schema
> > default value MUST NOT be reported.
> >
> >
> >
> > The key text is "would be set". A better clarification is "would be used"
> >
> > The intent is that the node is not explicitly set.
> >
> >
> >
> > It is not possible for a node to have a value other than the YANG
> default and
> > not be explicitly set.
> >
> >
> >
> > Andy
> >
> >
> >
> > On Tue, Apr 18, 2023 at 5:37 AM RFC Errata System <
> [e-mail]
> > <mailto:[e-mail]> > wrote:
> >
> > The following errata report has been submitted for RFC6243,
> > "With-defaults Capability for NETCONF".
> >
> > --------------------------------------
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid7427
> > <https://www.rfc-editor.org/errata/eid7427>
> >
> > --------------------------------------
> > Type: Technical
> > Reported by: Dylan Sadoun <[e-mail]
> > <mailto:[e-mail]> >
> >
> > Section: 3.3
> >
> > Original Text
> > -------------
> > When data is retrieved with a <with-defaults> parameter equal to
> 'explicit', a
> > data node that was set by a client to its schema default value MUST be
> > reported.  A conceptual data node that would be set by the server to the
> > schema default value MUST NOT be reported. Non-configuration data nodes
> > containing the schema default value MUST be reported.
> >
> > Corrected Text
> > --------------
> > When data is retrieved with a <with-defaults> parameter equal to
> 'explicit', a
> > data node that was set by a client to its schema default value MUST be
> > reported. A conceptual data node that would be set by the server to the
> schema
> > default value MUST NOT be reported. A conceptual data node that would be
> set
> > by the server to a value other than its schema default value MUST be
> reported.
> > Non-configuration data nodes containing the schema default value MUST be
> > reported.
> >
> > Notes
> > -----
> > The RFC defines "Explicitly set data" for the sole purpose of defining
> the
> > explicit retrieval mode. This definition is clear about when data set by
> the
> > server should be considered "explicitly set" i.e. when not set to the
> schema
> > default value. However, the 2.3.1 and 3.3 sections are ambiguous and
> prone to
> > misunderstanding, as they only emphasise the "set by the client" case,
> which
> > leads to think that data set by the server to a value different from its
> > schema default value should not be reported.
> > This erratum is for the 3.3 section.
> >
> > Instructions:
> > -------------
> > This erratum is currently posted as "Reported". If necessary, please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party
> > can log in to change the status and edit the report, if necessary.
> >
> > --------------------------------------
> > RFC6243 (draft-ietf-netconf-with-defaults-14)
> > --------------------------------------
> > Title               : With-defaults Capability for NETCONF
> > Publication Date    : June 2011
> > Author(s)           : A. Bierman, B. Lengyel
> > Category            : PROPOSED STANDARD
> > Source              : Network Configuration
> > Area                : Operations and Management
> > Stream              : IETF
> > Verifying Party     : IESG
> >
>
> > Date: Tue, 18 Apr 2023 14:52:50 +0200
> > From: [e-mail]
> > To: "Jason Sterne (Nokia)" <[e-mail]>, Andy Bierman
> >  <[e-mail]>
> > Cc: [e-mail], [e-mail]
> > Subject: RE: [netconf]  Regarding RFC 6243 "With-defaults Capability for
> >  NETCONF" … the devil is in the defaults
> > Message-ID: <
> [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/,
> 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]> [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]
> >
> >  <mailto:[e-mail]> [e-mail]
> >
> >
> >
> >
> >
> > Orange Restricted
> >
> > De : Jason Sterne (Nokia) <[e-mail] <mailto:
> [e-mail]> >
> > Envoyé : mardi 18 avril 2023 00:57
> > À : Andy Bierman <[e-mail] <mailto:[e-mail]> >;
> SADOUN Dylan DTSI/DTR <[e-mail] <mailto:
> [e-mail]> >
> > Cc : [e-mail] <mailto:
> [e-mail]> ; [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]>
> > On Behalf Of Andy Bierman
> > Sent: Friday, April 14, 2023 11:08 AM
> > To: [e-mail] <mailto:[e-mail]>
> > Cc: [e-mail] <mailto:
> [e-mail]> ; [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 for additional
> information.
> >
> >
> >
> > Hi,
> >
> >
> >
> > I think the text in 2.3.1 is an omission.
> >
> >
> >
> > "set by client" should be "set by client or server"
> >
> >
> >
> > Andy
> >
> >
> >
> >
> >
> > On Fri, Apr 14, 2023 at 7:53 AM <[e-mail] <mailto:
> [e-mail]> > wrote:
> >
> > Hello
> >
> >
> >
> > I am reaching you about a potential technical erratum in RFC 6243,
> although I am not accustomed to the IETF process. I read  <
> https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/>
>
> 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]> [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
> >
> >
> >
>
>
>
>
>
>
>
>
> > _______________________________________________
> > netconf mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netconf
>
>
> --
> Jürgen Schönwälder              Constructor University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://constructor.university/>
>
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>