> On 16 Oct 2015, at 13:11, Martin Bjorklund <[email protected]> wrote: > > Ladislav Lhotka <[email protected]> wrote: >> >>> On 16 Oct 2015, at 12:27, Balazs Lengyel <[email protected]> >>> wrote: >>> >>> IMHO YANG should define the behavoir, and I would want it to be the >>> same on Netconf/Restconf/CLI etc. >>> I agree that " 1) you get an error back" would be the best: because it >>> is the easiest to understand for the operator, with the fewest corner >>> cases. >>> Also we must define if in the same transaction we set b=42 and >>> a=2. which of the 3 options are taken? >>> >>> >>> We should not leave such complex cases undefined, or alternatively >>> state that they are implementation dependant. >> >> I might be difficult to say what is a complex case, unless we abandon >> XPath in "when" statements and use something else - and considerably >> simpler. >> >> Here is another interesting corner case - does it qualify as being >> complex? >> >> leaf-list bar { >> type uint8; >> when "count(../*) > 1"; >> } >> leaf foo { >> type uint8; >> } >> >> Assuming no instances exist, is this edit allowed? (This was >> essentially your question.) >> >> <bar>1</bar> >> <foo>2</foo> > > Yes. > >> But what about this? >> >> <bar>1</bar> >> <bar>2</bar> > > No. > > (Note the new text that specifies that 'bar' is tentatively replaced > with a dummy node during when processing)
Yes, I know, but it is *extremely* weird. I can guarantee you that XPath experts would be upset when seeing this. Lada > > >> >> Lada >> >>> regards Balazs >>> >>> On 2015-10-16 09:43, Ladislav Lhotka wrote: >>>>> On 15 Oct 2015, at 18:03, Martin Bjorklund <[email protected]> >>>>> wrote: >>>>> >>>>> Andy Bierman >>>>> <[email protected]> >>>>> wrote: >>>>> >>>>>> On Thu, Oct 15, 2015 at 4:53 AM, Martin Bjorklund <[email protected]> >>>>>> wrote: >>>>>> >>>>>> >>>>>>> Andy Bierman <[email protected]> >>>>>>> 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 >>>>> >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/netmod >>>> >>>> >>>> >>> >>> -- >>> Balazs Lengyel Ericsson Hungary Ltd. >>> Senior Specialist >>> ECN: 831 7320 >>> Mobile: +36-70-330-7909 email: >>> [email protected] >>> >>> >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> >> _______________________________________________ >> netmod mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
