Subject: Re: [netmod] yang-02, 7.5.2

From: Martin Bjorklund <[email-masked]>
Date: Sun, 04 Jan 2009 12:27:04 +0100 (CET)

Andy Bierman <[email-masked]> wrote:
> Hi,
> 
> Are all these discussions about must-stmt inside rpc or
> notification academic?
> 
>  From 7.5.2, para 4:
> 
>     The "must" statement is ignored if the data does not represent
>     configuration.
> 
> Para 7:
> 
>     If the node with the must statement represents configuration data,
>     any node referenced in the XPath expression MUST also represent
>     configuration.
> 
> These statements seem to conflict.

I have removed para 4 in -03.

> It's fine with me if we leave must-stmt processing out
> of RPC and notification completely.  It will make the
> document easier to read and write (and get done).

The current consensus (see
http://trac.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang#issue-00172)
is to allow this.

> BTW, para 7 is not quite complete -- 'any node referenced'
> could be via 1 of the wildcard mechanisms, and not just
> an explicit path statement like the examples we often use.
> Each path statement result is a node-set, not just 1 node.
> Ditto for each path step.
> 
> So we need a sentence that says that non-config nodes
> matched by [fill in the wildcard mechanisms], instead
> of by direct reference, are ignored during must-stmt
> validation and evaluation.
> 
> Or are wildcard matches considered an error also?

Actually, I think this should be reworded.  Referencing a non-config
node from a config node should be treated in the same way as
referencing a non-existing node.  And treating a non-existing node is
not an error, but that expression will return an empty node set.

It's probably a good idea if YANG tools produces warnings in these
cases though, but that's an implementation issue.

/martin
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Sun, 04 Jan 2009 07:55:33 -0800

> not an error, but that expression will return an empty node set.

There is a difference between these conditions.
If the user says "must '/x:foo';", and there is no x:foo
node, then the result will always be empty.
Some expressions like "/.." are invalid.

We don't have any use cases for must/when statements
that include a constant expression that equals the
empty set.  It is not always easy to tell (//../*/../foo),
but if the compiler can flag a non-existent prefix or node,
then that is a fatal error, because the XPath
expression will always be false.

In my implementation, I am silently skipping non-config
nodes that match via wildcard (if the context node is config)
and only generating an error if I can tell it was explicitly
selected.

> cases though, but that's an implementation issue.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sun, 04 Jan 2009 08:48:09 -0800

> Andy Bierman <[email-masked]> wrote:
...
> cases though, but that's an implementation issue.

After some more thought -- this will be fine.
It can be too difficult to know the intent of
the DM designer when encountering an unknown node
in a sub-expression.

    must "/x:new-goo-feature or /y:old-foo-feature";

What about if the entire expression always evaluates to false?
Also a warning I guess. Even must-stmt?  An empty nodeset
is just one way to reach this result.

Phil says nobody pays attention to warnings,
but this is the "<commit> operation will always fail" warning,
so you can ignore it, but it won't ignore you ;-)

Andy