RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

RFC 6241, "Network Configuration Protocol (NETCONF)", June 2011

Source of RFC: netconf (ops)

Errata ID: 5397
Status: Reported
Type: Technical

Reported By: Jonathan Hansford
Date Reported: 2018-06-19

Section 7.8 & 7.9 says:

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>

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>

It should say:

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.
 
      If a NETCONF server receives a <close-session> request while
      processing a confirmed commit (Section 8.4) for that session, it
      MUST restore the configuration to its state before the confirmed
      commit was issued unless the confirmed commit included a <persist>
      element.
 
      Otherwise, the <close-session> operation does not roll back
      configuration or other device state modifications made by the
      entity holding the lock. Note that the only way to abort a
      persistent confirmed commit is to let the timer expire, or to use
      the <cancel-commit> operation.
 
   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>
 
7.9.  <kill-session>
 
   Description:  Force the termination of a NETCONF session.
 
      When a NETCONF server 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) for that session, it
      MUST restore the configuration to its state before the confirmed
      commit was issued unless the confirmed commit included a <persist>
      element.
 
      Otherwise, the <kill-session> operation does not roll back
      configuration or other device state modifications made by the
      entity holding the lock. Note that the only way to abort a
      persistent confirmed commit is to let the timer expire, or to use
      the <cancel-commit> operation.
 
   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>

Notes:

Clarifies the behaviour for both <close-session> and <kill-session> when that session has an outstanding confirmed commit, regardless of whether the confirmed commit includes a <persist> element.

Report New Errata