Re: [netconf] RFC 6241 Ambiguity

"Jonathan Hansford" <jonathan@hansfords.net> Wed, 12 June 2019 13:39 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 0D4A412011A for <netconf@ietfa.amsl.com>; Wed, 12 Jun 2019 06:39:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] 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 zesxV7MND4Ta for <netconf@ietfa.amsl.com>; Wed, 12 Jun 2019 06:39:34 -0700 (PDT)
Received: from aye.elm.relay.mailchannels.net (aye.elm.relay.mailchannels.net [23.83.212.6]) (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 7C3971200C7 for <netconf@ietf.org>; Wed, 12 Jun 2019 06:39:33 -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 6C7FD342589; Wed, 12 Jun 2019 13:39:31 +0000 (UTC)
Received: from mail.myfast.site (100-96-14-97.trex.outbound.svc.cluster.local [100.96.14.97]) (Authenticated sender: dxszz3qpvg) by relay.mailchannels.net (Postfix) with ESMTPA id 8166E3425F3; Wed, 12 Jun 2019 13:39:29 +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 13:39:31 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dxszz3qpvg|x-authuser|jonathan@hansfords.net
X-MailChannels-Auth-Id: dxszz3qpvg
X-Share-Tart: 20e6e0bc13688fd9_1560346770868_3204188455
X-MC-Loop-Signature: 1560346770868:571585063
X-MC-Ingress-Time: 1560346770864
Received: from [51.52.247.166] (port=50708 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 1hb3TE-00HKeF-3y; Wed, 12 Jun 2019 14:39:21 +0100
From: "Jonathan Hansford" <jonathan@hansfords.net>
To: "Kent Watsen" <kent+ietf@watsen.net>, "netconf@ietf.org" <netconf@ietf.org>
Date: Wed, 12 Jun 2019 13:39:35 +0000
Message-Id: <em8ac8a7c4-85cd-4797-8992-ab6878bff60e@morpheus>
In-Reply-To: <0100016b4bc86abb-d69f575f-c2e7-4ce9-93a5-047262cbff75-000000@email.amazonses.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> <0100016b4bc86abb-d69f575f-c2e7-4ce9-93a5-047262cbff75-000000@email.amazonses.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="------=_MB6F74EDAB-E7B5-4C41-837B-E8C09189928D"
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/fi0qlysI3kJjp4ov6-70WMFDX5g>
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 13:39:36 -0000


On 12/06/2019 14:02:34, "Kent Watsen" <kent+ietf@watsen.net> wrote:

>
>>>   a)  'persist' MUST span reboots.
>>>   b)  'persist' MUST NOT span reboots.
>>>   c) it is an implementation decision as to if 'persist' spans 
>>>reboots.
>>>
>>>[...]
>>
>>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
>>
>>[...]
>>
>>I think (c) is OK since it not 100% clear what the scope of "unless" is in para 5.
>
>If (a) is not possible, and (b) excludes [IoT] devices that must reboot 
>for each commit, then (c) becomes the front runner.
If (a) is not possible, how can it be an implementation decision whether 
'persist' spans reboots? If (a) is not possible, only (b) is left and 
IoT devices that must reboot for each commit are excluded.
>
>
>The text could be curt and just state “it is an implementation decision 
>as to if 'persist' spans reboots.”
>
>But it might be helpful to elaborate along the lines of “devices that 
>require a reboot in order to commit SHOULD..., other devices MAY...”.
>
>As to how a client can determine the server’s behavior, given this is 
>just Errata, it would be inappropriate to define a ‘feature’.   How 
>about:
>
>“This document does not provide a mechanism enabling a client to 
>determine if a server supports the ‘persist’ behavior over reboots, or 
>if a server requires a reboot in order to effect configuration 
>changes.“
>
>???
>
>Kent // contributor

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