Subject: Re: [Netconf] [Rtg-yang-coord] YANG leaf writing to running-datastore

From: "Sterne, Jason (Jason)" <[email-masked]>
Date: Tue, 3 Mar 2015 13:42:20 +0000

Adding netconf into this as we're talking about generic netconf functionality here.

The concept of having other (somewhat arbitrary) data stores is something that may be useful for this "debug" type of configuration.  It may even make sense to have both a debug-running & a debug-startup datastore for debug (and perhaps a debug-candidate as well).  Some implementations effectively treat debug as a separate datastore (e.g. allow saving debug info separately from the rest of the configuration).

A similar approach may also make sense for Lawful Interception configuration which is often treated separately from the rest of config.

I think we'd have to extend the <hello> in some way to indicate which capabilities (which yang modules) apply to which datastores.

Jason

-----Original Message-----
From: Rtg-yang-coord [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Tuesday, March 03, 2015 5:12 AM
To: David Ball
Cc: Mahesh Jethanandani; [email-masked]
Subject: Re: [Rtg-yang-coord] YANG leaf writing to running-datastore

On Tue, Mar 03, 2015 at 09:55:30AM +0000, David Ball wrote:
> Wouldn't that be best done with an RPC?
>

An ephemeral data store would provide a generic solution for this kind of problem. RPCs tend to be specific (or you invent a generic RPC that actually models an ephemeral data store).

/js

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

_______________________________________________
Rtg-yang-coord mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtg-yang-coord

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 3 Mar 2015 14:57:10 +0100

Hi,

please consult the NETMOD physical interim minutes (September 2015)
and followup discussions on the I2RS list concerning ephemeral
datastores. If people find some of this useful, someone needs to
condense the ideas into an I-D. (Note that the motivation back then
was to deal with I2RS injected ephemeral config state.)

/js