Re: [netconf] RFC 6241 Ambiguity

[Mahesh Jethanandani <[e-mail]>]

Hi Andy,

Please provide alternative text in the form of OLD/NEW, if you do not agree with what is being proposed.

Thanks

> On Jun 3, 2019, at 8:24 AM, Andy Bierman <[e-mail]> wrote:
> 
> 
> 
> On Fri, May 31, 2019 at 3:19 PM Mahesh Jethanandani <[e-mail] <mailto:[e-mail]>> wrote:
> 
> 
> Several attempts have been made to clarify the role of confirmed commit in RFC 6241 vis-a-vis Section 7.8 <close-session> and Section 7.9 <kill-session>, and the text in Section 8.4 Confirmed Commit Capability.
> 
> We, (the chairs) believe that the best way to resolve issues with the current set of erratum that already exist or are being proposed is to minimize re-explaining the role of confirmed commit in both Section 7.8 and 7.9 and defer the explanation to Section 8.4 of the RFC. With that in mind, we are proposing that Section 7.8 and 7.9 should ultimately look as follows. Note, the highlights in all the sections are to enable identifying the changes.
> 
>  
> 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>
> 
> 
> In addition, 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.
> 
> 
> 
> I do not agree at all that the original text says or implies that a server MUST support 
> continuation of a confirmed commit across a reboot. 
> Is that what this new text is meant to convey?
> 
> The new text could mean that if <persist> was provided that the server MAY or SHOULD restore the configuration
> and terminate the confirmed commit procedure.
> 
> (There is text in multiple places that assumes the reader knows that restoring the configuration
> also terminates the CC)
> 
> 
> Current Erratums for RFC 6241 will be adjusted to accommodate these changes.
> 
> Mahesh & Kent (co-chairs)
> 
> 
> 
> 
> Andy
>  
> _______________________________________________
> netconf mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
Mahesh Jethanandani
[e-mail]