> On 30 May 2016, at 09:43, Martin Bjorklund <m...@tail-f.com> wrote: > > Ladislav Lhotka <lho...@nic.cz> wrote: >> >>> On 27 May 2016, at 19:30, t.petch <ie...@btconnect.com> wrote: >>> >>> >>> ----- Original Message ----- >>> From: "Martin Bjorklund" <m...@tail-f.com> >>> To: <netmod@ietf.org> >>> Sent: Monday, May 23, 2016 3:10 PM >>>> >>>> This comment from the Gen-ART review deserves it's own thread. >>>> >>>> gen-art> - section 9.9 >>>> gen-art> >>>> gen-art> The leafref type is used to declare a constraint on the >>> value space >>>> gen-art> of a leaf, based on a reference to a set of leaf instances >>> in the >>>> gen-art> data tree. The "path" substatement (Section 9.9.2) >>> selects a set of >>>> gen-art> leaf instances, and the leafref value space is the set of >>> values of >>>> gen-art> these leaf instances. >>>> gen-art> >>>> gen-art> The first sentence isn't quite right. Perhaps: >>>> gen-art> >>>> gen-art> The value space of a leaf with leafref type is one of the >>> values of >>>> gen-art> a set of leaf instances in the data tree. The "path" >>> substatement >>>> gen-art> (Section 9.9.2) selects the set of leaf instances, and the >>> leafref >>>> gen-art> value space is the set of values of these leaf instances. >>>> gen-art> >>>> gen-art> - section 9.9.3 >>>> gen-art> >>>> gen-art> If "require-instance" is "true", it means that the >>> instance being >>>> gen-art> referred MUST exist for the data to be valid. This >>> constraint is >>>> gen-art> enforced according to the rules in Section 8. >>>> gen-art> >>>> gen-art> If "require-instance" is "false", it means that the >>> instance being >>>> gen-art> referred MAY exist in valid data. >>>> gen-art> >>>> [...] >>>> gen-art> Also, I think the second paragraph means that if >>> require-instance is >>>> gen-art> false, the referred-to instance need not exist. But it's not >>> clear to >>>> gen-art> me what that would mean -- if there are no instances >>> referenced by the >>>> gen-art> XPath expression, then the set of value values of the leafref >>> would be >>>> gen-art> empty and the leafref would necessarily be invalid. ... I >>> think these >>>> gen-art> paragraphs need to be expanded in some way. >>>> >>>> mbj> Right; so what we want to say is: >>>> mbj> >>>> mbj> - the value space is the same as the value space of the >>> referred >>>> mbj> leaf >>>> mbj> >>>> mbj> - there is an additional constraint if require-instance is true >>> that >>>> mbj> the referred to leaf instance must exist >>>> mbj> >>>> mbj> How about >>>> mbj> >>>> mbj> OLD: >>>> mbj> >>>> mbj> The leafref type is used to declare a constraint on the value >>> space >>>> mbj> of a leaf, based on a reference to a set of leaf instances in >>> the >>>> mbj> data tree. The "path" substatement (Section 9.9.2) selects a >>> set of >>>> mbj> leaf instances, and the leafref value space is the set of >>> values of >>>> mbj> these leaf instances. >>>> mbj> >>>> mbj> If the leaf with the leafref type represents configuration >>> data, and >>>> mbj> the "require-instance" property (Section 9.9.3) is "true", the >>> leaf >>>> mbj> it refers to MUST also represent configuration. Such a leaf >>> puts a >>>> mbj> constraint on valid data. All such nodes MUST reference >>> existing >>>> mbj> leaf instances or leafs with default values in use (see >>> Section 7.6.1 >>>> mbj> and Section 7.7.2) for the data to be valid. This constraint >>> is >>>> mbj> enforced according to the rules in Section 8. >>>> mbj> >>>> mbj> NEW: >>>> mbj> >>>> mbj> The leafref type is used to declare a constraint on the value >>> space >>>> mbj> of a leaf, based on a reference to a set of leaf instances in >>> the >>>> mbj> data tree. The "path" substatement (Section 9.9.2) is used to >>> refer >>>> mbj> to another leaf node. The leafref value space is the value >>> space of >>>> mbj> this leaf node. >>>> mbj> >>>> mbj> If the "require-instance" property is "true", there MUST exist >>> an >>>> mbj> instance, or a leaf with a default value in use (see Section >>> 7.6.1 >>>> mbj> and Section 7.7.2), of the leaf being referred to with the >>> same value >>>> mbj> as the leafref value in a valid data tree. >>>> mbj> >>>> mbj> If the leaf with the leafref type represents configuration >>> data, and >>>> mbj> the "require-instance" property (Section 9.9.3) is "true", the >>> leaf >>>> mbj> it refers to MUST also represent configuration. >>>> >>>> Does anyone have comments on this proposal? >>> >>> yes! >>> >>> I realise that the discussion is moving on, and corner cases are >>> appearing, but I think that the NEW paragraph is still a tough read. >>> I >>> rearrange the words - more or less -and get >>> >>> NEW >>> >>> The leafref type is used to declare a constraint on the value space of >>> a >>> leaf. >>> >>> The "path" substatement (Section 9.9.2) which MUST be present >>> references >>> another leaf node. The value space of this other leaf node defines a >>> set >>> of values, which may be empty (e.g. when the leaf node is not present >>> in >>> the data tree). >>> >>> If the "require-instance" property is "true", then the value of the >>> leaf >>> with the leafref type MUST exist in the set of values; the set of >>> value >>> includes leafs with have a default value in use (see Section 7.6.1 and >>> Section 7.7.2) >> >> I think this not correct. > > I agree. Tom, note that the proposal has gone through a couple of > iterations already. The latest proposal is in > https://mailarchive.ietf.org/arch/msg/netmod/V3-S4enTYpWM24Ws5DWYpEKIq3I > > >> Unlike RFC 6020, the "path" argument is now >> used for two different purposes: >> >> 1. It is evaluated as an XPath expression against an instance document >> (datastore), which results in a node set. If "require-instance" is >> true, then at least one node in that node set must have the same value >> as the leaf with leafref type. This is the original 6020 meaning. > > Maybe. 6020 also says: > > If the leaf with the leafref type represents configuration data, the > leaf it refers to MUST also represent configuration. Such a leaf > puts a constraint on valid data. All leafref nodes MUST reference > existing leaf instances or leafs with default values in use (see > Section 7.6.1) for the data to be valid. This constraint is enforced > according to the rules in Section 8. > > which indicates that the intention is that the constraint is *only* > enforced in "valid data". > > I think that this is a bug in 6020.
Hmm, I agree the second sentence in the original formulation was unclear, but I've always thought it meant simply "Such a leaf introduces a semantic constraint", and that's also how it is handled in DSDL (see sec. 12.10 in RFC 6110). Note that the phrase "put/declare a constraint on valid data" is used in other places in 6020bis. If the meaning is different from the above, then I am confused. > > I'm pretty sure that no implementation has implemented this the way it > is described. Specifically, I think that implementations that support > the candidate datastore allows "non-existing" leafrefs in the > candidate. Isn't it what sec. 8.3.3 in RFC 6020 prescribes? If the datastore is <candidate/>, the constraint enforcement is delayed until a <commit> or <validate> operation. Lada > > > /martin > >> 2. It also implicitly refers to a leaf node in the schema, and the >> *type* of this other leaf node determines the type and set of valid >> values for the leaf with learef type. This is independent of the >> "require-instance" value and any datastore content. However, any >> semantic constraints that may apply to the other leaf (such as "must" >> statements) are not taken into account. >> >> Lada >> >>> >>> If the leaf with the leafref type represents configuration data, and >>> the "require-instance" property (Section 9.9.3) is "true", then the >>> target of the "path" substatement MUST also represent configuration >>> data. >>> >>> Tom Petch >>> >>>> /martin >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
