On Thu, 2018-12-13 at 11:24 +0100, Martin Bjorklund wrote: > Ladislav Lhotka <[email protected]> wrote: > > On Thu, 2018-12-13 at 09:51 +0100, Martin Bjorklund wrote: > > > Ladislav Lhotka <[email protected]> wrote: > > > > On Wed, 2018-12-12 at 15:23 +0000, Robert Wilton wrote: > > > > > Hi Lada, > > > > > I basically agree with Jan's suggestion. > > > > > I don't think that I would use a when statement for this scenario > since > > > you > > > > > want a leaf to report the operational value that is in effect, and one > of > > > the > > > > > aims of NMDA is to try and get the configured and operational value > onto > > > the > > > > > same path wherever possible. > > > > > But, I think that the question about validity of must statements is > more > > > > > interesting. RFC 8342 states that these can be violated in > operational, > > > but > > > > > the intention is that the constraints in <operational> should > generally > > > apply > > > > > (but never be actually checked by the server). In this case, it might > be > > > > > useful to be able to annotate a must statement to indicate that it > only > > > > > applies to configuration data and not operational data. > > > > > > > > Another option could be that "must" constraints on config data do not > apply > > > in > > > > <operational>, whereas constraints on "config false" data serve as > binding > > > > guidelines for implementors. > > > > > > Not sure what "binding guideline" means, but note that RFC 8342 says > > > for <operational>: > > > > > > <operational> SHOULD conform to any constraints specified in the data > > > model, but given the principal aim of returning "in use" values, it > > > is possible that constraints MAY be violated [...] > > > > According to the definition of SHOULD and MAY in RFC 2119, this sentence > > contradicts itself. > > It should probably have been "may" then...?
With a sound definition of syntactic and semantic constraints, we could state that data in <operational> - MUST satisfy syntactic constraints - SHOULD satisfy semantic constraints that apply to config=false data (semantic constraints on config=true data are checked before the data get into <running>) > > > > Only semantic constraints MAY be violated. These are the YANG > > > "when", "must", "mandatory", "unique", "min-elements", and > > > "max-elements" statements; and the uniqueness of key values. > > > > It is nice to see "when" listed among semantic constraints. > > Yeah, I was a bit surprised that this sentence classifies "when" as a > semantic constraint... Every truth will eventually be revealed. :-) > > > Note, however, that > > in sec. 8.1 of RFC 7950, "when" ended up among the constraints that > > are true in > > all data trees (despite my hefty protests in the past). > > Note that also uniqueness of keys is listed in 8.1 as true all data > trees, but relaxed by 8342. Well, section 8.1 only says this about keys: o All key leafs MUST be present for all list entries. Their uniqueness is not mentioned (an omission?). Anyway, it is IMO a typical semantic constraint that shouldn't be enforced in <candidate>, but due to the limitations of the NETCONF protocol it has to be. Lada > > > /martin -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
