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

> Jernej Tuljak wrote:
> > Martin Bjorklund je 17.3.2016 ob 21:32 napisal:
> > > "Larsson, Gustav" <glars...@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
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to