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)


> 
> 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
> 

_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to