[YANGTOOLS-608] Mandatory leaf enforcement is not correct with presence container Created: 02/May/16  Updated: 10/Apr/22  Resolved: 07/Jun/16

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

Type: Bug
Reporter: Tom Pantelis Assignee: Peter Kajsa
Resolution: Done 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: 5830
Priority: Normal

 Description   

Given the following schema:

container task-container {
list task {
key "task-id";

leaf task-id

{ type string; }

container task-data {
presence "Task data";
leaf mandatory-data

{ type string; mandatory true; }

leaf other-data

{ type string; }

}
}
}

If one PUTs:

task:

{ task-id: "123" }

it succeeds as expected without specifying the mandatory descendant leaf "mandatory-data" because its immediate ancestor, "task-data", is a presence container and it wasn't specified. This conforms to https://tools.ietf.org/html/rfc6020#section-7.6.5 (the 3rd constraint bullet below):

If "mandatory" is "true", the behavior of the constraint depends on
the type of the leaf's closest ancestor node in the schema tree that
is not a non-presence container (see Section 7.5.1):

o If no such ancestor exists in the schema tree, the leaf MUST
exist.

o Otherwise, if this ancestor is a case node, the leaf MUST exist if
any node from the case exists in the data tree.

o Otherwise, the leaf MUST exist if the ancestor node exists in the
data tree.

Therefore "mandatory-data" doesn't need to exist b/c "task-data" doesn't exist.

If one PUTs:

task: {
task-id: "123",
task-data:

{ other-data: "foo" }

}

it also succeeds. However, in this case, "task-data" is present so this seems to violate the 3rd constraint above, i.e. it should've failed b/c "mandatory-data" was not specified.

 Comments   
Comment by Tom Pantelis [ 03/May/16 ]

I found another case which looks like a bug. If container "task-data" in the schema above is not a presence container the writing:

task: {
task-id: "123",
task-data:

{ other-data: "foo" }

}

fails as expected b/c "mandatory-data" was not specified.

However if the "task" list is removed from the schema, i.e.:

container task-container {
leaf task-id

{ type string; }

container task-data {
leaf mandatory-data

{ type string; mandatory true; }

leaf other-data

{ type string; }

}
}

writing:

task-container: {
task-id: "123",
task-data:

{ other-data: "foo" }

}

succeeds. This also seems to violate the RFC. Mandatory leafs are only enforced when descendants of a list.

Comment by Tom Pantelis [ 03/May/16 ]

Another inconsistency. Given the original schema with the "task" list but "task-data" non-presence, writing

task-container: {
task: {
task-id: "123",
task-data:

{ other-data: "foo" }

}
}

succeeds but it should fail.

Comment by Robert Varga [ 03/May/16 ]

The two later cases are expected, as mandatory leaf enforcement is not performing validation based on RFC6020 Section 7.6.5 bullet 1, as that would require all mandatory leaves to be introduced in the first transaction that occurs – any other transactions would fail.

We do not have a mechanism which could reliably satisfy that requirement.

Comment by Colin Dixon [ 03/May/16 ]

Should we open an enhancement bug to allow people to voluntarily enable mandatory enforcement per the RFC 6020 on some basis. For example, could somebody turn it on a per-module basis sometime after boot?

Comment by Colin Dixon [ 03/May/16 ]

During the MD-SAL call today, we confirmed that at least the first part here is a real bug. That is if a presence container exists, its mandatory child leaves must also exist.

Comment by Peter Kajsa [ 25/May/16 ]

(In reply to Colin Dixon from comment #5)
> During the MD-SAL call today, we confirmed that at least the first part here
> is a real bug. That is if a presence container exists, its mandatory child
> leaves must also exist.

fix: https://git.opendaylight.org/gerrit/#/c/39313/

Comment by Robert Varga [ 07/Jun/16 ]

Be: https://git.opendaylight.org/gerrit/39942

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