Some clarification is needed on how PR #543 applies to the following ubiquitous idiom:
leaf name {
type leafref {
path "../config/name";
}
description
"Reference to list key";
}
Is each definition of this kind going to be marked require-instance true? Or are we allowing creation of elements with different values of name and config/name?
PR seems to be aware of this use case, since it lists it first in the "Why use a leafref?" section and notes that only the third item in the list "requires additional consideration". Section "Relaxed Leafref Validation Requirements" however does not make this distinction, saying that a server "SHOULD NOT validate the existence of the leaf that is pointed to by the leafref path" unless require-instance true is specified.
This issue is stale because it has been open 180 days with no activity. If you wish to keep this issue active, please remove the stale label or add a comment, otherwise will be closed in 14 days.
Some clarification is needed on how PR #543 applies to the following ubiquitous idiom:
Is each definition of this kind going to be marked
require-instance true
? Or are we allowing creation of elements with different values ofname
andconfig/name
?PR seems to be aware of this use case, since it lists it first in the "Why use a leafref?" section and notes that only the third item in the list "requires additional consideration". Section "Relaxed Leafref Validation Requirements" however does not make this distinction, saying that a server "SHOULD NOT validate the existence of the leaf that is pointed to by the leafref path" unless
require-instance true
is specified.Cf. #773