Re: [netconf] RFC 6241 Ambiguity

Andy Bierman <andy@yumaworks.com> Mon, 03 June 2019 15:24 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 3FAD712033D for <netconf@ietfa.amsl.com>; Mon, 3 Jun 2019 08:24:20 -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, 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, URIBL_BLOCKED=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 gyB7YAGR5FvA for <netconf@ietfa.amsl.com>; Mon, 3 Jun 2019 08:24:17 -0700 (PDT)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 8F64C120343 for <netconf@ietf.org>; Mon, 3 Jun 2019 08:24:16 -0700 (PDT)
Received: by mail-lf1-x136.google.com with SMTP id y13so13910874lfh.9 for <netconf@ietf.org>; Mon, 03 Jun 2019 08:24:16 -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=+m0OmvyDgB8nLpB07zUqdawiX97rtnTLUkUDDEy7VuI=; b=kwnC2uNWVlIq0i9ymkYbT2D76FJ81vXBG5TJMtYasObOOIefsSGxrGZS3EGUxBEZRb Lv2d9afkknq79ZaMhaFqhG4PSmOQG7IYhHe2QmbLQ0GEJwIJmvZAcVPkRqqrVBgNFs5w jmSmP8Fo6lRyJ/IeYmwted5gl9utkZfjJneXrP4c97wUOlCOBbRjEmZ78LqU2G3hyy9U LVy2CS/W8vgJpuaxCy3Veux54mZBZHeCGtk/njjd2lxQPaNHHMlF0GGnqSOXGh1FSaDV u75HGhz0zZNrnJZrAEZKMkDZ51Gq0TroI1CXHGdB8SRbeh3e7DoabVNPd9IbPnCbmiiO DqRg==
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=+m0OmvyDgB8nLpB07zUqdawiX97rtnTLUkUDDEy7VuI=; b=dD+3IgzlBhyzMAGNTPzFag09zJbaYptm5q9PTZxKc24vdw88EjDkHtLCN3b9ypfOx/ 0MwjhRUKALApiBlkWOPiKqMcvjjBRWSXHH91OZoKSyPzKtRtRv0uKTgXJj/FeM53aUM5 IExfHmGQEtik3DhJYCY7ktBgggTOGPpmPEJuP/OlqXiSrI+ZuDVFUNBrKvuKkCiBQxDU hRO5aXkQ/HRo36uad7nhjaQ0q3hCQY+bin7VZC1xrJYO2zJ7K6TPnd7Wwp+WHhc/7GKX +D8/xjiSp9kLKLtzBzFzpDiquLmpKB5j6Tf1b7KQGZnUfxt1WUwafYh4SfnODwB2Th2h ZhcQ==
X-Gm-Message-State: APjAAAUXMr3Ugs5vboV451Vhu5IphWMmKDC6BQC04s824pPiNVd845LL qk8x2sDtytPG39gxN+ZnHRS0vEqlUNXt72hwxjATEQ==
X-Google-Smtp-Source: APXvYqz1QY1TvSYhnbzre05m8CbEs6vySOjBFIo4H7xlaGfKN2ETBY+60aZxat2F0OZKf2U/RLAD/RYxQMy8GouOU0A=
X-Received: by 2002:ac2:4202:: with SMTP id y2mr7806012lfh.178.1559575454445; Mon, 03 Jun 2019 08:24:14 -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>
In-Reply-To: <E954A8E5-B241-4655-BF04-F987EC2870C2@gmail.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Mon, 3 Jun 2019 08:24:03 -0700
Message-ID: <CABCOCHRKSjEFfRvdQWZEnqMQVQd_hNdrK2r4KByiaTbb8FL3aA@mail.gmail.com>
To: Mahesh Jethanandani <mjethanandani@gmail.com>
Cc: Netconf <netconf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f68c62058a6cf419"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/qMI00Yoamb2BHIG9lUOHYAMULvI>
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: Mon, 03 Jun 2019 15:24:20 -0000

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
>