RFC Errata
Found 5 records.
Status: Verified (4)
RFC 6241, "Network Configuration Protocol (NETCONF)", June 2011
Note: This RFC has been updated by RFC 7803, RFC 8526
Source of RFC: netconf (ops)
Errata ID: 5790
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mahesh Jethanandani
Date Reported: 2019-07-23
Verifier Name: Ignas Bagdonas
Date Verified: 2019-08-20
In Sections 7.8, 7.9, and 8.4.1
OLD:
7.8. <close-session>
Description: Request graceful termination of a NETCONF session.
When a NETCONF server receives a <close-session> request, it will
gracefully close the session. The server will release any locks
and resources associated with the session and gracefully close
any associated connections. Any NETCONF requests received after
a <close-session> request will be ignored.
Positive Response: If the device was able to satisfy the request, an
<rpc-reply> is sent that includes an <ok> element.
Negative Response: An <rpc-error> element is included in the
<rpc-reply> if the request cannot be completed for any reason.
Example:
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<close-session/>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
NEW
7.8. <close-session>
Description: Request graceful termination of a NETCONF session.
When a NETCONF server receives a <close-session> request, it will
gracefully close the session. The server will release any locks
and resources associated with the session and gracefully close any
associated connections. Any NETCONF requests received after a
<close-session> request will be ignored.
For details on what happens if a NETCONF server receives a
<close-session> request while processing a confirmed commit,
please refer to Section 8.4.
Positive Response: If the device was able to satisfy the request, an
<rpc-reply> is sent that includes an <ok> element.
Negative Response: An <rpc-error> element is included in the
<rpc-reply> if the request cannot be completed for any reason.
Example:
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<close-session/>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
OLD
7.9. <kill-session>
Description: Force the termination of a NETCONF session.
When a NETCONF entity receives a <kill-session> request for an
open session, it will abort any operations currently in process,
release any locks and resources associated with the session, and
close any associated connections.
If a NETCONF server receives a <kill-session> request while
processing a confirmed commit (Section 8.4), it MUST restore the
configuration to its state before the confirmed commit was issued.
Otherwise, the <kill-session> operation does not roll back
configuration or other device state modifications made by the
entity holding the lock.
Parameters:
session-id: Session identifier of the NETCONF session to be
terminated. If this value is equal to the current session ID,
an "invalid-value" error is returned.
Positive Response: If the device was able to satisfy the request, an
<rpc-reply> is sent that includes an <ok> element.
Negative Response: An <rpc-error> element is included in the
<rpc-reply> if the request cannot be completed for any reason.
Example:
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<kill-session>
<session-id>4</session-id>
</kill-session>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
NEW
7.9. <kill-session>
Description: Force the termination of a NETCONF session.
When a NETCONF entity receives a <kill-session> request for an
open session, it will abort any operations currently in process,
release any locks and resources associated with the session, and
close any associated connections.
For details on what happens if a NETCONF server receives a
<kill-session> request while processing a confirmed commit,
please refer to Section 8.4.
Otherwise, the <kill-session> operation does not roll back
configuration or other device state modifications made by the
entity holding the lock.
Parameters:
session-id: Session identifier of the NETCONF session to be
terminated. If this value is equal to the current session ID,
an "invalid-value" error is returned.
Positive Response: If the device was able to satisfy the request, an
<rpc-reply> is sent that includes an <ok> element.
Negative Response: An <rpc-error> element is included in the
<rpc-reply> if the request cannot be completed for any reason.
Example:
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<kill-session>
<session-id>4</session-id>
</kill-session>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
Section 8.4.1
OLD:
If the device reboots for any reason before the confirm timeout
expires, the server MUST restore the configuration to its state
before the confirmed commit was issued.
NEW:
If the device reboots for any reason before the confirm timeout
expires, the server MUST restore the configuration to its state
before the confirmed commit was issued, unless the confirmed commit
also included a <persist> element, in which case the server MAY
continue the confirmed commit procedure.
Notes:
This Errata modifies three different sections, Sections 7.8, 7.9 and 8.4.1. The changes in Section 7.8 and 7.9 defer the description of the behavior of confirmed commit to Section 8.4.1.
Errata ID: 3980
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Klement Sekera
Date Reported: 2014-05-05
Verifier Name: Benoit Claise
Date Verified: 2015-01-23
Sections 6.2.5 and 6.3
In section 6.3:
OLD:
The
algorithm continues until all sibling sets in all subtrees specified
in the filter have been processed.
In section 6.2.5
OLD:
o If any sibling nodes of the selection node are instance identifier
components for a conceptual data structure (e.g., list key leaf),
then they MAY also be included in the filter output.
It should say:
In section 6.3: NEW: The algorithm continues until all sibling sets in all subtrees specified in the filter have been processed. If any sibling nodes of a node are instance identifier components for a conceptual data structure (e.g., list key leaf), then they MAY also be included in the filter output. In section 6.2.5 NEW:
Notes:
The intent is to allow the server to always include the key node values and the wording accidentally does not cover this case.
Here is the OLD/NEW in a more intuitive way:
In section 6.3:
OLD:
The algorithm continues until all sibling sets in all subtrees specified
in the filter have been processed.
NEW:
The algorithm continues until all sibling sets in all subtrees specified
in the filter have been processed. If any sibling nodes of a node
are instance identifier components for a conceptual data structure
(e.g., list key leaf), then they MAY also be included in the filter output.
Implicitly in section 6.2.5 to delete the moved text:
OLD:
If any sibling nodes of the selection node are instance identifier
components for a conceptual data structure (e.g., list key leaf),
then they MAY also be included in the filter output.
NEW:
<void>
Errata ID: 4066
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Andy Bierman
Date Reported: 2014-07-30
Verifier Name: Benoit Claise
Date Verified: 2014-09-22
Section 7.2 says:
If the "operation" attribute is not specified, the configuration is merged into the configuration datastore.
It should say:
If the "operation" attribute is not specified, then the operation applied to the parent data node of the configuration is used. If no parent data node is available, then the value of the <default-operation> parameter is used. If the <default-operation> parameter is not given, the configuration is merged into the configuration datastore.
Notes:
sentence in para 6 is not correct.
The default-operation value is used, not the value "merge".
Discussion on the NETCONF mailing list. See http://www.ietf.org/mail-archive/web/netconf/current/msg09169.html
Errata ID: 5388
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jonathan Hansford
Date Reported: 2018-06-11
Verifier Name: Ignas Bagdonas
Date Verified: 2019-10-18
Section 8.3.4.2 says:
8.3.4.2. <discard-changes>
If the client decides that the candidate configuration is not to be
committed, the <discard-changes> operation can be used to revert the
candidate configuration to the current running configuration.
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<discard-changes/>
</rpc>
This operation discards any uncommitted changes by resetting the
candidate configuration with the content of the running
configuration.
It should say:
8.3.4.2. <discard-changes>
Description:
If the client decides that the candidate configuration is not
to be committed, the <discard-changes> operation can be used to
revert the candidate configuration to the current running
configuration.
This operation discards any uncommitted changes by resetting
the candidate configuration with the content of the running
configuration.
Positive Response:
If the device was able to satisfy the request, an <rpc-reply>
is sent that contains an <ok> element.
Negative Response:
An <rpc-error> element is included in the <rpc-reply> if the
request cannot be completed for any reason.
Example:
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<discard-changes/>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
Notes:
RFC 6241 section 1.1 includes the following two definitions:
o protocol operation: A specific remote procedure call, as used
within the NETCONF protocol.
o remote procedure call (RPC): Realized by exchanging <rpc> and
<rpc-reply> messages.
Positive and negative responses are detailed for all instances of an operation within the RFC with the exception of <discard-changes>.
Section 8.3.4.2 identifies <discard-changes> as an operation, and appendices A and C identify "rollback-failed" as an error-tag to be used when the "Request to roll back some configuration change (via rollback-on-error or <discard-changes> operations) was not completed for some reason."
This change clarifies that <discard-changes> requires an <rpc-reply>.
Status: Reported (1)
RFC 6241, "Network Configuration Protocol (NETCONF)", June 2011
Note: This RFC has been updated by RFC 7803, RFC 8526
Source of RFC: netconf (ops)
Errata ID: 7624
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Jernej Tuljak
Date Reported: 2023-08-31
Section 4.3. says:
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<rpc-error>
<error-type>rpc</error-type>
<error-tag>missing-attribute</error-tag>
<error-severity>error</error-severity>
<error-info>
<bad-attribute>message-id</bad-attribute>
<bad-element>rpc</bad-element>
</error-info>
</rpc-error>
</rpc-reply>
It should say:
<nc:rpc-reply xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<nc:rpc-error>
<nc:error-type>rpc</nc:error-type>
<nc:error-tag>missing-attribute</nc:error-tag>
<nc:error-severity>error</nc:error-severity>
<nc:error-info>
<nc:bad-attribute>message-id</nc:bad-attribute>
<nc:bad-element>nc:rpc</nc:bad-element>
</nc:error-info>
</nc:rpc-error>
</nc:rpc-reply>
Notes:
The original error response is referring to the NETCONF messages layer attribute "message-id", which does not belong to any XML namespace. The response is not properly encoding xs:QName values of elements "bad-attribute" and "bad-element" by placing them both into the default XML namespace. Proposed new text (while verbose) ensures that the values are placed into their respective proper XML namespaces.