Re: [netmod] 答复: 答复: Please clarify implementation about ‘when’

Martin Bjorklund <mbj@tail-f.com> Thu, 26 September 2019 07:45 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BEFD120820 for <netmod@ietfa.amsl.com>; Thu, 26 Sep 2019 00:45:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 6ej4ElD820BU for <netmod@ietfa.amsl.com>; Thu, 26 Sep 2019 00:45:53 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 40A7B12083F for <netmod@ietf.org>; Thu, 26 Sep 2019 00:45:53 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id A84511AE018A; Thu, 26 Sep 2019 09:45:51 +0200 (CEST)
Date: Thu, 26 Sep 2019 09:45:26 +0200 (CEST)
Message-Id: <20190926.094526.272771637371098799.mbj@tail-f.com>
To: lhotka@nic.cz
Cc: andy@yumaworks.com, jason.sterne@nokia.com, netmod@ietf.org, yangang@huawei.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <9bc06f9f3f1c87c79ccce4e1c4d40755c804875a.camel@nic.cz>
References: <87h84z4kmw.fsf@nic.cz> <20190926.085644.1268671875357328723.mbj@tail-f.com> <9bc06f9f3f1c87c79ccce4e1c4d40755c804875a.camel@nic.cz>
X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/S21vkw1nHtJgdZKqzdzz86FP0YY>
Subject: Re: [netmod] =?utf-8?b?562U5aSNOiDnrZTlpI06IFBsZWFzZSBjbGFyaWZ5IGlt?= =?utf-8?b?cGxlbWVudGF0aW9uIGFib3V0IOKAmHdoZW7igJk=?=
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Sep 2019 07:46:07 -0000

Ladislav Lhotka <lhotka@nic.cz> wrote:
> On Thu, 2019-09-26 at 08:56 +0200, Martin Bjorklund wrote:
> > Ladislav Lhotka <lhotka@nic.cz> wrote:
> > > Andy Bierman <andy@yumaworks.com> writes:
> > 
> > > 
> > 
> > > > On Wed, Sep 25, 2019 at 8:44 AM Sterne, Jason (Nokia - CA/Ottawa) <
> > 
> > > > jason.sterne@nokia.com> wrote:
> > 
> > > >
> > 
> > > >> Processing order should not matter. The evaluation of the 'when'
> > statement
> > 
> > > >> should be done assuming an atomic application of the edit-config.
> > 
> > > >>
> > 
> > > >>
> > 
> > > >>
> > 
> > > >> I agree that a standards compliant server should do as Rob said:
> > 
> > > >>
> > 
> > > >>
> > 
> > > >>
> > 
> > > >> - For “scene 1”, the config change is accepted because the result of the
> > 
> > > >> config datastore after the edit-config has been applied is valid.
> > 
> > > >>
> > 
> > > >> - For “scene 2”, the config change is rejected because the result of the
> > 
> > > >> config datastore after the edit-config has been applied is invalid.
> > 
> > > >>
> > 
> > > >>
> > 
> > > >>
> > 
> > > >> From an implementation that may indeed mean processing the 'when' after a
> > 
> > > >> first pass that sets the various leafs to tentative values. But that's
> > 
> > > >> implementation detail.
> > 
> > > >>
> > 
> > > >>
> > 
> > > >>
> > 
> > > >> IMO the auto-clearing behavior of 'when' may be complicated but that is
> > 
> > > >> how it is defined (same with 'choice'). Clients can and should depend on
> > 
> > > >> things being automatically deleted. If you want validation errors (i.e.
> > 
> > > >> force the client to clear all the dependant leafs instead of auto-
> > clearing)
> > 
> > > >> then use a 'must' statement.
> > 
> > > >>
> > 
> > > >>
> > 
> > > >>
> > 
> > > >
> > 
> > > > +1
> > 
> > > >
> > 
> > > > YANG clearly defines "must" and "when" with different behavior.
> > 
> > > > A server that does not implement the auto-delete aspects of when-stmt is
> > 
> > > > not compliant to the RFC.
> > 
> > > 
> > 
> > > I don't agree with this. RFC 7950 says in sec. 8.1:
> > 
> > > 
> > 
> > >    The following properties are true in all data trees:
> > 
> > > 
> > 
> > >    ...
> > 
> > > 
> > 
> > >    o  There MUST be no nodes tagged with "when" present if the "when"
> > 
> > >       condition evaluates to "false" in the data tree.
> > 
> > 
> > It also says in 8.2:
> > 
> >    o  If a request modifies a configuration data node such that any
> >       node's "when" expression becomes false, then the node in the data
> >       tree with the "when" expression is deleted by the server.
> 
> Right. But the request won't modify a configuration data node because it is
> rejected. So the premise of the above implication doesn't hold, and the
> conclusion doesn't apply.

With the same logic you can claim conformance if you reject a request
to create nodes under a case if another case is active.  I think it is
quite clear that this auto-deletion is part of the spec, and something
clients can rely on.  If the intention had been that this was optional
to implement, it would have been clearly stated, and there would have
been mechanism present for clients to detect this.


/martin