RFC Errata
RFC 6243, "With-defaults Capability for NETCONF", June 2011
Source of RFC: netconf (ops)
Errata ID: 7428
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dylan Sadoun
Date Reported: 2023-04-18
Rejected by: Rob Wilton
Date Rejected: 2023-10-02
Section Appendix A says:
A.2. Example Data Set
[...]
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<interfaces xmlns="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"/>
</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">
<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"/>
</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">
<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"/>
</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">
<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"/>
</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">
<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>
It should say:
A.2. Example Data Set
[...]
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<interfaces xmlns="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"/>
</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">
<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"/>
</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">
<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"/>
</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">
<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"/>
</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">
<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.
--VERIFIER NOTES--
After discussion with the WG, it was agreed that several server implementations would likely behave as your errata suggests. However, the consensus was that this behavior is beyond what can be clarified as part of an errata without specifying a new RFC. In particular, it is noted that the current RFC predominantly defines expected behavior for data nodes modified via the external API between the client and server and defining "conceptual data nodes being set by a server" is beyond the scope of behavior specified by the RFC.
Please also see errata 7426 that helps clarify the behavior for section 2.3.1.