Re: [netconf] RFC 6241 Ambiguity

[Mahesh Jethanandani <[e-mail]>]

Summarizing the list of changes that we seem to have agreed upon:

For the first set of changes in section 7.8 and 7.9, we seem to agree on the original set of changes I had sent out earlier, which essentially deferred the discussion of confirmed commit to section 8.4 of the RFC. The second set of changes updates Section 8.4.1 to explain what happens to a confirmed commit that includes a <persist> element.

The highlights in the sections should enable identifying the changes.

CHANGE 1 START

OLD (as in original RFC 6241)

7.8 <https://tools.ietf.org/html/rfc6241#section-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 <https://tools.ietf.org/html/rfc6241#section-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 <https://tools.ietf.org/html/rfc6241#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 (as in original RFC 6241).

7.9 <https://tools.ietf.org/html/rfc6241#section-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 <https://tools.ietf.org/html/rfc6241#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 <https://tools.ietf.org/html/rfc6241#section-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 <https://tools.ietf.org/html/rfc6241#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>

CHANGE 1 END

CHANGE 2 START
The following paragraph in Section 8.4.1 would be modified.

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.

CHANGE 2 END

Finally, looking at the current set of Errata that are already open against the RFC, we (the chairs) believe that Errata number 5397 should be deleted and (a new Errata with these contents) be posted. This is being done to avoid stacking one Errata on top of another.

Unless there is objection to these changes within the next two weeks, we will proceed with submitting them to the RFC Editor.

> On Jun 12, 2019, at 2:47 PM, Andy Bierman <[e-mail]> wrote:
> 
> Hi,
> 
> This is the new text in question:
> It appears your intent is (c) since there is no mention at all what happens if
> <persist> was included.  The text just says what does not happen in this case.
> 
>>> 
>>>    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.
>> 
>> 
>> 
>> How about adding at the end:
>> 
>> OLD:
>> 
>> element.
>> 
>> NEW:
>> 
>> element, in which case the server MAY continue the confirmed commit procedure.
>> 
>> 
>> Andy
>>  
> 
> On Wed, Jun 12, 2019 at 1:16 PM Kent Watsen <[e-mail] <mailto:[e-mail]>> wrote:
> 
> Hi Andy,
> 
>> I object to changing RFC 6241 with an Errata if it attempts to enforce protocol behavior
>> that the original RFC does not actually specify.  (c) is correct for an Errata because the original RFC
>> is under-specified.  Or perhaps: (d) 'persist' MAY span reboots
> 
> It sounds like we're in agreement.  Are you objecting to something I wrote in particular?
> 
> Kent // contributor
> 
> 

Mahesh Jethanandani
[e-mail]