Re: [netconf] Defaults and NP containers in YangPush

["Rob Wilton (rwilton)" <[e-mail]>]

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 <[e-mail]> 
Sent: 13 December 2019 11:16
To: Rob Wilton (rwilton) <[e-mail]>
Cc: Martin Bjorklund <[e-mail]>; balazs.lengyel=[e-mail]; [e-mail]; [e-mail]
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:
> 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 <[e-mail]> On Behalf Of Martin Bjorklund
> Sent: 12 December 2019 08:57
> To: balazs.lengyel=[e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Re: [netconf] Defaults and NP containers in YangPush
> 
> Hi,
> 
> 
> Balázs Lengyel <balazs.lengyel=[e-mail]> wrote:
> > 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 ?
> 
> 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
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>