Re: [netmod] deviation that changes config true to false: deviate add or replace?

Andy Bierman <andy@yumaworks.com> Tue, 22 March 2016 15:22 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 9678D12DA10 for <netmod@ietfa.amsl.com>; Tue, 22 Mar 2016 08:22:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 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_LOW=-0.7, SPF_PASS=-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 E_pmFWf8m8kL for <netmod@ietfa.amsl.com>; Tue, 22 Mar 2016 08:22:22 -0700 (PDT)
Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (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 F003412DA40 for <netmod@ietf.org>; Tue, 22 Mar 2016 08:22:21 -0700 (PDT)
Received: by mail-lb0-x231.google.com with SMTP id bc4so166722953lbc.2 for <netmod@ietf.org>; Tue, 22 Mar 2016 08:22:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=wbn+B8rmWqpzhQv08hnpF2LGWfRwtaLKznVgJnbPlCU=; b=Jz8286+Ja/8EzVh1Stf5rlQRuEVjAD7rXYkLXi6Hkg1smg29dgwTrHEMt3da23aeo9 +1WyorbCoKvKuS0O/Kul1M6V7ulTCYpWWCIZHrwN2D5MeHHdUd4W7lUm83wNxb205NHQ iOwoY3t/Y4Yfu5bfldiKHL6gMh9tXFoStn6hrntwXuWsk5hYs/juT8DUgMfoLLlaLU+n I9nC/Mey4XI15HkgnCtoso62hwxBrPggszR0ePRBogZCvV7Zf2j47ZDkTT2/HAwIJhTK vKhjzp9mKNJA+CJfB1n7BWKPS9F2IY3ckKa4UaSuc4tm1Jx+/5ii+eu8VGclsQd9joKp ezlQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=wbn+B8rmWqpzhQv08hnpF2LGWfRwtaLKznVgJnbPlCU=; b=VbtDgbdyN9MQsVbVfvwHZb0N49TpU51SGD8ncM5DhYRVmGVqMaGXpLneR1Gq8SnGRs 2Lk+72gycONkfQOG+93EJhGVYiwZKCwvRbisAavZPG2x/cA34I34ap/ImI5+gXjP3CUe UuGE4QaZllYZrXD110oV2lcy9kIA07sfkQe05t2aoiy4ftrbwN5KUmZIUMGaIgULhkDF 0FEO5b9EfVU4Rx2rgjh93OI4BGIicIn4AMsp/ldtCMFg8tY/mEbxS1fMPzrLK1TZsYW6 k1s7o1tlNABH6vlV2AohY+GsUeTIEyWi6uLGwlKmOtv3f+4BkWHftNMCGUxk1+RLpaHI lVnw==
X-Gm-Message-State: AD7BkJIYa1fKex5A3I1h/vMySMmEYXjxcDMAjzmxpJKXLKHIk/eYrbutpilozfr3E4Smh4pWA8mI1ymlLnf7ng==
MIME-Version: 1.0
X-Received: by 10.25.85.145 with SMTP id j139mr13470387lfb.131.1458660139630; Tue, 22 Mar 2016 08:22:19 -0700 (PDT)
Received: by 10.112.135.97 with HTTP; Tue, 22 Mar 2016 08:22:19 -0700 (PDT)
In-Reply-To: <23FD825DF7C2A6489CA3B5077FB1DC8603B47F848E@ONWVEXCHMB03.ciena.com>
References: <23FD825DF7C2A6489CA3B5077FB1DC8603B47F7F83@ONWVEXCHMB03.ciena.com> <20160317.213218.2303351254263780998.mbj@tail-f.com> <56EBC795.70209@mg-soft.si> <23FD825DF7C2A6489CA3B5077FB1DC8603B47F848E@ONWVEXCHMB03.ciena.com>
Date: Tue, 22 Mar 2016 08:22:19 -0700
Message-ID: <CABCOCHTzjmp6pgoXy__tT=jiT2T4PxqkQNBFTRKdbJ-LaeN2TA@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: "Larsson, Gustav" <glarsson@ciena.com>
Content-Type: multipart/alternative; boundary="001a11405936789429052ea4c7c7"
Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/XDY3gSEaU08phJ8Ni_CcPYwimq8>
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] deviation that changes config true to false: deviate add or replace?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 22 Mar 2016 15:22:24 -0000

On Fri, Mar 18, 2016 at 11:44 AM, Larsson, Gustav <glarsson@ciena.com>
wrote:

> Jernej Tuljak wrote:
> > Martin Bjorklund je 17.3.2016 ob 21:32 napisal:
> > > "Larsson, Gustav" <glarsson@ciena.com> wrote:
> > >     The argument "replace" replaces properties of the target node.  The
> > > >     properties to replace are identified by substatements to the
> > > >     "deviate" statement.  The properties to replace MUST exist in the
> > > >     target node.
> > > >
> > > > /x/y is config true by default even though config is not explictly
> > > > given. Section 7.19.1 of RFC 6020 is not clear about whether config
> > > > is considered to exist when defaulted.
> > > Don't you think it is clear how the config value is inherited?
> > >
> > >    If "config" is not specified, the default is the same as the parent
> > >    schema node's "config" value.  If the parent node is a "case" node,
> > >    the value is the same as the "case" node's parent "choice" node.
> > >
> > >    If the top node does not specify a "config" statement, the default
> is
> > >    "true".
> > >
> > >
> > > This text doesn't use the words "config property", this could probably
> > > be clarified.
> > >
> >
> > What needs to be clarified is the definition of "property". I always read
> > this as "substatement": "units", "default", "require-instance", "when",
> > "if-feature", "ordered-by" are all being referred to as "properties" and
> > those are not inherited. On the other hand, "mandatory" is never referred
> > to as a "property".
> >
> > Also, "refine" statement text, which is practically analogous to
> "deviation",
> > explicitly uses "statement" for refinements (config included).
>
> I agree that the definition of "property" needs to be clarified.
>
> Another way of looking at it is whether "property" refers to the
> (syntactic)
> substatement or the (semantic) value. When the config value is inherited,
> the config substatement is syntactically absent but the config value is
> semantically present. It is unclear whether the "config property" is
> considered to be (syntactically) absent or (semantically) present for the
> purposes of deviate statements.
>
> > Our implementation requires "add", if no "config" substatement is present
> > in the target node (as did early versions of pyang, if I'm not mistaken).
> >
> >Jernej
>
> That's what I was concerned about. The latest pyang (1.6) seems to take
> the opposite approach by requiring "replace".
>
>
Our code doesn't care if it is "add" or "replace".  Both will work.
Forcing 1 or the other is rather fragile.

I fail to see any value at all in making a distinction between add and
replace.
It is unclear whether it means the property (which always exists)
or the statement (in which the actual stmt placement is irrelevant in some
cases),

It is also unclear what it means wrt/ multiple deviations from different
modules changing
the same thing.  There is no order defined for applying multi-module
deviations,
so which one wins?

Gustav
>

Andy


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