RFC Errata
Found 14 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.
Status: Held for Document Update (5)
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: 5401
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Rohit R Ranade
Date Reported: 2018-06-21
Held for Document Update by: Ignas Bagdonas
Date Held: 2019-10-18
Section 8.9.1 says:
The XPath expression MUST return a node set. If it does not return a node set, the operation fails with an "invalid-value" error.
It should say:
The XPath expression MUST return a node set. If it does not return a node set, the operation fails with an <error-tag> value of "invalid-value".
Notes:
It is unclear what is the meaning of "invalid-value" "error". Since the xpath will be part of "select" attribute, we can assume that a server can return a "bad-attribute" error-tag and having error-message indicating invalid-value for the attribute. This clarifies the <error-tag> to be used in such cases.
In other places, where error-tag has been mentioned, it is clear that "invalid-value" <error-tag> must be used.
Errata ID: 3569
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Xiang Li
Date Reported: 2013-03-27
Held for Document Update by: Benoit Claise
Section 1.2 says:
(2) The Messages layer provides a simple, transport-independent
framing mechanism for encoding RPCs and notifications.
Section 4 documents the RPC messages, and [RFC5717] documents
notifications
It should say:
(2) The Messages layer provides a simple, transport-independent
framing mechanism for encoding RPCs and notifications.
Section 4 documents the RPC messages, and [RFC5277] documents
notifications
Notes:
RFC5717 Partial Lock Remote Procedure Call (RPC) for NETCONF
RFC5277 NETCONF Event Notifications
Errata ID: 3821
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jonathan Hansford
Date Reported: 2013-12-06
Held for Document Update by: Benoit Claise
Date Held: 2014-01-13
Section 8.4.1 says:
8.4.1. Description The :confirmed-commit:1.1 capability indicates that the server will support the <cancel-commit> operation and the <confirmed>, <confirm-timeout>, <persist>, and <persist-id> parameters for the <commit> operation. See Section 8.3 for further details on the <commit> operation. A confirmed <commit> operation MUST be reverted if a confirming commit is not issued within the timeout period (by default 600 seconds = 10 minutes). The confirming commit is a <commit> operation without the <confirmed> parameter. The timeout period can be adjusted with the <confirm-timeout> parameter. If a follow-up confirmed <commit> operation is issued before the timer expires, the timer is reset to the new value (600 seconds by default). Both the confirming commit and a follow-up confirmed <commit> operation MAY introduce additional changes to the configuration. If the <persist> element is not given in the confirmed commit operation, any follow-up commit and the confirming commit MUST be issued on the same session that issued the confirmed commit. If the <persist> element is given in the confirmed <commit> operation, a follow-up commit and the confirming commit can be given on any session, and they MUST include a <persist-id> element with a value equal to the given value of the <persist> element. If the server also advertises the :startup capability, a <copy-config> from running to startup is also necessary to save the changes to startup. If the session issuing the confirmed commit is terminated 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. 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. If a confirming commit is not issued, the device will revert its configuration to the state prior to the issuance of the confirmed commit. To cancel a confirmed commit and revert changes without waiting for the confirm timeout to expire, the client can explicitly restore the configuration to its state before the confirmed commit was issued, by using the <cancel-commit> operation.
It should say:
8.4.1. Description The :confirmed-commit:1.1 capability indicates that the server will support the <cancel-commit> operation, the <confirmed>, <confirm- timeout>, <persist>, and <persist-id> parameters for the <commit> operation, and differentiate between a “to be confirmed” <commit> operation (a “confirmed commit”) and a confirming <commit> operation. See Section 8.3 for further details on the <commit> operation. A confirmed <commit> operation MUST be reverted if a confirming commit is not issued within the timeout period (by default 600 seconds = 10 minutes). The confirming commit is a <commit> operation without the <confirmed> parameter and, if successful, cannot be reverted. The timeout period can be adjusted with the <confirm- timeout> parameter. If a follow-up confirmed <commit> operation is issued before the timer expires, the timer is reset to the new value (600 seconds by default). Both the confirming commit and a follow-up confirmed <commit> operation MAY introduce additional changes to the configuration. If the <persist> element is not given in the confirmed commit operation, any follow-up commit and the confirming commit MUST be issued on the same session that issued the confirmed commit. If the <persist> element is given in the confirmed <commit> operation, a follow-up commit and the confirming commit can be given on any session, and they MUST include a <persist-id> element with a value equal to the given value of the <persist> element. If the server also advertises the :startup capability, a <copy- config> from running to startup is also necessary to save the changes to startup. If the session issuing a sequence of one or more confirmed commits is terminated for any reason before the confirm timeout expires, the server MUST restore the configuration to its state before the sequence of confirmed commits was issued, unless the last confirmed commit also included a <persist> or <persist-id> element. If the device reboots for any reason before the confirm timeout expires, the server MUST restore the configuration to its state before the sequence of confirmed commits was issued, unless the last confirmed commit also included a <persist> or <persist-id> element. If a confirming commit is not issued, the device will revert its configuration to the state prior to the issuance of the first in the current sequence of confirmed commits. To cancel the current sequence of confirmed commits and revert changes without waiting for the confirm timeout to expire, the client can explicitly restore the configuration to its state before the sequence of confirmed commits was issued, by using the <cancel-commit> operation.
Notes:
This erratum seeks to clarify the meaning of the term "confirmed commit" for those not familiar with the use of the term within JUNOS. In particular, that the use of "confirmed" is not in the sense of the adjective (meaning "firmly established") but rather that the commit needs to be confirmed. It also emphasises that a "confirming commit" cannot be reverted. Finally it identifies that it is possible to have a sequence of "confirmed commits" prior to a "confirming commit" and that, should no "confirming commit" be received, the configuration will revert to the state prior to the first "confirmed commit" in the sequence.
Errata ID: 3822
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jonathan Hansford
Date Reported: 2013-12-06
Held for Document Update by: Benoit Claise
Date Held: 2014-01-13
Section 8.4.4.1 says:
Description:
Cancels an ongoing confirmed commit. If the <persist-id>
parameter is not given, the <cancel-commit> operation MUST be
issued on the same session that issued the confirmed commit.
Parameters:
persist-id:
Cancels a persistent confirmed commit. The value MUST be
equal to the value given in the <persist> parameter to the
<commit> operation. If the value does not match, the
operation fails with an "invalid-value" error.
It should say:
Description:
Cancels an ongoing sequence of confirmed commits. If the
<persist-id> parameter is not given, the <cancel-commit>
operation MUST be issued on the same session that issued the
sequence of confirmed commits.
Parameters:
persist-id:
Cancels a persistent sequence of confirmed commits. The
value MUST be equal to the value given in the <persist>
parameter to the <commit> operation. If the value does not
match, the operation fails with an "invalid-value" error.
Notes:
This erratum seeks to clarify that <cancel-commit> will cancel all configuration changes arising from a sequence of "confirmed commits".
Errata ID: 3823
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jonathan Hansford
Date Reported: 2013-12-06
Held for Document Update by: Benoit Claise
Date Held: 2014-01-13
Section 8.4.5.1 says:
persist:
Make the confirmed commit survive a session termination, and
set a token on the ongoing confirmed commit.
It should say:
persist:
Make the confirmed commit survive a session termination,
and set a token on the ongoing sequence of confirmed
commits.
Notes:
This erratum seeks to clarify that the use of the "persist" parameter will persist all configuration changes arising from a sequence of "confirmed commits".
Status: Rejected (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: 4544
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Keshava Bhat
Date Reported: 2015-11-24
Rejected by: Benoit Claise
Date Rejected: 2015-12-01
Section 6.1 says:
XML subtree filtering is a mechanism that allows an application to select particular XML subtrees to include in the <rpc-reply> for a <get> or <get-config> operation. A small set of filters for inclusion, simple content exact-match, and selection is provided, which allows some useful, but also very limited, selection mechanisms. The server does not need to utilize any data-model- specific semantics during processing, allowing for simple and centralized implementation strategies. Conceptually, a subtree filter is comprised of zero or more element subtrees, which represent the filter selection criteria. At each containment level within a subtree, the set of sibling nodes is logically processed by the server to determine if its subtree and path of elements to the root are included in the filter output. Each node specified in a subtree filter represents an inclusive filter. Only associated nodes in underlying data model(s) within the specified datastore on the server are selected by the filter. A node is selected if it matches the selection criteria and hierarchy of elements given in the filter data, except that the filter absolute path name is adjusted to start from the layer below <filter>. Response messages contain only the subtrees selected by the filter. Any selection criteria that were present in the request, within a particular selected subtree, are also included in the response. Note that some elements expressed in the filter as leaf nodes will be expanded (i.e., subtrees included) in the filter output. Specific data instances are not duplicated in the response in the event that the request contains multiple filter subtree expressions that select the same data.
It should say:
XML subtree filtering is a mechanism that allows an application to select particular XML subtrees to include in the <rpc-reply> for a <get> or <get-config> operation. A small set of filters for inclusion, simple content exact-match, and selection is provided, which allows some useful, but also very limited, selection mechanisms. The server does not need to utilize any data-model- specific semantics during processing, allowing for simple and centralized implementation strategies. Conceptually, a subtree filter is comprised of zero or more element subtrees, which represent the filter selection criteria. At each containment level within a subtree, the set of sibling nodes is logically processed by the server to determine if its subtree and path of elements to the root are included in the filter output. Each node specified in a subtree filter represents an inclusive filter. Only associated nodes in underlying data model(s) within the specified datastore on the server are selected by the filter. A node is selected if it matches the selection criteria and hierarchy of elements given in the filter data, except that the filter absolute path name is adjusted to start from the layer below <filter>. Response messages contain only the subtrees selected by the filter. Any selection criteria that were present in the request, within a particular selected subtree, are also included in the response. Note that some elements expressed in the filter as leaf nodes will be expanded (i.e., subtrees included) in the filter output. Specific data instances are not duplicated in the response in the event that the request contains multiple filter subtree expressions that select the same data. When a node in the subtree filter is unknown, the server sends a <rpc-error> as reply with "unknown-element" error-tag. In case of <get-config> RPC, if the subtree filter contains a node that is not a configuration node, the server sends <rpc-error> as reply with "bad-element" error-tag.
Notes:
It is not clear in the RFC what a netconf server should do when
it encounters invalid nodes in a subtree filter in case of
get/get-config RPC.
--VERIFIER NOTES--
I think the text is clear - it says that if the element "exactly
matches a corresponding portion of the supported data model" it is
included. If it is not even in the server's schema, it doesn't match
the "supported data model".
XPath filtering works the same way; elements that are not part of the
data model simply won't match, without producing an error.
Errata ID: 4856
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: frank feng
Date Reported: 2016-11-08
Rejected by: Benoit Claise
Date Rejected: 2016-12-20
Section 7.2 says:
config: A hierarchy of configuration data as defined by one of
the device's data models. The contents MUST be placed in an
appropriate namespace, to allow the device to detect the
appropriate data model, and the contents MUST follow the
constraints of that data model, as defined by its capability
definition. Capabilities are discussed in Section 8.
It should say:
config: A hierarchy of configuration data as defined by one or more of
the device's data models. The contents MUST be placed in an
appropriate namespace, to allow the device to detect the
appropriate data model, and the contents MUST follow the
constraints of that data model, as defined by its capability
definition. Capabilities are discussed in Section 8.
Notes:
--VERIFIER NOTES--
As discussed on the NETCONF mailing list.
Errata ID: 5443
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jonathan Natale
Date Reported: 2018-07-27
Rejected by: Ignas Bagdonas
Date Rejected: 2019-10-18
Section 4.4 says:
The <ok> element is sent in <rpc-reply> messages if no errors or warnings occurred during the processing of an <rpc> request, and no data was returned from the operation.
It should say:
The <ok> element is sent in <rpc-reply> messages if and only if no errors or warnings occurred during the processing of an <rpc> request, and no data was returned from the operation.
Notes:
I have been informed that an <ok> element should not include any errors or warnings, even in the event of the associated operation completing because the error's severity was only at warning level).
--VERIFIER NOTES--
Rejected based on WG mailing list discussion: https://mailarchive.ietf.org/arch/msg/netconf/nQYVm8sm5pZamtRAIhbcB9cOuos
Errata ID: 5596
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jonathan Hansford
Date Reported: 2019-01-09
Rejected by: Ignas Bagdonas
Date Rejected: 2019-10-19
Section 7.5 says:
The duration of the lock is defined as beginning when the lock is
acquired and lasting until either the lock is released or the
NETCONF session closes. The session closure can be explicitly
performed by the client, or implicitly performed by the server
based on criteria such as failure of the underlying transport,
simple inactivity timeout, or detection of abusive behavior on the
part of the client. These criteria are dependent on the
implementation and the underlying transport.
It should say:
The duration of the lock is defined as beginning when the lock is
acquired and lasting until either the lock is released or the
NETCONF session closes. The session closure can be explicitly
performed by the client, or implicitly performed by the server
based on criteria such as failure of the underlying transport,
simple inactivity timeout, or detection of abusive behavior on the
part of the client. These criteria are dependent on the
implementation and the underlying transport. Note that a lock
associated with a persistent confirmed commit will be released if
the NETCONF session closes and, if required, a new lock will have
to be acquired.
Notes:
A persistent confirmed commit can survive a session termination, however any lock on that same session cannot. If a new session is established between the client and server, the client will need to acquire new locks if it wishes to protect the ongoing persistent confirmed commit.
--VERIFIER NOTES--
Rejected based on WG mailing list discussion: https://mailarchive.ietf.org/arch/msg/netconf/lNr91W5aK-abxDaqzadftjoE2Pg