[YANGTOOLS-800] The validate rules of "min-elements" is not consistent with the RFC6020 Created: 25/Jul/17  Updated: 10/Apr/22  Resolved: 01/Aug/17

Status: Resolved
Project: yangtools
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: anzhe Assignee: Unassigned
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All

External issue ID: 8887

 Description   

I am using yangtools boron-sr4. I think the validate rules of "min-elements" is not consistent with the RFC6020.

See https://tools.ietf.org/html/rfc6020#page-63

7.7.3. The min-elements Statement

If "min-elements" exists in the leaf-list or list, and the leaf-list's or list's closest ancestor node is neither a non-presence container nor a case node. The "min-elements" constraint is enforced if the ancestor node exists.

But in fact the yang-data-impl's rule is like this:

if (constraints.isMandatory() || (minElements != null && minElements > 0)) {
final YangInstanceIdentifier childId = id.node(NodeIdentifier.create(child.getQName()));
LOG.debug("Adding mandatory child {}", childId);
builder.add(childId.toOptimized());
} }
}
It means that if "min-elements" is exist, the list or leaf-list node must exist.

Consider a yang module like this:
list layer-protocol {
container eth-cep-pac {
list vlan-spec

{ key 'vlan-id'; uses TypeDefinition:zte-vlan-spec; min-elements 1; }

leaf mac-adress-learning-range

{ type uint64; }
}
container eth-nep-pac {
leaf total-potential-eth-capacity { type uint64; }

leaf available-eth-capacity

{ type uint64; }

}
}
If I put "layer-protocol" without "eth-cep-pac" into configuration datastoreļ¼Œ IllegalArgumentException occurred " missing mandatory descendant /eth-cep-pac/vlan-spec"

 Comments   
Comment by Peter Kajsa [ 31/Jul/17 ]

My understanding is as follows:

Rfc6020 https://tools.ietf.org/html/rfc6020#section-7.7.3 says:
"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."

So the "vlan-spec" list's closest ancestor node in the schema tree that is not a non-presence container is the list "layer-protocol", because container "eth-cep-pac" is non-presence container and therefore the second point from the Rfc6020 is applied i.e. "Otherwise, it is enforced if the ancestor node exists."

Therefore if an entry of list "layer-protocol" exists, at least one entry of list "vlan-spec" should also exists, because the container "eth-cep-pac" is non-presence container.

Comment by Robert Varga [ 01/Aug/17 ]

I do believe Peter's analysis is in fact correct. If the intent is to have the constraint enforced only if eth-cep-pac is present, then eth-cep-pac needs to be a presence container.

Generated at Wed Feb 07 20:54:21 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.