> On 15 Oct 2015, at 18:03, Martin Bjorklund <m...@tail-f.com> wrote: > > Andy Bierman <a...@yumaworks.com> wrote: >> On Thu, Oct 15, 2015 at 4:53 AM, Martin Bjorklund <m...@tail-f.com> wrote: >> >>> Andy Bierman <a...@yumaworks.com> wrote: >>>> Hi, >>>> >>>> You are incorrect. >>>> >>>> Within the PAYLOAD (as this section describes), there is no when-stmt >>>> for data nodes within the datastore. Look at the YANG for edit-config. >>>> There are no when-stmts for "interface" in "edit-config". >>> >>> Andy, there is some confusion here. The section talks about: >>> >>> For configuration data, there are three windows when constraints >>> MUST be enforced: >>> >>> - during parsing of RPC payloads >>> - during processing of NETCONF operations >>> - during validation >>> >>> So the entire section talks about constraints *on configuration data*. >>> >>> >> >> http://www.netconfcentral.org/modules/ietf-netconf/2011-06-01#edit-config.421 >> >> >> Here is the YANG for edit-config? >> Please point out the when-stmts in this rpc-stmt >> specific to the "interface" node. >> I just see an "anyxml" that has no when-stmts at all. >> >> So enforcing the when constraint on the RPC PAYLOAD >> clearly has nothing to do with "interface" -- just the parameters >> specified in the rpc-stmt. > > Ok, you're right. 8.2.1 should be kept as it is. (we may need to > rephrase the intro text in 8.2) But I think Balazs is also right. > Suppose you have: > > leaf a { > when "../b = 42"; > type int32; > } > leaf b { > type int32; > } > > and the db contains b=10. > > Suppose I send an edit-config with a=2. What is the result? > > 1) you get an error back > 2) you get ok; the request to set a to 2 is silently dropped > 3) something else
IMO YANG spec shouldn't deal with this kind of things in the first place. It should be sufficient to define two validation levels, e.g. syntactic (schema) and semantic validity. Stating what a protocol does if either of these validity types is violated would then be up to the protocol spec, and different protocols may use different approaches. That said, I like #1 best. Lada > > > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
