Ladislav Lhotka <lho...@nic.cz> wrote: > > > 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.
See below. > > 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. Right; so the bug in 6020 is this text: The "path" substatement (Section 9.9.2) selects a set of leaf instances, and the leafref value space is the set of values of these leaf instances. This is not correct for the candidate. This text means for example that if there are no target instances in the candidate, the value space for the leafref would be empty, and it wouldn't be possible to set the leafref leaf in the candidate. Hence the proposal to fix this bug in 6020. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
