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

From: "Larsson, Gustav" <[email-masked]>
Date: Thu, 17 Mar 2016 15:40:23 -0400

(Originally posted to the netconf mailing list in error. My apologies.)

Hello,

When a node defaults to config true and a deviation changes it to config false, should "deviate add" or "deviate replace" be used? Some YANG implementations allow either, some allow only "deviate replace". Perhaps some allow only "deviate add" but we have not yet seen that.

Consider these definitions:

  container x {
    leaf y {
      type string;
    }
  }

  deviation /x/y {
    deviate replace {     <--  Should this be add or replace?
      config false;
    }
  }

Section 7.18.3.2 of RFC 6020 says:

   The argument "add" adds properties to the target node.  The
   properties to add are identified by substatements to the "deviate"
   statement.  If a property can only appear once, the property MUST NOT
   exist in the target node.

   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.

If config is considered to exist, then "deviate replace" is correct. Otherwise, "deviate add" is correct. Technically, RFC 6020 allows only one or the other but not both in this case, but perhaps a robust implementation should accept both.

YANG file authors need to pick one or the other, so clear guidance would be helpful.

Thanks,
Gustav

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 17 Mar 2016 21:32:18 +0100 (CET)

"Larsson, Gustav" <[email-masked]> wrote:
> When a node defaults to config true and a deviation changes it to
> config false, should "deviate add" or "deviate replace" be used? Some
> YANG implementations allow either, some allow only "deviate
> replace". Perhaps some allow only "deviate add" but we have not yet
> seen that.
> 

All nodes in the data tree has a "config" value; if it isn't
explicitly specified it is inherited from the parent, and if the
top-level node doesn't have an explicit statement it defaults to
"true".   So in order to change this property, it should be deviated
with 'replace'.

> /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.

/martin

> 
> If config is considered to exist, then "deviate replace" is
> correct. Otherwise, "deviate add" is correct. Technically, RFC 6020
> allows only one or the other but not both in this case, but perhaps a
> robust implementation should accept both.
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Jernej Tuljak <[email-masked]>
Date: Fri, 18 Mar 2016 10:17:09 +0100

> This text doesn't use the words "config property", this could probably

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).

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

---

From: "Larsson, Gustav" <[email-masked]>
Date: Fri, 18 Mar 2016 14:44:37 -0400

Jernej Tuljak wrote:
> > > given. Section 7.19.1 of RFC 6020 is not clear about whether config 
> > > is considered to exist when defaulted.
> 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".

Gustav

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Mar 2016 08:22:19 -0700

On Fri, Mar 18, 2016 at 11:44 AM, Larsson, Gustav <[email-masked]>
wrote:

> "deviation",
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