Re: [netconf] RFC 6241 Ambiguity

[Andy Bierman <[e-mail]>]

On Tue, Jun 11, 2019 at 1:16 PM Kent Watsen <[e-mail]> wrote:

>
> Hi Andy,
>
> So, by exclusion, is it fair to say that you support the NEW 7.8 and 7.9
> text?
>
>
They defer to section 8.4 which fine


> As for the 8.4.1 text, do you agree that there is a disconnect between
> what's in 8.4.1 and the description for the 'persist' leaf (e.g., current
> text says "the only way to abort a persistent confirmed commit is to let
> the timer expire, or to use the <cancel-commit> operation.").  If so, then
> a clarifying statement is needed, the only question is what it is. The
> choices are:
>
>   a)  'persist' MUST span reboots.
>   b)  'persist' MUST NOT span reboots.
>   c) ' it is an implementation decision as to if 'persist' spans reboots.
>
> Personally, I'm okay with any of these as it seems the primary benefit for
> 'persist' is still reaped (i.e., to survive a client-disconnect that may
> occur due to the config being committed) and given that most devices do not
> need to reboot in order to commit a configuration.
>
>
IMO the text most strongly supports (b) [para 6].
It could be argued that [para 5] supports (a) because a server reboot does
cause a session
termination, but IMO this was not the intent of para 5. It suggests the
server is still running
but the client session is terminated

[para 5]

   If the session issuing the confirmed commit is terminated 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.


[para 6]

       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.


I think (c) is OK since it not 100% clear what the scope of "unless"
is in para 5.



That said, some (IoT?) devices may need to reboot in order to apply any
> configuration.  If this ability does not support such devices, then they
> would never be able to support 'commit confirmed' (with or without
> 'persist') and hence may become bricks in some scenarios.  Do we care?
>
> Kent  // contributor
>
>
>
Andy


>
> On Jun 4, 2019, at 4:16 PM, Andy Bierman <[e-mail]> wrote:
>
> 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]
>>
>>
>>
>> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>
>
>