Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

clarify "require-instance" property for leafrefs #67

Closed
abierman opened this issue Mar 9, 2019 · 2 comments
Closed

clarify "require-instance" property for leafrefs #67

abierman opened this issue Mar 9, 2019 · 2 comments

Comments

@abierman
Copy link

abierman commented Mar 9, 2019

There are some issues with "require-instance" processing for leafrefs
It is clear that this property is enforced in a valid data tree [9.9, para 2]

  • path statement validation [9.9.2, para 4]

The "path" expression evaluates to a node set consisting of zero,
one, or more nodes. If the "require-instance" property is "true",
this node set MUST be non-empty.

Should be clear that "the node set" refers to conceptual evaluation of the path-expr
using an instance of the object defined in this data-def-stmt

When is the node-set evaluated? Also only in a valid data tree, but not stated

There is an example [9.12.4] that warns not to delete a pointed-at leaf in use
but no example of the error that would be returned

  • Error handling for deletion of pointed-at leaf [15.5]

15.5. Error Message for Data That Violates a "require-instance" Statement
If a NETCONF operation would result in configuration data where a
leaf of type "instance-identifier" or "leafref" marked with
require-instance "true" refers to an instance that does not exist,
the following error MUST be returned:
error-tag: data-missing
error-app-tag: instance-required
error-path: Path to the instance-identifier or leafref leaf.

This error handling is clear for create and modify operations on the leafref leaf,
but not clear for modify and delete operations on the pointed-at leaf.

Consider the example in 9.12.4.

Assume a delete edit-config operation on the "filter" entry.
If this is done on candidate then the delete is allowed.
During a validate or commit operation, the error reporting in [15.5] is followed.
The error-path should be /outbound-filter

What is the error handling for target = running?
In this case the delete operation is not allowed since edits on running must be valid immediately.
Is the same error-reporting followed as in candidate, or is an "in-use" error-tag used
and the error-path set to /filter/name

@mbj4668
Copy link

mbj4668 commented Mar 11, 2019

There are some issues with "require-instance" processing for leafrefs
It is clear that this property is enforced in a valid data tree [9.9, para 2]

* path statement validation [9.9.2, para 4]

The "path" expression evaluates to a node set consisting of zero,
one, or more nodes. If the "require-instance" property is "true",
this node set MUST be non-empty.

Should be clear that "the node set" refers to conceptual evaluation of the path-expr
using an instance of the object defined in this data-def-stmt

When is the node-set evaluated? Also only in a valid data tree, but not stated

The intention is that section 8.3.3 covers this. If it is unlcear then we should clarify.

There is an example [9.12.4] that warns not to delete a pointed-at leaf in use
but no example of the error that would be returned

* Error handling for deletion of pointed-at leaf [15.5]

15.5. Error Message for Data That Violates a "require-instance" Statement
If a NETCONF operation would result in configuration data where a
leaf of type "instance-identifier" or "leafref" marked with
require-instance "true" refers to an instance that does not exist,
the following error MUST be returned:
error-tag: data-missing
error-app-tag: instance-required
error-path: Path to the instance-identifier or leafref leaf.

This error handling is clear for create and modify operations on the leafref leaf,
but not clear for modify and delete operations on the pointed-at leaf.

This text says "a NETCONF operation would result in..." which is intended to capture also the delete case.

Consider the example in 9.12.4.

Assume a delete edit-config operation on the "filter" entry.
If this is done on candidate then the delete is allowed.
During a validate or commit operation, the error reporting in [15.5] is followed.
The error-path should be /outbound-filter

Yes.

What is the error handling for target = running?
In this case the delete operation is not allowed since edits on running must be valid immediately.
Is the same error-reporting followed as in candidate

Yes, since 15.5 applies.

@abierman
Copy link
Author

OK -- closing this issue since no changes required

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants