Consistent default value behavior for operations and validation

[abierman]

YANG validation (e.g., must-stmt) sometimes depends on whether a "node exists in the accessible tree". This creates a cornercase with the default-stmt

container npcon {
   leaf A { type string; }
   leaf B {
     must "../A = 'test1'";
     type int32;
     default 10;
   }
}

The issue is that every server can decide differently whether node /npcon/B is in the accessible tree. It depends on with-defaults basic-style.

Each basic-style (trim, explicit, report-all) can have a different answer. For report-all, this example would fail the must-stmt test when the module was loaded. (Although our server does not do that since it would break some real deployments)

This also affects the 'create' and 'delete' operations in protocol operations.

Solution: not clear if YANG 2.0 can mandate a single behavior or find an alternative to the 'node exists in the accessible tree' language

[abierman]

This issue also applies to NP containers. The RFC text is not clear if NP containers always cause a node to exist in the accessible tree.

For the RFC example: Would the must-stmt be evaluated as soon as the module was loaded, because container 'interface' always exists?

The XPath Context section clearly states that NP containers and leafy defaults exist in the accessible tree for XPath evaluation. This is after all the text about data nodes that actually exist.

[kwatsen]

Kent: is this a clarification stating that, for must statements, defaults are in the tree? Andy: prefer not requiring default be in the tree Rob: I think a node w/ a default value is in the tree Rob: this shouldn't depend on the report-level supported by server Andy: servers should not execute a must expression for nodes that just defaults. Balazs: 7950 section 6.4.1 says that, for XPath, all defaults are in the accessible tree, so this seems clear So the example resolves that leaf A must always be "test1" Rob: agree that defaults are in the accessible tree Balazs: different vendors have not agreement Importance high just because it's unclear (clarification needed!)