Re: [netconf] RFC 6241 Ambiguity

Mahesh Jethanandani <mjethanandani@gmail.com> Tue, 04 June 2019 19:48 UTC

Return-Path: <mjethanandani@gmail.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 E9AB61205D9 for <netconf@ietfa.amsl.com>; Tue, 4 Jun 2019 12:48:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=gmail.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 P1PTESuCg3GN for <netconf@ietfa.amsl.com>; Tue, 4 Jun 2019 12:48:00 -0700 (PDT)
Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 0C70512013B for <netconf@ietf.org>; Tue, 4 Jun 2019 12:48:00 -0700 (PDT)
Received: by mail-pf1-x436.google.com with SMTP id a23so13327813pff.4 for <netconf@ietf.org>; Tue, 04 Jun 2019 12:48:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=CnCmTNHL+9k3ZhZ+lUAO4MJLPtRMl8P3Qrfgnf8MDp8=; b=nCZl65fwc/PiWUi5OJZU4xAyMXyse3MomTDCcqMIIMnfOGRK2v+lQiaDx87WlJEn6P Yi0fBEa5b/OdM32bXqKsiPXevPR0H/9vqawC5oN7vdTHcUtyOUdUJJJgXBM3LsPb6kgj K36+u333KNb5pvJiKJSquxZcLiBY6EkC4tGs28SLgvJJ8wH6usBa9M27eTIKttb8exJr RMkgLWPen0QUsHY/3Um/QAz8d2+oJXtydHwv8RJaXLhUxKcuEfLAfYQp9TPI1v2qFHYY ZvZoMTDd6C3KfLmyo/BFsltuvcnSeiu8Y0Iw7psHtHcD8Z0e9i/nI16s6F5jwrYxOJab LtfQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=CnCmTNHL+9k3ZhZ+lUAO4MJLPtRMl8P3Qrfgnf8MDp8=; b=M/VwSLrMOqT/L9c0kTHKX+4yJOZSBb2WZLkPuY9aUs4jB0hiypDguiPgdlbL0dr/Ki 4vKlUvO6RakAR7T2q6IPpqjonYHQRj5k42dunsdrG3u1LslrdWf2/j62DBpfHE7ptLRs ipIeijeVXk5DTVeBVYqAj/FVMpTKgtrrIGNY6pOJ/UsDFQmFtRzoRcyiYLYQ6dLj1+Ku TsYrR4F1ohnByaDjC2VDAm9cbG3dZhwhtpxRhse4wQIzZncAP921hSJCRisI35EWNcYY +/QV324Q8vtGSzpVtbdHS9Q3eA4V03uY2zizPlwXUsditm7GLElkbNHjWgj6FgHZMyO/ aXAA==
X-Gm-Message-State: APjAAAU7j4v74VBjV6xGoX+oMf7xFcOvOh27dRBHxgdT+/iZZSW8xZ2/ z7z17rQVP8/x8mFUnV0UTEpVxHun
X-Google-Smtp-Source: APXvYqzQALLxD3uTjRTXCJaobrmZnmi+ROsKbZ19KXbhXZ8YgvCDNR+Xiaw9GCLCVRiFgYLWF0hrKA==
X-Received: by 2002:a17:90a:29c5:: with SMTP id h63mr5469045pjd.83.1559677679216; Tue, 04 Jun 2019 12:47:59 -0700 (PDT)
Received: from [10.33.123.214] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id c142sm20652466pfb.171.2019.06.04.12.47.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Jun 2019 12:47:57 -0700 (PDT)
From: Mahesh Jethanandani <mjethanandani@gmail.com>
Message-Id: <3B2E5975-26B3-4310-B718-9D8D3F0B0DDA@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7ED1B3B9-8237-4A60-9877-2B203068A164"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Tue, 4 Jun 2019 12:47:56 -0700
In-Reply-To: <CABCOCHRKSjEFfRvdQWZEnqMQVQd_hNdrK2r4KByiaTbb8FL3aA@mail.gmail.com>
Cc: Netconf <netconf@ietf.org>
To: Andy Bierman <andy@yumaworks.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>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/ydG2ujf9bDvCefB-pwupQP1Jk7o>
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 19:48:04 -0000

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 <mailto: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 <mailto:netconf@ietf.org>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
Mahesh Jethanandani
mjethanandani@gmail.com