Re: [netconf] RFC 6241 Ambiguity

"Jonathan Hansford" <jonathan@hansfords.net> Wed, 12 June 2019 11:16 UTC

Return-Path: <jonathan@hansfords.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 882D9120120 for <netconf@ietfa.amsl.com>; Wed, 12 Jun 2019 04:16:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9ZgXaFilXyW for <netconf@ietfa.amsl.com>; Wed, 12 Jun 2019 04:16:02 -0700 (PDT)
Received: from egyptian.birch.relay.mailchannels.net (egyptian.birch.relay.mailchannels.net [23.83.209.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C05071200B6 for <netconf@ietf.org>; Wed, 12 Jun 2019 04:16:01 -0700 (PDT)
X-Sender-Id: dxszz3qpvg|x-authuser|jonathan@hansfords.net
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 95AA9140702; Wed, 12 Jun 2019 11:15:59 +0000 (UTC)
Received: from mail.myfast.site (100-96-85-75.trex.outbound.svc.cluster.local [100.96.85.75]) (Authenticated sender: dxszz3qpvg) by relay.mailchannels.net (Postfix) with ESMTPA id 96C4E141528; Wed, 12 Jun 2019 11:15:57 +0000 (UTC)
X-Sender-Id: dxszz3qpvg|x-authuser|jonathan@hansfords.net
Received: from mail.myfast.site ([TEMPUNAVAIL]. [81.19.215.14]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Wed, 12 Jun 2019 11:15:59 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dxszz3qpvg|x-authuser|jonathan@hansfords.net
X-MailChannels-Auth-Id: dxszz3qpvg
X-Shelf-Obese: 61e0075e08e5a50c_1560338159274_2890827254
X-MC-Loop-Signature: 1560338159274:1969808845
X-MC-Ingress-Time: 1560338159274
Received: from [51.52.247.166] (port=50179 helo=[172.16.3.14]) by localhost.localdomain with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <jonathan@hansfords.net>) id 1hb1EL-00Gl8F-Bb; Wed, 12 Jun 2019 12:15:50 +0100
From: "Jonathan Hansford" <jonathan@hansfords.net>
To: "Andy Bierman" <andy@yumaworks.com>, "Kent Watsen" <kent@watsen.net>
Cc: "netconf@ietf.org" <netconf@ietf.org>
Date: Wed, 12 Jun 2019 11:16:05 +0000
Message-Id: <emac521462-2e91-4511-a7e2-4ead5327daa3@morpheus>
In-Reply-To: <CABCOCHQbUCPBu-wY_5sA2TUgsOFNGBtAtrYZ9crFJZV+=xo3Cw@mail.gmail.com>
References: <em35e87021-fa76-4888-a383-8b34e960175f@morpheus> <0100016aa75956af-70018fb1-15f8-4394-8ffd-4f4d5b2d7b3f-000000@email.amazonses.com> <CABCOCHScSp8AEjcgSd7tX-Va45y51CxK-b_hO4nd3SzW9rTUKA@mail.gmail.com> <eme2e51d99-6140-4142-b89f-db5e4c6e2a88@morpheus> <0100016ab7a9af7e-cd7f776e-79e1-42a4-9c5d-d04aed0d8fa1-000000@email.amazonses.com> <emdf557a96-2926-4d87-83f9-2f8216ed652e@morpheus> <76ED75C8-AA1A-4A03-A382-0DE834C914A1@gmail.com> <0100016abd77bfe3-88ae515a-d7f9-41c7-b627-9c51bdf16213-000000@email.amazonses.com> <CABCOCHQ-SWFCzs-FzhLe=-n+j+-AEknTuv-nKJ4etFm0srig5w@mail.gmail.com> <884391D0-3F53-4F3D-BFB0-DD333D09507C@gmail.com> <CABCOCHTLzW+2mkau0KHSbprw0e7PjNFO6SZoPyXUzkKm7gsyow@mail.gmail.com> <00d101d51216$f807d120$e8177360$@hansfords.net> <E954A8E5-B241-4655-BF04-F987EC2870C2@gmail.com> <CABCOCHRKSjEFfRvdQWZEnqMQVQd_hNdrK2r4KByiaTbb8FL3aA@mail.gmail.com> <3B2E5975-26B3-4310-B718-9D8D3F0B0DDA@gmail.com> <CABCOCHTH8Ge6Yk3KdaX-sTmcs_Cx-1U4CEvL8Mt-oLFXUQUCug@mail.gmail.com> <0100016b482fc5f4-caf4b52b-416a-438f-9c47-68df526fb9b7-000000@email.amazonses.com> <CABCOCHQbUCPBu-wY_5sA2TUgsOFNGBtAtrYZ9crFJZV+=xo3Cw@mail.gmail.com>
Reply-To: "Jonathan Hansford" <jonathan@hansfords.net>
User-Agent: eM_Client/7.2.34959.0
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="------=_MB03DBEB89-E247-46E0-A1E9-8A11845083C1"
X-Antivirus: Avast (VPS 190611-4, 11/06/2019), Outbound message
X-Antivirus-Status: Clean
X-OutGoing-Spam-Status: No, score=-1.0
X-AuthUser: jonathan@hansfords.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/3LMB7jbvpo1PTkkSwR4fuLXojlk>
Subject: Re: [netconf] RFC 6241 Ambiguity
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Jun 2019 11:16:07 -0000


On 11/06/2019 22:19:05, "Andy Bierman" <andy@yumaworks.com> wrote:

>
>
>On Tue, Jun 11, 2019 at 1:16 PM Kent Watsen <kent@watsen.net> 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.
>
With (c), how does a client know what each server has implemented, and 
how does a server know what each client has implemented? And what if 
your clients and servers have all implemented, say, (a) and then you 
need to add a client or server that has implemented (b)?
>
>>
>>
>
>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 <andy@yumaworks.com> 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 
>>><mjethanandani@gmail.com> 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 <andy@yumaworks.com> 
>>>>>wrote:
>>>>>
>>>>>
>>>>>
>>>>>On Fri, May 31, 2019 at 3:19 PM Mahesh Jethanandani 
>>>>><mjethanandani@gmail.com> 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
>>>>>>netconf@ietf.org
>>>>>>https://www.ietf.org/mailman/listinfo/netconf
>>>>
>>>>Mahesh Jethanandani
>>>>mjethanandani@gmail.com
>>>>
>>>>
>>>>
>>>_______________________________________________
>>>netconf mailing list
>>>netconf@ietf.org
>>>https://www.ietf.org/mailman/listinfo/netconf
>>

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus