RFC Errata
Found 6 records.
Status: Verified (3)
RFC 6243, "With-defaults Capability for NETCONF", June 2011
Source of RFC: netconf (ops)
Errata ID: 4688
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Muly Ilan
Date Reported: 2016-05-08
Verifier Name: Benoit Claise
Date Verified: 2016-05-16
Section 4.5.2 says:
If the operation attribute contains the value 'create', and the data node already exists in the target configuration datastore, then the server MUST return an <rpc-error> response with an 'invalid-value' error-tag.
It should say:
If the operation attribute contains the value 'create', and the data node already exists in the target configuration datastore, then the server MUST return an <rpc-error> response with an 'data-exists' error-tag.
Notes:
According to RFC6241 section 7.2 the behavior for the 'create' operation is: " If the configuration data exists, an <rpc-error> element is returned with an <error-tag> value of "data-exists". "
Errata ID: 5289
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ganesh Sivasankaran
Date Reported: 2018-03-20
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2018-04-17
Section 4.5.1 says:
taken from the ’with-defaults-type’ typedef in Section 5.
It should say:
taken from the ’with-defaults-mode’ typedef in Section 5.
Notes:
Text reference typedef "with-defaults-type" does not exist in Section 5 and even in ietf-netconf-with-defaults.yang
Rather it is named typedef “with-defaults-mode”
[ WK: Verified, with agreement of authors. ]
Errata ID: 4687
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Muly Ilan
Date Reported: 2016-05-08
Verifier Name: Benoit Claise
Date Verified: 2016-05-17
Section A.1 says:
typedef status-type {
description "Interface status";
type enumeration {
enum ok;
enum 'waking up';
enum 'not feeling so good';
enum 'better check it out';
enum 'better call for help';
}
default ok;
}
It should say:
typedef status-type {
description "Interface status";
type enumeration {
enum up;
enum 'waking up';
enum 'not feeling so good';
enum 'better check it out';
enum 'better call for help';
}
default up;
}
Notes:
The examples in appendix A use the value 'up' and not the value 'ok'.
Status: Reported (3)
RFC 6243, "With-defaults Capability for NETCONF", June 2011
Source of RFC: netconf (ops)
Errata ID: 7426
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Dylan Sadoun
Date Reported: 2023-04-18
Section 2.3.1 says:
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.
It should say:
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.
Errata ID: 7427
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Dylan Sadoun
Date Reported: 2023-04-18
Section 3.3 says:
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.
It should say:
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.
Errata ID: 7428
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dylan Sadoun
Date Reported: 2023-04-18
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.