Re: [netconf] RFC 6241 Ambiguity

"Jonathan Hansford" <jonathan@hansfords.net> Wed, 15 May 2019 10:24 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 5EC8A120047 for <netconf@ietfa.amsl.com>; Wed, 15 May 2019 03:24:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.99
X-Spam-Level:
X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hansfords.net
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 fo1h65gOTizZ for <netconf@ietfa.amsl.com>; Wed, 15 May 2019 03:24:47 -0700 (PDT)
Received: from mail.myfast.site (mail.myfast.site [109.203.117.12]) (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 8E89612002E for <netconf@ietf.org>; Wed, 15 May 2019 03:24:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hansfords.net; s=default; h=Content-Type:Mime-Version:Reply-To:References: In-Reply-To:Message-Id:Date:Cc:Subject:To:From:Sender: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=DXPHlKfhZM42+TDdII5X1XhWma7V44XNdvm7oyJlmmY=; b=fyhUcrCRouZKm//c3ufey7CPq thIUSgtRqoO/RTQhf8h+xLUji3JsBYv75QF2nm2MxP+D3eL6pF2wNh9wref5l1eAIvTGobBRo4raE XUDp73oCGjQGBa7prtB//vcx+X4wsNF51yKxg45jpDR8K6yDqcTQS+rvBqvAAodeibo7g9qUma8dd Rx/vYM7E/s6EqJhstPhnadfeVPhbWE5tvCJM8FSSJ4tcVqVS/lg72iFP5e8ldiyFFlsAsQxovRwmh lX++tby3+S0gV0EYCwfWVnKAqoP+EOkNbobB/TeJf6+Xs3o4k7tJWZn9GIxmyuhz306+QOUdznIfq JiLE+toYQ==;
Received: from [51.52.247.166] (port=52628 helo=[172.16.3.14]) by mail.myfast.site with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <jonathan@hansfords.net>) id 1hQr5Y-0007fn-JV; Wed, 15 May 2019 11:24:44 +0100
From: "Jonathan Hansford" <jonathan@hansfords.net>
To: "Kent Watsen" <kent@watsen.net>
Cc: "Andy Bierman" <andy@yumaworks.com>, "netconf@ietf.org" <netconf@ietf.org>
Date: Wed, 15 May 2019 10:24:46 +0000
Message-Id: <emdf557a96-2926-4d87-83f9-2f8216ed652e@morpheus>
In-Reply-To: <0100016ab7a9af7e-cd7f776e-79e1-42a4-9c5d-d04aed0d8fa1-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>
Reply-To: "Jonathan Hansford" <jonathan@hansfords.net>
User-Agent: eM_Client/7.2.34959.0
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="------=_MB205F4328-83AA-45FD-994B-642C0A13368D"
X-Antivirus: Avast (VPS 190515-0, 15/05/2019), Outbound message
X-Antivirus-Status: Clean
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - mail.myfast.site
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - hansfords.net
X-Get-Message-Sender-Via: mail.myfast.site: authenticated_id: jonathan@hansfords.net
X-Authenticated-Sender: mail.myfast.site: jonathan@hansfords.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/8x-Zyd6mpFjdqdzvsq7faW5mAAA>
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, 15 May 2019 10:24:50 -0000

Kent,

I don't think Erratum 5397 should be deleted. Though the original 
section 7.8 makes no mention of confirmed commits, section 7.9 does, but 
does not differentiate between a vanilla confirmed commit and a 
persistent confirmed commit. Since a persistent confirmed commit is 
still a type of confirmed commit, without clarification the second 
paragraph of the description would seem to apply.

With the diff, should that be against the original text or the original 
erratum?

Thanks,

Jonathan


On 14/05/2019 19:45:12, "Kent Watsen" <kent@watsen.net>; wrote:

>
>>  So I need to contact the RFC Editor to correct Erratum 5397, with the relevant text in sections 7.8 and 7.9 being changed to something like:
>>
>>  7.8: "If a NETCONF server receives a <close-session> request while processing a confirmed commit (Section 8.4) for that session, unless the confirmed commit is a persistent confirmed commit, it MUST restore the configuration to its state before the confirmed commit was issued. A persistent confirmed commit MUST survive session termination."
>>
>>  7.9: "If a NETCONF server receives a <kill-session> request while processing a confirmed commit (Section 8.4) for the session to be killed, unless the confirmed commit is a persistent confirmed commit, it MUST restore the configuration to its state before the confirmed commit was issued. A persistent confirmed commit MUST survive session termination."
>
>Ideally, Errata 5397 is deleted (because I think that it's clear that Section 8.4 overrides the 7.8 behavior) but, if we have to patch the errata, I might suggests:
>
>For Section 7.8
>   OLD (in RFC 6241)
>
>     The server will release any locks
>     and resources associated with the session and gracefully close any
>     associated connections.
>
>   NEW:
>
>     The server will release any locks
>     and resources, associated with the session and gracefully close any
>     associated connections.  As an exception to the previous sentence, if
>     the session is processing a persistent confirmed commit (Section 8.4),
>     the resources necessary for supporting confirmed commit are not released.
>
>For Section 7.9:
>   OLD (in RFC 6241)
>
>       If a NETCONF server receives a <kill-session> request while
>       processing a confirmed commit (Section 8.4), it MUST restore the
>       configuration to its state before the confirmed commit was issued.
>
>   NEW:
>       What you have above seems fine, though I'd leave off the last sentence.
>
>
>>  I also need to contact the RFC Editor to correct Erratum 3821 to change:
>>
>>  If the session issuing a sequence of one or more confirmed commits is
>>  terminated for any reason before the confirm timeout expires, the server
>>  MUST restore the configuration to its state before the sequence of
>>  confirmed commits was issued, unless the last confirmed commit also
>>  included a <persist> element.
>>
>>  If the device reboots for any reason before the confirm timeout
>>  expires, the server MUST restore the configuration to its state
>>  before the sequence of confirmed commits was issued.
>>
>>  to something like:
>>
>>  If the session issuing a sequence of one or more confirmed commits is
>>  terminated for any reason before the confirm timeout expires, the server
>>  MUST restore the configuration to its state before the sequence of
>>  confirmed commits was issued, unless the confirmed commit is a
>>  persistent confirmed commit.
>>
>>  If the device reboots for any reason before the confirm timeout
>>  expires, unless a persistent confirmed commit is in progress, the
>>  server MUST restore the configuration to its state before the
>>  sequence of confirmed commits was issued.
>>
>>   A persistent confirmed commit MUST survive session termination.
>>
>
>This seems okay but, again, I'd leave out the last sentence.
>
>
>Side note: huge errata are hard to read without a diff.  If a lot of text, then the NEW (or the NOTES) should include a diff highlighting exactly what changed.
>
>Kent // contributor
>
>
>
>>  Are those errata OK?
>>
>

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