Re: [netconf] RFC 6241 Ambiguity

[Andy Bierman <[e-mail]>]

On Fri, May 31, 2019 at 3:19 PM Mahesh Jethanandani <[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]
> https://www.ietf.org/mailman/listinfo/netconf
>