Subject: [netmod] NP-container and min-elements

From: Andy Bierman <[email-masked]>
Date: Thu, 26 May 2016 06:14:46 -0700

Hi,

Our compiler generates a "top-level mandatory" warning for something
like this:

   container top {
     list foo {
        min-elements 1;
        ...
      }
   }

A customer is saying this is incorrect.  RFC6020bis is confusing on this
issue.

Terms::

   o  mandatory node: A mandatory node is one of:

      *  A leaf, choice, anydata, or anyxml node with a "mandatory"
         statement with the value "true".

      *  A list or leaf-list node with a "min-elements" statement with a
         value greater than zero.

      *  A container node without a "presence" statement, which has at
         least one mandatory node as a child.

7.7.5.  The min-elements Statement

   The "min-elements" statement, which is optional, takes as an argument
   a non-negative integer that puts a constraint on valid list entries.
   A valid leaf-list or list MUST have at least min-elements entries.

   If no "min-elements" statement is present, it defaults to zero.

 *  The behavior of the constraint depends on the type of the leaf-list's
   or list's closest ancestor node in the schema tree that is not a non-
   presence-container (see Section 7.5.1):
*
   o  If this ancestor is a case node, the constraint is enforced if any
      other node from the case exists.

   o  Otherwise, it is enforced if the ancestor node exists.

8.1:

  o  The "mandatory" constraint is enforced for leafs and choices,
      unless the node or any of its ancestors has a "when" condition or
      "if-feature" expression that evaluates to "false".

   o  The "min-elements" and "max-elements" constraints are enforced for
      lists and leaf-lists, unless the node or any of its ancestors has
      a "when" condition or "if-feature" expression that evaluates to
      "false".

In this example, there is no ancestor node (except docroot) that is not an
NP-container. The "mandatory" term and sec. 7.7.5 implies that the
warning is correct. Sec. 8.1 implies the ancestor data node has to exist for
min-elements to be enforced. Is the docroot the ancestor node in this
example?

The transparent nature of NP-containers has always confused people.
It is not that obvious that they are so very different than all other node
types.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 26 May 2016 15:26:46 +0200 (CEST)

>          least one mandatory node as a child.

With this definition, I think it is clear that 'top' is a "mandatory
node".  What is confusing about this?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 26 May 2016 06:29:35 -0700

> node".  What is confusing about this?
This is clear but 7.7.5 is not clear that the docroot is an ancestor data
node.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 26 May 2016 15:44:06 +0200

> On 26 May 2016, at 15:29, Andy Bierman <[email-masked]> wrote:
> 
> 
> 
> This is clear but 7.7.5 is not clear that the docroot is an ancestor data node.

But in your example the ancestor is the "top" container, and it is a mandatory top-level node.

Lada 

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

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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 26 May 2016 06:49:24 -0700

> mandatory top-level node.

  The behavior of the constraint depends on the type of the leaf-list's
   or list's closest ancestor node in the schema tree *that is not a non-*
*   presence-container *(see Section 7.5.1):

The min-elements text seems to indicate that the NP container is skipped
when checking if min-elements is enforced or not.

Lada

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 26 May 2016 15:51:34 +0200 (CEST)

Andy Bierman <[email-masked]> wrote:
> This is clear

Ok.

> but 7.7.5 is not clear that the docroot is an ancestor data
> node.

You're right.  There is similar text in 7.6.1, 7.6.5, 7.7.2, 7.7.5,
7.9.4.  Of these, 7.7.5 and 7.9.4 doesn't handle the "docroot" case.

So I suggest we align these sections.  Specifically:

OLD in 7.7.5 and 7.9.4:

NEW in 7.7.5 and 7.9.4:

   o  If no such ancestor exists in the schema tree, the constraint is
      enforced.

   o  Otherwise, if this ancestor is a case node, the constraint is
      enforced if any other node from the case exists.

Do you think this addresses the issue?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 26 May 2016 07:02:28 -0700

> Do you think this addresses the issue?

yes

> > > > In this example, there is no ancestor node (except docroot) that is
> not
> > > an
> > > > warning is correct. Sec. 8.1 implies the ancestor data node has to
> exist
> > > for

---

From: Andy Bierman <[email-masked]>
Date: Thu, 26 May 2016 07:36:12 -0700

Hi,

I ran a test on a module with these 2 statements:

  container top {
    list mand-list {
      key name;
      min-elements 1;
      leaf name { type string; }
      leaf-list vlan-id { type uint32; }
    }
  }

  choice top-ch {
    default A;
    case A {
      list mand-list {
        key name;
        min-elements 1;
        leaf name { type string; }
        leaf-list vlan-id { type uint32; }
      }
    }
  }

yangdump-pro gives a warning about container top is mandatory, but pyang is
silent.
Both compilers give an error about the mandatory node in a default case.

IMO YANG is inconsistent here. Both constructs result in exactly the same
mandatory list,
but 1 is an error and the other is not.

Andy