clarify NP-containers

[kwatsen]

Searching the NETCONF list archives for the word "non-presense" found the following:

• 2019-06-21: restconf 'get' on non-presence container
• 2018-06-28: Existence of Non-Presence Containers
• 2016-07-11: What should a server response be? (70+ responses in 30 days!)

[rgwilton]

+1 on clarifying the behavior of NP-containers, although some of this clarification might need to be in future protocol drafts rather than the base YANG spec.

[michalvasko]

Another ambiguity regarding NP-containers in the NETMOD mailing list:

• 2019-06-25: mandatory choice with non-presence container case

[llhotka]

One option that may be worth considering is to get rid of the distinction between P and NP altogether, with these two additional rules:

• the server shall not delete client-created containers on its own
• must constraints on a container become effective only after the container instance is created

[llhotka]

Here is another thread related to this issue

[rgwilton]

Personally I think that the distinction is useful and makes sense. But I think that the YANG and protocol specifications should put more constraints on how the servers are expected to behave.

However, I do find the XPath context definition confusing/inconsistent with the np-containers not really existing:

   If a node that exists in the accessible tree has a non-presence
   container as a child, then the non-presence container also exists in
   the accessible tree.

[rovarga]

I think current lifecycle (as implied by RFC7950) is very much consistent and I do not believe it should be changed. They are extremely useful for pruning data tree parts which have no semantic meaning, as well as anchoring enforcement points for things like MUST constraints.

I believe access protocols (i.e. NETCONF/RESTCONF) should instead be clarified to explicitly define lifecycle rules for NP containers.

[kwatsen]

Related, the list and leaf-list nodes are similarly unclear as to if they exist when empty.

[kwatsen]

Somewhat related,list and leaf-list are also unclear as to if the list exists when empty.

[kwatsen]

Regarding Lada's "must constraints on a container become effective only after the container instance is created", this is root issue for why I add presence statements in models with mandatory descendents like this:

        presence
          "Blah, blah, blah. 
           This statement is present so the mandatory descendant
           nodes do not imply that this node must be configured.";