Re: [netconf] RFC 6241 Ambiguity

Andy Bierman <andy@yumaworks.com> Tue, 04 June 2019 20:17 UTC

Return-Path: <andy@yumaworks.com>
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 9F36D1205D9 for <netconf@ietfa.amsl.com>; Tue, 4 Jun 2019 13:17:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
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 HxzNthrjjptn for <netconf@ietfa.amsl.com>; Tue, 4 Jun 2019 13:17:11 -0700 (PDT)
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58E94120048 for <netconf@ietf.org>; Tue, 4 Jun 2019 13:17:10 -0700 (PDT)
Received: by mail-lj1-x236.google.com with SMTP id v29so9696601ljv.0 for <netconf@ietf.org>; Tue, 04 Jun 2019 13:17:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IpbMLSVkcQUJIoAwiwpwdW2UVm56XZbU3UEIM1T8EFs=; b=urrhmuc6qtI507J8rwSttTSUy7sXR3nTglA/mhosYiYbnFMn4EMFRPiE0ofhIxsTIx 7VOOVopZmps/qpVPi7/Y77ZMqSjGC78f6+SAVjmQ3Ke6JjhgsjHvl8UWdp2xfA/Qp1vG x2tLcw9caeIPWnNeDNPtW7FsPGQ7JyCSAZAF9jV/pWwDjVjWfd2sAT+28rNjZhV/rlC/ w/+XRb7tIujjP4he66U6Or/ZSYd+zwao/IwE36aNR0OGlf5wFYoWbZKiBlEp9o4hbUva JUXONFWE3f2Kqkdz/ccBfR0hj8ov18rC0M0nYuLl55HkJj/S/iHq0n8h+GY8PktYGzQy hH5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IpbMLSVkcQUJIoAwiwpwdW2UVm56XZbU3UEIM1T8EFs=; b=OqkMPgW4OgOsT7ghFrXES1bA0g6Q53sFWL9U4NTv4b7iQVaxXwK/Ws5vgh7jqsQt83 CiXre1bmxTrMMWVmF8cgeZbKjfaZCCVHpi2tkpJ8LV4BmOmMxvrmiOqEHs2tDJDnHShA KEDraShFy5y6d5isHY7zx/5t2KhXQAnCXLZRQdnqp/6BwehCG59VWH+mr+mbmL5UlqVE bTbP87tMjCVC4km3432Lv27P47wZO9kZdcexMxsjwioNnf7W4o8gQDKutjKe5Mkxr3zS C/CEL0ChI8w6DKDDI5qremCd5VcnbjxxeOIUJjc+TSZ0NWmD9c05+psJBukbw3M1M7Cd I8dA==
X-Gm-Message-State: APjAAAWb8eDSVD/QJxv6PeobmNbsvWaz7pJlq2Q9866P8v0Uf9lXwqF9 YtDXOgvBVm+t2cUyMWsXrxkyouLVGMicgFgjecj6Yg==
X-Google-Smtp-Source: APXvYqyQ6Mu86VsDAXtmiBeFO0q7gyqnGAK7HSpschAO/PM5eQAmT0kos6aZNqLum7vSz+fUtVgQxAeJFJkytnoNel0=
X-Received: by 2002:a2e:b0ee:: with SMTP id h14mr15255905ljl.171.1559679428346; Tue, 04 Jun 2019 13:17:08 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <3B2E5975-26B3-4310-B718-9D8D3F0B0DDA@gmail.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Tue, 4 Jun 2019 13:16:56 -0700
Message-ID: <CABCOCHTH8Ge6Yk3KdaX-sTmcs_Cx-1U4CEvL8Mt-oLFXUQUCug@mail.gmail.com>
To: Mahesh Jethanandani <mjethanandani@gmail.com>
Cc: Netconf <netconf@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004a5f21058a852a97"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/K82rWEPXnLB8b3bk8yA0-rXuvBA>
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: Tue, 04 Jun 2019 20:17:15 -0000

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
>
>
>
>