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

[[e-mail]]

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.

--- Begin Message ---

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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid7428&data=05%7C01%7Cdylan.sadoun%40orange.com%7C4d44b3f8dd7c408c5d9308db4035a752%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638174371410851355%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=v5B1g7nxmMttrzOTnJj%2BjfxCD46n2ouXHPWv2GtO78I%3D&reserved=0>

--------------------------------------
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 
<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fexample.com%2Fns%2Finterfaces&data=05%7C01%7Cdylan.sadoun%40orange.com%7C4d44b3f8dd7c408c5d9308db4035a752%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638174371410851355%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=80V0Sh0mHUOBhDfGgLKM33C6%2BNc2Hl95I7Ql%2BWc63cY%3D&reserved=0> 
">
      <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 
<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fexample.com%2Fns%2Finterfaces&data=05%7C01%7Cdylan.sadoun%40orange.com%7C4d44b3f8dd7c408c5d9308db4035a752%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638174371410851355%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=80V0Sh0mHUOBhDfGgLKM33C6%2BNc2Hl95I7Ql%2BWc63cY%3D&reserved=0> 
"/>
        </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 
<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fexample.com%2Fns%2Finterfaces&data=05%7C01%7Cdylan.sadoun%40orange.com%7C4d44b3f8dd7c408c5d9308db4035a752%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638174371411007611%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RtzbCbUqHt7m5N3QhloRe0ec6PuhzF1BaF05KY2CvtE%3D&reserved=0> 
">
          <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 
<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fexample.com%2Fns%2Finterfaces&data=05%7C01%7Cdylan.sadoun%40orange.com%7C4d44b3f8dd7c408c5d9308db4035a752%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638174371411007611%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RtzbCbUqHt7m5N3QhloRe0ec6PuhzF1BaF05KY2CvtE%3D&reserved=0> 
"/>
        </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 
<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fexample.com%2Fns%2Finterfaces&data=05%7C01%7Cdylan.sadoun%40orange.com%7C4d44b3f8dd7c408c5d9308db4035a752%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638174371411007611%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RtzbCbUqHt7m5N3QhloRe0ec6PuhzF1BaF05KY2CvtE%3D&reserved=0> 
">
          <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 
<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fexample.com%2Fns%2Finterfaces&data=05%7C01%7Cdylan.sadoun%40orange.com%7C4d44b3f8dd7c408c5d9308db4035a752%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638174371411007611%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RtzbCbUqHt7m5N3QhloRe0ec6PuhzF1BaF05KY2CvtE%3D&reserved=0> 
"/>
        </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 
<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fexample.com%2Fns%2Finterfaces&data=05%7C01%7Cdylan.sadoun%40orange.com%7C4d44b3f8dd7c408c5d9308db4035a752%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638174371411007611%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RtzbCbUqHt7m5N3QhloRe0ec6PuhzF1BaF05KY2CvtE%3D&reserved=0> 
">
          <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 
<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fexample.com%2Fns%2Finterfaces&data=05%7C01%7Cdylan.sadoun%40orange.com%7C4d44b3f8dd7c408c5d9308db4035a752%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638174371411007611%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RtzbCbUqHt7m5N3QhloRe0ec6PuhzF1BaF05KY2CvtE%3D&reserved=0> 
"/>
        </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 
<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fexample.com%2Fns%2Finterfaces&data=05%7C01%7Cdylan.sadoun%40orange.com%7C4d44b3f8dd7c408c5d9308db4035a752%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638174371411007611%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RtzbCbUqHt7m5N3QhloRe0ec6PuhzF1BaF05KY2CvtE%3D&reserved=0> 
">
          <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 
<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fexample.com%2Fns%2Finterfaces&data=05%7C01%7Cdylan.sadoun%40orange.com%7C4d44b3f8dd7c408c5d9308db4035a752%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638174371411007611%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RtzbCbUqHt7m5N3QhloRe0ec6PuhzF1BaF05KY2CvtE%3D&reserved=0> 
">
      <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 
<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fexample.com%2Fns%2Finterfaces&data=05%7C01%7Cdylan.sadoun%40orange.com%7C4d44b3f8dd7c408c5d9308db4035a752%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638174371411007611%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RtzbCbUqHt7m5N3QhloRe0ec6PuhzF1BaF05KY2CvtE%3D&reserved=0> 
"/>
        </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 
<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fexample.com%2Fns%2Finterfaces&data=05%7C01%7Cdylan.sadoun%40orange.com%7C4d44b3f8dd7c408c5d9308db4035a752%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638174371411007611%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RtzbCbUqHt7m5N3QhloRe0ec6PuhzF1BaF05KY2CvtE%3D&reserved=0> 
">
          <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 
<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fexample.com%2Fns%2Finterfaces&data=05%7C01%7Cdylan.sadoun%40orange.com%7C4d44b3f8dd7c408c5d9308db4035a752%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638174371411007611%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RtzbCbUqHt7m5N3QhloRe0ec6PuhzF1BaF05KY2CvtE%3D&reserved=0> 
"/>
        </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 
<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fexample.com%2Fns%2Finterfaces&data=05%7C01%7Cdylan.sadoun%40orange.com%7C4d44b3f8dd7c408c5d9308db4035a752%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638174371411007611%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RtzbCbUqHt7m5N3QhloRe0ec6PuhzF1BaF05KY2CvtE%3D&reserved=0> 
">
          <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 
<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fexample.com%2Fns%2Finterfaces&data=05%7C01%7Cdylan.sadoun%40orange.com%7C4d44b3f8dd7c408c5d9308db4035a752%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638174371411007611%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RtzbCbUqHt7m5N3QhloRe0ec6PuhzF1BaF05KY2CvtE%3D&reserved=0> 
"/>
        </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 
<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fexample.com%2Fns%2Finterfaces&data=05%7C01%7Cdylan.sadoun%40orange.com%7C4d44b3f8dd7c408c5d9308db4035a752%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638174371411007611%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RtzbCbUqHt7m5N3QhloRe0ec6PuhzF1BaF05KY2CvtE%3D&reserved=0> 
">
          <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 
<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fexample.com%2Fns%2Finterfaces&data=05%7C01%7Cdylan.sadoun%40orange.com%7C4d44b3f8dd7c408c5d9308db4035a752%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638174371411007611%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RtzbCbUqHt7m5N3QhloRe0ec6PuhzF1BaF05KY2CvtE%3D&reserved=0> 
"/>
        </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 
<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fexample.com%2Fns%2Finterfaces&data=05%7C01%7Cdylan.sadoun%40orange.com%7C4d44b3f8dd7c408c5d9308db4035a752%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638174371411163843%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=wiCoqKM1vX5QUkAW1EZiDZmSk1iunuYSTYmTHyj1MBs%3D&reserved=0> 
">
          <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

--- End Message ---

--- Begin Message ---

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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc6243%23section-3.3&data=05%7C01%7Cdylan.sadoun%40orange.com%7C6461af4a120f4dd0febe08db403450fc%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638174365658461011%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=x9kHGhl8AOEo6XXoLMAt4xtypTgJPihbwwhvxrURWgo%3D&reserved=0> 
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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc6243%23section-2.3.1&data=05%7C01%7Cdylan.sadoun%40orange.com%7C6461af4a120f4dd0febe08db403450fc%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638174365658461011%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=aAaqyNtS3aRHSEAX5iAvtPz8dl0OZzZ9axIPdOtE%2BXY%3D&reserved=0> 
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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid7426&data=05%7C01%7Cdylan.sadoun%40orange.com%7C6461af4a120f4dd0febe08db403450fc%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638174365658461011%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=nhm3Nj6A3hZoqc1KXhao2rq%2FPBtZqNeLP33ShXWIiQY%3D&reserved=0>

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

--- End Message ---

--- Begin Message ---

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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid7427&data=05%7C01%7Cdylan.sadoun%40orange.com%7Cbd4687e5147a46dc6c4d08db402ffd8f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638174347084717540%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=F%2FFOtbAUEhqVXCI7%2F3pYuahlxKRbOpDPnDGiK0gMsKk%3D&reserved=0>

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

--- End Message ---

--- Begin Message ---

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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fprocessing-errata-ietf-stream%2F&data=05%7C01%7Cdylan.sadoun%40orange.com%7Cb86705da7f9540b7694708db3f970c36%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638173690201161442%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=oicNgtoiLC5VjCYFQC22n3dmHhjHoxBq95XK34C7E7A%3D&reserved=0> 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

 

--- End Message ---