Re: [netconf] RFC 6241 Ambiguity

Mahesh Jethanandani <mjethanandani@gmail.com> Thu, 16 May 2019 18:50 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 80039120153 for <netconf@ietfa.amsl.com>; Thu, 16 May 2019 11:50:07 -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_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=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 3MFGDiiEU80q for <netconf@ietfa.amsl.com>; Thu, 16 May 2019 11:50:04 -0700 (PDT)
Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (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 A971D12014F for <netconf@ietf.org>; Thu, 16 May 2019 11:50:04 -0700 (PDT)
Received: by mail-pf1-x42e.google.com with SMTP id y11so2286522pfm.13 for <netconf@ietf.org>; Thu, 16 May 2019 11:50:04 -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=9jS/WlW/gIfxe1XhyYABwY3gsddYDfzcbaE5UPJdYXU=; b=e6K3znpdSjtJ/SjCMq0esvuXep2uJUolxDEyVVk0VjaFF/NCuStlks72ijk6xmnWCm K9SC0vtKxYqLWOIah+08Cef4lQcs/3xDiwFxsyqPTCFzdNqBJTkVApdqPZZJa/NPyeIJ HJm3vRtpvqqXIws34/QtfszoKecaIyhy3F+TvtffJ1tscm3gZ/jPF/Lv0heLbf9AZWlE ar8eUUJk9yKLJ7/A6MNdvwfQ80w/tOQhDSy2WUBzwYjlVmkzAqc35Q3SoG0zdIi482rS BQ7ROFhH/Rmqi2WXGk8nZG2yf48Cgf/oj8Dry/MK7YoDVI9ZZ/jqwdvXN2T6fPmZ1iCg dxWQ==
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=9jS/WlW/gIfxe1XhyYABwY3gsddYDfzcbaE5UPJdYXU=; b=SuFUBHseMmqbkN/TJgw/pv1/2EJ2igIXfUdBnv166v7anK5X7XRFD8niS2y6szsBxh /1gyLWWIDBhkErJQ9l3XlMN4dAuzz/gS7iTSKty++0TqlgCtrnEfWEYscfRVe7nk7wSS bx55ufVT9ex5xFKyD/j8DhjV5BI4U6LwfTzGnq2I3gvbir1t2HMXQ2j+dW551l3zOppz nZfMPcOM/rGngG51r0OkDLa/L/bSgvRAndlJ458ilVNhFMW4/wFz9CGYGCBWzca1o+t+ gPREQIRWphfQCmy2VlIK2Zs1XcCvlPeyPJQnfnv01WTCa6zMT9AfZ0btrEsTStRVJhRV jumA==
X-Gm-Message-State: APjAAAXYzqRiuD7cFzpJZXrBTVDLCDHcH8tTo3qb7NnjeCRPaGhHnsAu 31HeV2EkIvl7lFIjlrW8G9kRyDL2
X-Google-Smtp-Source: APXvYqx5sJKkZ+991C4PfTJS5EEWMjiC9yJBmjheSxmGCKKz6vFEjtbSemp7k0IEnqN7tqtEALUNAA==
X-Received: by 2002:a63:d615:: with SMTP id q21mr52068852pgg.401.1558032604000; Thu, 16 May 2019 11:50:04 -0700 (PDT)
Received: from [10.33.123.214] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id r9sm11255192pfc.173.2019.05.16.11.50.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 May 2019 11:50:02 -0700 (PDT)
From: Mahesh Jethanandani <mjethanandani@gmail.com>
Message-Id: <884391D0-3F53-4F3D-BFB0-DD333D09507C@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_32F927A8-1D9B-4432-A94C-C4869544C7E3"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Thu, 16 May 2019 11:50:01 -0700
In-Reply-To: <CABCOCHQ-SWFCzs-FzhLe=-n+j+-AEknTuv-nKJ4etFm0srig5w@mail.gmail.com>
Cc: Kent Watsen <kent@watsen.net>, "netconf@ietf.org" <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>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/T8ahjN1_Fv8NBeEsyqQV_EBLoeU>
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: Thu, 16 May 2019 18:50:08 -0000

Hi Andy,

> On May 16, 2019, at 10:02 AM, Andy Bierman <andy@yumaworks.com>; wrote:
> 
> 
> 
> On Wed, May 15, 2019 at 2:48 PM Kent Watsen <kent@watsen.net <mailto:kent@watsen.net>> wrote:
> 
> 
>>> 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. 
>> 
>> I would agree.
> 
> 
> 7.8 does not say anything about the <kill-session> is for the
> session that started a confirmed commit or extended a confirmed commmit.
> It could be interpreted to mean any kill-session for any session causes
> a confirmed commit to be rolled back.  The text below is so ambiguous it
> is not even clear the <kill-session> has to be for an existing session,
> 
>       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.
> 

While the original text in 7.8 was ambiguous, Erratum 5397 does seem to clarify that the <close-session> (not <kill-session), is for the session in question, and not any session.

      If a NETCONF server receives a <close-session> request while
      processing a confirmed commit (Section 8.4) for that session, it
      MUST restore the configuration to its state before the confirmed
      commit was issued unless the confirmed commit included a <persist>
      element.
That is why I agree that Erratum 5397 should not be deleted, but should be modified to the text suggested by Jonathan.

> 
>  
> It's a minor point, but I could argue, as I wrote before, that such clarifications in 7.x are unnecessary because 8.4 provides overrides.   I prefer less text because it's easier to get right (wit this is at least the 3rd time Jonathan is at this now).  However "unnecessary" doesn't mean "wrong" and since we've already stepped in it, getting the 7.x errata right might be easier than getting 8.4 right.
> 
> 
> 
> 8.4 para 3 says the confirmed commit is not tied to a session if the persist/persist0id mechanism is used.
> 
>    If the <persist> element is not given in the confirmed commit
>    operation, any follow-up commit and the confirming commit MUST be
>    issued on the same session that issued the confirmed commit.  If the
>    <persist> element is given in the confirmed <commit> operation, a
>    follow-up commit and the confirming commit can be given on any
>    session, and they MUST include a <persist-id> element with a value
>    equal to the given value of the <persist> element.
>  
> The problematic text is actually in <cancel_commit>
> 
> 8.4.4.1.  <cancel-commit>
> 
>    Description:
> 
>          Cancels an ongoing confirmed commit.  If the <persist-id>
>          parameter is not given, the <cancel-commit> operation MUST be
>          issued on the same session that issued the confirmed commit.
> 
> In order to cancel a confirmed commit (belonging to another client, i.e
> the persist-id is not known), the client issues a <kill-session> for
> any random or non-existent session.  It would make more sense to issue a <cancel-commit>
> (maybe require superuser) instead. The access control policy for <kill-session>
> is the wrong way to configure access to cancelling a confirmed commit.
> 
> IMO these procedures are not well designed or documented, and an Errata cannot
> be used to fix it -- a new version of the protocol should fix it, in which WG and IETF consensus
> is reached for the selected solution.

Do you want to open this as a netconf-next issue?

> 
> 
> 
> 
>>> With the diff, should that be against the original text or the original erratum?
>> 
>> The diff is building on top of the original erratum. I would think a diff w.r.t. to the original erratum would make sense.
> 
> It depends, are you correcting the earlier errata or filing a new one?   Regardless, I expressed a diff for what I think the text should be (which you didn't comment on); how that is translated is up to you.
> 
> 
> Kent // contributor
> 
> 
> 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