Subject: [netconf] Defaults and NP containers in YangPush

From: Balázs Lengyel <[email-masked]>
Date: Wed, 11 Dec 2019 14:00:50 +0000

Hello,

If I have the data model 

container cont1 {

presence “xx”;

  container cont2 {

    leaf leaf1 {

      type string;

      default ddd;

}}}

And I create cont1 

*	should Yang-Push report cont2 or leaf1 as created?
*	Is this affected by with-default ?

Regards Balazs

-- 

Balazs Lengyel                    Senior Specialist
Ericsson Hungary Ltd. 

Mobile: +36-70-330-7909              email: [email-masked]

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 12 Dec 2019 09:57:09 +0100 (CET)

Hi,

Balázs Lengyel <balazs.lengyel=[email-masked]> wrote:
> presence xx;

Great question!

I think it must be affected by the server's basic-mode for
with-defaults.

My assumption is that we want the subscriber to be able to keep a copy
of the data on the publisher, and we must allow different default
handling strategies in this copy - i.e., allow different
implementation strategies.

[Another way of viewing this is that if we pass the data in the notif
back to the server in an edit-config, it should effectively be a
no-op.]

So, a 'report-all' server will send 'leaf1' in the notif, but an
'explicit' or 'trim' server will not send it.

Here's another case.  After your operation above, suppose a client
sets 'leaf1' to 'ddd'.  A 'trim' server will not include 'leaf1' in
the notis, but an 'explicit' will include it.  (And a 'report-all'
server will not see a change at all, since 'leaf1' already had
'ddd').

This means that the subscriber may need to be aware of the server's
basic-mode, in order to be able to correctly interpret the notifs.

/martin

---

From: Balázs Lengyel <[email-masked]>
Date: Thu, 12 Dec 2019 13:34:22 +0000

-----Original Message-----
From: netconf <[email-masked]> On Behalf Of Martin Bjorklund
Sent: 2019. december 12., csütörtök 9:57
To: balazs.lengyel=[email-masked]
Cc: [email-masked]; Mark Hollmann <[email-masked]>
Subject: Re: [netconf] Defaults and NP containers in YangPush

Hi,

Great question!

I think it must be affected by the server's basic-mode for with-defaults.

My assumption is that we want the subscriber to be able to keep a copy of the data on the publisher, and we must allow different default handling strategies in this copy - i.e., allow different implementation strategies.

[Another way of viewing this is that if we pass the data in the notif back to the server in an edit-config, it should effectively be a no-op.]

So, a 'report-all' server will send 'leaf1' in the notif, but an 'explicit' or 'trim' server will not send it.

Here's another case.  After your operation above, suppose a client sets 'leaf1' to 'ddd'.  A 'trim' server will not include 'leaf1' in the notis, but an 'explicit' will include it.  (And a 'report-all'
server will not see a change at all, since 'leaf1' already had 'ddd').

This means that the subscriber may need to be aware of the server's basic-mode, in order to be able to correctly interpret the notifs.

/martin
_______________________________________________
BALAZS2:  I agree with you, because this way if the client reacts to all these notifications with additional edit-config operations, it will receive the expected results considering the potential error messages for create and delete operations. 

Regards Balazs

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 13 Dec 2019 11:04:21 +0000

Hi Martin,

I've not thought deeply about this, but I also probably agree with you.

However, I'm not sure that your position is necessarily obvious.  Hence, it might be nice if this was formally specified somewhere.  I also think that the "with-defaults" behaviours shouldn't necessary apply the same way to all datastores.  E.g. a server might want to choose "explicit" mode for <running>, but perhaps "trim" or "report-all" for <intended>.

Maybe there should be a bis version of RFC 6243 ... covering datastores and YANG push.

Thanks,
Rob

-----Original Message-----
From: netconf <[email-masked]> On Behalf Of Martin Bjorklund
Sent: 12 December 2019 08:57
To: balazs.lengyel=[email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [netconf] Defaults and NP containers in YangPush

Hi,

Great question!

/martin
_______________________________________________
netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Fri, 13 Dec 2019 11:16:08 +0000

For me, "explicit" is the only sane mode. We enhance interoperability
if we would converge to that instead of making things more complex by
allowing per datastore different default handling modes. This is
leading into the wrong direction if you ask me.

/js (in explicit mode)

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 13 Dec 2019 11:50:59 +0000

Hi Juergen,

I'm all for keeping things simple and homogeneous.

For client writable configurable datastores then I completely agree with you that "explicit" is the sanest basic mode, and I support converging on that.  If devices want to optionally support returning the contents with-default versions of that data on a per query basis then that is fine with me.

But for <operational>, RFC 8526 effectively specifies:
 - if no "with-default" parameter is specified, then the values returned are the "in-use" values, i.e. really much closer to the "report-all" default mode.
 - "report-all-tagged" and "trim" MAY be specified and return different output.

For <intended>, I would be happy if we agreed on what basic mode that datastore should default to, and what other optional with-default modes are allowed, but for this datastore it isn't obvious to me that "explicit" is necessarily the right choice.

Either way, I think that it would be helpful to refine what we have standardized so far, and make sure that the behaviour is well specified.  At the moment, it doesn't seem to be.

Thanks,
Rob

-----Original Message-----
From: Schönwälder, Jürgen <[email-masked]> 
Sent: 13 December 2019 11:16
To: Rob Wilton (rwilton) <[email-masked]>
Cc: Martin Bjorklund <[email-masked]>; balazs.lengyel=[email-masked]; [email-masked]; [email-masked]
Subject: Re: [netconf] Defaults and NP containers in YangPush

For me, "explicit" is the only sane mode. We enhance interoperability if we would converge to that instead of making things more complex by allowing per datastore different default handling modes. This is leading into the wrong direction if you ask me.

/js (in explicit mode)

On Fri, Dec 13, 2019 at 11:04:21AM +0000, Rob Wilton (rwilton) wrote:
> > presence "xx";

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Fri, 13 Dec 2019 12:17:29 +0000

>  - "report-all-tagged" and "trim" MAY be specified and return different output.

For <operational> you get the "in-use" values except if you use the
OPTIONAL to implement "with-defaults" parameter and you set it to
"trim".

Perhaps we should drop that since you can filter on origin.

> Either way, I think that it would be helpful to refine what we have
> standardized so far, and make sure that the behaviour is well
> specified.  At the moment, it doesn't seem to be.

Filtering on origin looks like a much cleaner and more flexible
solution. OK, origin annotations may not be available in <intended>,
but they could be meaningful for some implementations that do not
strictly follow Fig. 2 of RFC 8342 by allowing insertion of say system
config data into intended that is not stricly coming out of <running>.

/js