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

Martin Bjorklund <mbj@tail-f.com> Thu, 26 September 2019 12:12 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 124CA120123 for <netmod@ietfa.amsl.com>; Thu, 26 Sep 2019 05:12:15 -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 XPQUkVL8AaMk for <netmod@ietfa.amsl.com>; Thu, 26 Sep 2019 05:12:13 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 23A26120047 for <netmod@ietf.org>; Thu, 26 Sep 2019 05:12:13 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 0F9381AE018A; Thu, 26 Sep 2019 14:12:11 +0200 (CEST)
Date: Thu, 26 Sep 2019 14:11:46 +0200 (CEST)
Message-Id: <20190926.141146.1645978108701885454.mbj@tail-f.com>
To: lhotka@nic.cz
Cc: J.Schoenwaelder@jacobs-university.de, netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <87f295bea85a4b38dd2f7775e78f53464512878b.camel@nic.cz>
References: <229de5aa1bd41ea6a30b920c9c83321903294f49.camel@nic.cz> <20190926110435.3vaqzw6pqsnker3s@anna.jacobs.jacobs-university.de> <87f295bea85a4b38dd2f7775e78f53464512878b.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=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/-l8A93jDcDDQnHRmI--EPkagvzg>
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 12:12:15 -0000

Ladislav Lhotka <lhotka@nic.cz> wrote:
> On Thu, 2019-09-26 at 11:04 +0000, Schönwälder, Jürgen wrote:
> > On Thu, Sep 26, 2019 at 12:27:17PM +0200, Ladislav Lhotka wrote:
> > > > Sure, one can discuss whether this feature is useful or harmful
> > > > but the only way to officially remove this is to create a new
> > > > specification and to run it through the IETF process.
> > > 
> > > I do insist that the wording in 7950 permits my interpretation, so I don't
> > > propose any change.
> > 
> > It does not. You cannot cherry pick sentences.
> 
> I am not aware of any cherry-picking on my side. Can you show that my
> interpretation is not possible?

8.2 says:

   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.

This means that requests can modify config this way, otherwise this
text wouldn't be there.  This is not just an intention, but follows
from the text.

>  Whatever the intent was, it is the text of the
> spec that counts.

With this logic, no client can be certain of anything; a server would
be free to reject legal requests in any way it liked.  For example it
would be perfectly fine for a server to only accept requests that
modifies a single leaf at the time.



/martin



> 
> > 
> > > What I propose instead is to remove such protocol-specific parts from the
> > > specification of the YANG language, and clarify it in the specification of
> > > individual protocols.
> > 
> > This is a different topic. Moving things around does not change the
> > meaning (unless you change things as well while moving things around).
> 
> I wrote about clarification of protocols or server behaviour, which means
> changes. It is also possible that different protocols use different approaches.
> 
> Lada
> 
> > 
> > /js
> > 
> > -- 
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod