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

Andy Bierman <andy@yumaworks.com> Thu, 26 September 2019 14:33 UTC

Return-Path: <andy@yumaworks.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 ADEEC120271 for <netmod@ietfa.amsl.com>; Thu, 26 Sep 2019 07:33:34 -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 eZSNDFI9O6KS for <netmod@ietfa.amsl.com>; Thu, 26 Sep 2019 07:33:31 -0700 (PDT)
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 484861201DB for <netmod@ietf.org>; Thu, 26 Sep 2019 07:33:31 -0700 (PDT)
Received: by mail-lj1-x236.google.com with SMTP id n14so2407970ljj.10 for <netmod@ietf.org>; Thu, 26 Sep 2019 07:33:31 -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=Y3DeIegahKwRpkvjqdK8blOZzG+1hjB5HX2tRbJQvWw=; b=RN6RfBWPJEKmq5pP0g1Ke5O91uf+SteVrdjhbXNSCQgxZJh5uXChAMBp3rLPhFqAZC Yc43gUIZKw27RfPjfSiOcnb2GRhGSiCI9EnHle1bqW9Y7aaBkWtjmjwY1i+VJwJbl/6v VHyJza9ouxJDQWvEIGA1h6fL8DdR/amWrgjpPUKax77BRiJa1JLSbrtIhsn9IzX0NsqC LIVmUoMJDCbntzjLwL0jOnH9UnScos14iq4swaBRsRfVjOakKb9IqszILFvIU8psoRBc WBq8eDxsouoJElYxS1fGMUQkz0FrNj8W+ghSqVhIRG4BnPmrz5yJj6q43Za1TpGjnv7P B/1A==
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=Y3DeIegahKwRpkvjqdK8blOZzG+1hjB5HX2tRbJQvWw=; b=Sw1kE0dmzLBf0ntPZo6s4lbRI9+V04aAoBvphNT6kaDgdCl8qnMBlz+poPFf52yaqS 1cXJOO4tSIOjqW//NqAMAV1UEfQacBShfxzlrqCuRqpkXg8RRNm3Hc1L0PIKpGkcvHor TcLQ9eXCvbyev2jJvbTpv5VMxQL0GZpJu6DkHsYbUlbj9Ox7JItMecLTgLMBqxfwSEdF a++g6iLPNepuFka34CWwklzIwRHsKQk5OlK5yZhHM79A83s13rayQisqVfqfSChTFVgN pMoPH5pW0jpQdxfuOeJYC8ZKfedapdAPkraoY69PSTv1GVMa0qZytGvzhcR5yDQM/9x2 FueA==
X-Gm-Message-State: APjAAAXLDvTsRslRaGfVTokCNwEXXV4Z5fgZXG+wEN49kWRFzUR7BHt7 5/9ZrpNH0bFbCBkOZF9NI71nr0cosqN6dxAGGUv+lg==
X-Google-Smtp-Source: APXvYqyhfXV6nDqM4UvS/Fg822kat6re75TNkenbl5+SC7P0zvFP6wH+Kfri9IijqEoQAPXyGtet6zgJmN5HPrvU6Is=
X-Received: by 2002:a05:651c:104b:: with SMTP id x11mr2904319ljm.218.1569508409329; Thu, 26 Sep 2019 07:33:29 -0700 (PDT)
MIME-Version: 1.0
References: <87h84z4kmw.fsf@nic.cz> <20190926.085644.1268671875357328723.mbj@tail-f.com> <9bc06f9f3f1c87c79ccce4e1c4d40755c804875a.camel@nic.cz> <20190926.094526.272771637371098799.mbj@tail-f.com> <MN2PR11MB4366078636D6030398489551B5860@MN2PR11MB4366.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB4366078636D6030398489551B5860@MN2PR11MB4366.namprd11.prod.outlook.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Thu, 26 Sep 2019 07:33:18 -0700
Message-ID: <CABCOCHQzmDjH+7wqFmrSsnaD0T_Q1LPsDi0yuY9Ow2gSvef4SA@mail.gmail.com>
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>
Cc: Martin Bjorklund <mbj@tail-f.com>, "lhotka@nic.cz" <lhotka@nic.cz>, "netmod@ietf.org" <netmod@ietf.org>, "yangang@huawei.com" <yangang@huawei.com>
Content-Type: multipart/alternative; boundary="00000000000035e418059375a77b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/fsCGGXdR68_qbtHiLPxVf-NTy_g>
Subject: Re: [netmod] 答复: 答复: Please clarify implementation about ‘when’
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 14:33:35 -0000

On Thu, Sep 26, 2019 at 3:32 AM Rob Wilton (rwilton) <rwilton@cisco.com>
wrote:

>
>
> > -----Original Message-----
> > From: netmod <netmod-bounces@ietf.org> On Behalf Of Martin Bjorklund
> > Sent: 26 September 2019 08:45
> > To: lhotka@nic.cz
> > Cc: yangang@huawei.com; netmod@ietf.org
> > Subject: Re: [netmod] 答复: 答复: Please clarify implementation about
> > ‘when’
> >
> > > >
> > > > 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.
> >
> I don't like the 'when' behaviour, I would have rather that clients were
> forced to delete the configuration explicitly (or pass an option for an
> implicit delete).
>
>
I hear the opposite from customers.
They insist that the server implement every last detail of the
machine-readable YANG,
especially when-stmt auto-deletion. The auto-cleanup is seen as a feature.


> However, I do agree with Martin & Juergen, that the intent of the spec is
> that servers perform the 'when' auto-delete behaviour, and clients must be
> able to rely on compliant servers behaving this way.
>
>
agreed.
It is hard to argue against consistent, predicable server behavior
for datastore editing.  (NP containers and NMDA are also causing problems,
and should be fixed in yang-next if that ever happens).


Thanks,
> Rob
>
>

Andy


>
> >
> > /martin
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>