On Sun, Oct 18, 2015 at 02:21:22PM +0200, Martin Bjorklund wrote:
> Juergen Schoenwaelder <[email protected]> wrote:
> > On Thu, Oct 15, 2015 at 06:03:57PM +0200, Martin Bjorklund wrote:
> > >
> > > 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
> > >
> >
> > Isn't the simplest to always make the changes that were requested in
> > the rpc/action (e.g. edit-config) and then to validate the result and
> > if it fails to validate to return an error? No magic addition or
> > removal of nodes while trying to guess what the client wanted to
> > achieve.
>
> Note that "when" is like a generalized "choice". If nodes for one
> case is present, and you want another case to be set, you just have to
> create the new nodes. The server deletes the nodes from the old case
> for you. In the same way, the server deletes nodes from "when"
> statements that become false.
>
> The "must" statement behaves the way you describe above.
Not sure this automatic deletion of nodes was a smart idea since this
leads to the confusion of what the server does with certain edits. I
am not sure the savings this brings (you do not have to delete the old
stuff) are worth the trouble. Are clients really relying on this
automatic deletion of nodes?
/js
PS: These are really specific protocol aspects that ideally would be
in some other document (but its difficult to refactor things in
the IETF).
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
