clarify NP-containers - Githubissues

netmod-wg / yang-next

Feature requests for future versions of YANG

6 stars 0 forks source link

clarify NP-containers #88

Open kwatsen opened 5 years ago

kwatsen commented 5 years ago

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 commented 5 years ago

+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 commented 5 years ago

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

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

llhotka commented 5 years ago

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 commented 5 years ago

Here is another thread related to this issue

rgwilton commented 5 years ago

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 commented 4 years ago

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 commented 4 years ago

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

kwatsen commented 4 years ago

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

kwatsen commented 8 months ago

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.";

abierman commented 2 weeks ago

NP containers have caused a lot of confusion and support tickets.

Maybe the protocol documents need to be clarified how NP containers work, not YANG.

Must do: complexity: medium, bc: medium, importance: high