Re: [netconf] RFC 6241 Ambiguity

[Andy Bierman <[e-mail]>]

Hi,

I prefer to leave the old text in 8.4.1 alone and not change it
I don't agree there is any text to support this significant change in
server behavior.
An Errata should not make existing implementations non-compliant.
I don't see any text that indicates the original intent was to make a
confirmed commit
survive a reboot.

If a <persist> parameter is provided by the client session, and then that
client session
terminates, there is no way for a superuser (or any user) to invoke the
<cancel-commit>
operation.  The only remedy is to wait for the timeout or reboot the device.
If the timeout is long or unknown) then waiting it out may not be a good
option.

With the new text, rebooting the device does not clear this situation


Andy


On Tue, Jun 4, 2019 at 12:48 PM Mahesh Jethanandani <[e-mail]>
wrote:

> 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]> 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
>
>
> Mahesh Jethanandani
> [e-mail]
>
>
>
>