Subject: [netmod] YANG 1.1 Clarification: must-stmt within an NP-container

From: Andy Bierman <[email-masked]>
Date: Mon, 9 Jun 2014 18:37:35 -0700

Hi,

Consider this YANG snippet:

   container np-con {
      must "/some-node-test";   // must1
      leaf def42 {
        must "/some-other-node-test";   // must2
        type int32;
        default 42;
     }
   }

  leaf X {
     must "/np-con";  // must3
     type string;
     default foo;
  }

  leaf Y {
     must "/np-con/def42";  // must4
     type string;
     default bar;
  }

Sec. 7.5.8 says that an empty NP-container MAY be removed by the server.

   If a container does not have a "presence" statement and the last
   child node is deleted, the NETCONF server MAY delete the container.

Additional text in 7.5.3. para 2:

   When a datastore is validated, all "must" constraints are
   conceptually evaluated once for each data node in the data tree, and
   for all leafs with default values in use (see Section 7.6.1).  If a
   data node does not exist in the data tree, and it does not have a
   default value, its "must" statements are not evaluated.

Problems:

  * This MAY statement in 7.5.8 means that a client does not know if the
server
    will evaluate "must1" if all child nodes are removed from /np-con.

 * The RFC is not clear about server-created NP containers. Are they
allowed?
    When is 'must1' evaluated on all servers?

 * The RFC does not account for the conceptual existence of default
    NP containers.  Clearly, 'must2' needs to be evaluated.  In order for
    the node /np-con/def42 to exist for XPath purposes, the parent node
    /np-con must also exist for XPath purposes

 * This node existence ambiguity can ripple to other nodes. The 'must'3'
    and 'must4' evaluations need to be done.  The rules are inconsistent.
    Evaluation of 'must4' is clearly defined but 'must3' is not.

Solution:
  * Define consistent behavior rules for NP-containers wrt/ default and
    related must/when expression evaluation

Andy

---

From: "Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)" <[email-masked]>
Date: Tue, 10 Jun 2014 14:39:40 +0000

Yes, we need this clarification, and it looks like it addresses the core problem described in Y38.

Some further thoughts on the solution:

It looks like banning the use of "must" in an NP container would fail the backwards-compatibility test. So the two alternative clarifications I can think of are:
  1. Only evaluate the "must" statement in an NP container if a node (not an NP container) is instantiated in the data tree within the subtree encapsulated by the NP container.
  2. Always evaluate the "must" statement in an NP container if its nearest non-NP-container ancestor exists (similarly defined to the rules for evaluating the "mandatory" statement in RFC6020 7.6.5 and "default" in 7.6.1).

It would be reasonable for existing implementations to be using either option 1 or option 2. 

If the rules are being tightened one way or the other, option 2 would have the following advantages:
  * It is more consistent with the "leaf with default" example Andy has given below.
  * It has better implications for the conformance of existing implementations:
    - If the clarification specifies that option 1 is the right behavior, then an existing implementation based on option 2 would reject some operations that are valid.
    - If the clarification specifies that option 2 is the right behavior, then an existing implementation based on option 1 would accept some operations that are invalid (and this is presumably the lesser evil?).
  * It seems more in line with the description of NP containers in 7.5.1, that they "exist only for organizing the hierarchy of data nodes ... the container has no meaning of its own, existing only to contain child nodes."

Cheers,
Peyman

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: 10 June 2014 02:38
To: [email-masked]
Subject: [netmod] YANG 1.1 Clarification: must-stmt within an NP-container

Hi,

   container np-con {

  leaf X {
     must "/np-con";  // must3
     type string;
     default foo;
  }

  leaf Y {

Problems:
  * This MAY statement in 7.5.8 means that a client does not know if the server
    will evaluate "must1" if all child nodes are removed from /np-con.

 * The RFC is not clear about server-created NP containers. Are they allowed?
    When is 'must1' evaluated on all servers?

Solution:

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 10 Jun 2014 08:00:04 -0700

On Tue, Jun 10, 2014 at 7:39 AM, Peyman Owladi -X (powladi - Ensoft Ltd at
Cisco) <[email-masked]> wrote:

> It looks like banning the use of "must" in an NP container would fail the
> backwards-compatibility test. So the two alternative clarifications I can
> think of are:
>   1. Only evaluate the "must" statement in an NP container if a node (not
> an NP container) is instantiated in the data tree within the subtree
> encapsulated by the NP container.
>   2. Always evaluate the "must" statement in an NP container if its
> nearest non-NP-container ancestor exists (similarly defined to the rules
> for evaluating the "mandatory" statement in RFC6020 7.6.5 and "default" in
> 7.6.1).
>
>     - If the clarification specifies that option 1 is the right behavior,
> then an existing implementation based on option 2 would reject some
> operations that are valid.
>     - If the clarification specifies that option 2 is the right behavior,
> then an existing implementation based on option 1 would accept some
> operations that are invalid (and this is presumably the lesser evil?).
>   * It seems more in line with the description of NP containers in 7.5.1,
> that they "exist only for organizing the hierarchy of data nodes ... the
> container has no meaning of its own, existing only to contain child nodes."
>
>
I could support option 2.
That would change the "MAY delete" NP-containers to "MUST NOT delete"
and "MUST create".

Is that a backward-compatible change?  It does not cause a YANG 1.0
module to be invalid but changes normative server behavior.

Andy

---

From: "Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)" <[email-masked]>
Date: Tue, 10 Jun 2014 16:55:52 +0000

From: Andy Bierman [mailto:[email-masked]]
Sent: 10 June 2014 16:00
To: Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)
Cc: [email-masked]
Subject: Re: [netmod] YANG 1.1 Clarification: must-stmt within an NP-container

On Tue, Jun 10, 2014 at 7:39 AM, Peyman Owladi -X (powladi - Ensoft Ltd at Cisco) <[email-masked]<mailto:[email-masked]>> wrote:
Yes, we need this clarification, and it looks like it addresses the core problem described in Y38.

It seems to me that this can simply be a recommendation for server behavior that helps to define the expected externally-observed behavior for evaluating "must" constraints. (Perhaps this should also apply to the behavior of "default" and "mandatory" leaves, to simplify the language in 7.6.1 and 7.6.5.)

A server implementation could choose not to actually instantiate the NP containers, but to evaluate the "must" constraints in the cases in the cases where they are described as being logically instantiated. (In other words, I think what's being described is just the "conceptual" existence  of NP-containers for these evaluations/behaviors.)

An alternative approach would be to avoid updating the statement about existence of NP-containers at all, and instead update the datastore validation statement in 7.5.3 to bring it in line with 7.6.1 and 7.6.5; e.g. replace the second paragraph of 7.5.3 with:

When a datastore is validated, all "must" constraints are
conceptually evaluated once for each data node in the data tree,
and for all leafs with default values in use (see Section 7.6.1).
For "must" constraints in non-presence containers (see Section
7.5.1), the evaluation depends on each instance of its closest
ancestor node in the schema tree that is not a non-presence
container:

   o  If no such ancestor exists in the schema tree, the "must"
      constraint is evaluated.

   o  Otherwise, if this ancestor is a case node, the "must"
      constraint is evaluated if any node from the case exists
      in the data tree.

   o  Otherwise, the leaf "must" constraint is evaluated if the
      ancestor node in the data tree.

For any other data node, its "must" statements are not evaluated.

Cheers,
Peyman

Andy

Cheers,
Peyman

-----Original Message-----
From: netmod [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Andy Bierman
Sent: 10 June 2014 02:38
To: [email-masked]<mailto:[email-masked]>
Subject: [netmod] YANG 1.1 Clarification: must-stmt within an NP-container

Hi,

   container np-con {

  leaf X {
     must "/np-con";  // must3
     type string;
     default foo;
  }

  leaf Y {

Problems:

Solution:

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 11 Jun 2014 14:46:06 +0200 (CEST)

Hi,

First of all, I think is issue is covered by Y41.  I will update the
issues list with a reference to this ML thread.

(I don't know which mail client you are using, but the citation got
messed up...)

"Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)" <[email-masked]> wrote:
> On Tue, Jun 10, 2014 at 7:39 AM, Peyman Owladi -X (powladi - Ensoft
> Ltd at Cisco) <[email-masked]<mailto:[email-masked]>> wrote:
> It looks like banning the use of "must" in an NP container would fail
> the backwards-compatibility test. So the two alternative
> clarifications I can think of are:
>   1. Only evaluate the "must" statement in an NP container if a node
>   (not an NP container) is instantiated in the data tree within the
>   subtree encapsulated by the NP container.
>   nearest non-NP-container ancestor exists (similarly defined to the
>   rules for evaluating the "mandatory" statement in RFC6020 7.6.5 and
>   "default" in 7.6.1).
> 
>   * It is more consistent with the "leaf with default" example Andy has
>   * given below.
>   * It has better implications for the conformance of existing
>   * implementations:
>     - then an existing implementation based on option 2 would reject some
>     - operations that are valid.
>     - then an existing implementation based on option 1 would accept some
>     - operations that are invalid (and this is presumably the lesser evil?).
>   * that they "exist only for organizing the hierarchy of data nodes
>   * ... the container has no meaning of its own, existing only to contain
>   * child nodes."
> 

+1

> It seems to me that this can simply be a recommendation for server
> behavior that helps to define the expected externally-observed
> behavior for evaluating "must" constraints. (Perhaps this should also
> apply to the behavior of "default" and "mandatory" leaves, to simplify
> the language in 7.6.1 and 7.6.5.)
> 
> A server implementation could choose not to actually instantiate the
> NP containers, but to evaluate the "must" constraints in the cases in
> the cases where they are described as being logically
> instantiated. (In other words, I think what's being described is just
> the "conceptual" existence of NP-containers for these
> evaluations/behaviors.)
> 
> An alternative approach would be to avoid updating the statement about
> existence of NP-containers at all, and instead update the datastore
> validation statement in 7.5.3 to bring it in line with 7.6.1 and
> 7.6.5; e.g. replace the second paragraph of 7.5.3 with:
> 

I like this approach.  It doesn't handle Andy's original "must3", but
I am not sure the behavior in that case needs to be well-defined.
These kinds of expressions should be avoided.

/martin

> From: netmod
> [mailto:[email-masked]<mailto:[email-masked]>] On
> Behalf Of Andy Bierman
> Sent: 10 June 2014 02:38
>   * server
>  * allowed?

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 11 Jun 2014 14:55:49 +0200

> First of all, I think is issue is covered by Y41.  I will update the

Yes, and see also this thread:

http://www.ietf.org/mail-archive/web/netmod/current/msg09641.html

Lada

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

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C