Re: [netconf] RFC 6241 Ambiguity

[Andy Bierman <[e-mail]>]

Hi,

these changes look OK to me.

Andy


On Tue, Jun 25, 2019 at 11:03 AM Mahesh Jethanandani <
[e-mail]> wrote:

> 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]> 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]
>
>
>
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>