Re: [netconf] RFC 6241 Ambiguity

Andy Bierman <andy@yumaworks.com> Tue, 25 June 2019 22:57 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 6CEEB1200B5 for <netconf@ietfa.amsl.com>; Tue, 25 Jun 2019 15:57:16 -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 Ib1ngRP92KZo for <netconf@ietfa.amsl.com>; Tue, 25 Jun 2019 15:57:12 -0700 (PDT)
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 F2C8112002E for <netconf@ietf.org>; Tue, 25 Jun 2019 15:57:11 -0700 (PDT)
Received: by mail-lf1-x12f.google.com with SMTP id b11so178538lfa.5 for <netconf@ietf.org>; Tue, 25 Jun 2019 15:57:11 -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=yLABkphDILmuS2hqMl4E0cp2XwV0DBF1WGekpCna43w=; b=l033yN6qUgpJnoV6LXagHCnNZqvzH2tsFd9FFBSOsoweI64fVqXu3WtmcIpIyoVhRV bLH+V/DTg67Vf7draKyyYSwq8yHXwyJ8TuqwmmNlTAycji6FJqza1zzFfK9e/chi8Bo/ SgepZngs2IrDbZz8P2YXMvZ60bZwcBwOF+mRPxCdKSseLpI2F7HpXEzJ2V/qTFHAPcB4 2zTCxf+o+0WoGmU2/N7hN+6e1jjq/y0vI3E5xL2wK4R/HTFFLRIlN9O5tWK+Kgl4kWyd TR+7jqhlXAC1Te39P8E7T5TQSo662YixovtDcWC1tc2+Xzyi6+Bun8VSV4iz59D12Q8N HQvg==
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=yLABkphDILmuS2hqMl4E0cp2XwV0DBF1WGekpCna43w=; b=ifCnfC1IhnEX+iZWu6xPzsYX2A1pGwrDWdBu6liKSD5d52UfXR4pV13dNaC/zqC6Ev sJcDptcRevnoz+jWQiW10ngQtBAsYvQPFOWSDmXFv7qZQ6q/Or1D3HtyNEbW98XLkKav XiYkbKuQJazQd9WgcLcVsbevhwy4rmFVGEArbZUaK/c/hvsgbq8PNngdqPGadn/LB0J7 lcUo8XiaLgXUKWhk1q39Ab1fpLzYjDtTkYTaf+63vnartw1J3nF0CJKGc253vFezU4yq 2wCk4+90yspNNwiFZSu4Os8Md8PVX8dhlSDHvwvYolx/IgHWThf1+pjkfVMQQIBpZYf4 IczQ==
X-Gm-Message-State: APjAAAWqBuTMRaS55HVBSe4nev1FbxZQJxONtjvLMMcvkIZuwdOVfdJY 0r06yU4unCjrL/aaiAdvsedQ9Y/dy8NiN2DjwJCx1Q==
X-Google-Smtp-Source: APXvYqzj6vzJb3cpCMTEBSHnDQzhpS+eXThKt0k1M+i8aclW9RT3czq+tTQOC4yG9LOJNngoH9ipMxCSbmtjOJgnA74=
X-Received: by 2002:ac2:514b:: with SMTP id q11mr662080lfd.33.1561503429894; Tue, 25 Jun 2019 15:57:09 -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> <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> <CABCOCHQct9XP86LsGU3qkUkNKfcoSttdmnUqLLG_JP1wfcLe3w@mail.gmail.com> <0100016b4d55fbaf-7f6ae36b-0a00-4b10-a6c0-22fd0401a5e2-000000@email.amazonses.com> <CABCOCHQJ96hXxD19E_KQJ2quHxiUwSivn-Ei0sGWoYDFwM6Qxw@mail.gmail.com> <3204AB2C-3B67-419A-851E-9BA8BEB2273A@gmail.com>
In-Reply-To: <3204AB2C-3B67-419A-851E-9BA8BEB2273A@gmail.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Tue, 25 Jun 2019 15:56:58 -0700
Message-ID: <CABCOCHRprs7hBOcNqamLRdeP67LZafHe_pczsACFzczpXHUxAA@mail.gmail.com>
To: Mahesh Jethanandani <mjethanandani@gmail.com>
Cc: "netconf@ietf.org" <netconf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000414196058c2dd940"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/ws2PdeItWnUzJssJ0ffhtef5O2o>
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, 25 Jun 2019 22:57:16 -0000

Hi,

these changes look OK to me.

Andy


On Tue, Jun 25, 2019 at 11:03 AM Mahesh Jethanandani <
mjethanandani@gmail.com>; wrote:

> Summarizing the list of changes that we seem to have agreed upon:
>
> For the first set of changes in section 7.8 and 7.9, we seem to agree on
> the original set of changes I had sent out earlier, which essentially
> deferred the discussion of confirmed commit to section 8.4 of the RFC. The
> second set of changes updates Section 8.4.1 to explain what happens to a
> confirmed commit that includes a <persist> element.
>
> The highlights in the sections should enable identifying the changes.
>
> *CHANGE 1 START*
>
> 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>
>
> *CHANGE 1 END*
>
> *CHANGE 2 START*
> 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, in which case the server MAY continue
>    the confirmed commit procedure.
>
> *CHANGE 2 END*
>
> Finally, looking at the current set of Errata that are already open
> against the RFC, we (the chairs) believe that Errata number 5397 should be
> deleted and (a new Errata with these contents) be posted. This is being
> done to avoid stacking one Errata on top of another.
>
> Unless there is objection to these changes within the next two weeks, we
> will proceed with submitting them to the RFC Editor.
>
> On Jun 12, 2019, at 2:47 PM, Andy Bierman <andy@yumaworks.com>; wrote:
>
> Hi,
>
> This is the new text in question:
> It appears your intent is (c) since there is no mention at all what
> happens if
> <persist> was included.  The text just says what does not happen in this
> case.
>
>
>>>    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.
>>>
>>
>
> How about adding at the end:
>
> OLD:
>
> element.
>
> NEW:
>
> element, in which case the server MAY continue the confirmed commit
> procedure.
>
>
> Andy
>
>
>
> On Wed, Jun 12, 2019 at 1:16 PM Kent Watsen <kent+ietf@watsen.net>; wrote:
>
>>
>> Hi Andy,
>>
>> I object to changing RFC 6241 with an Errata if it attempts to enforce
>> protocol behavior
>> that the original RFC does not actually specify.  (c) is correct for an
>> Errata because the original RFC
>> is under-specified.  Or perhaps: (d) 'persist' MAY span reboots
>>
>>
>> It sounds like we're in agreement.  Are you objecting to something I
>> wrote in particular?
>>
>> Kent // contributor
>>
>>
>>
> Mahesh Jethanandani
> mjethanandani@gmail.com
>
>
>
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>