Re: [Netconf] Draft Charter Proposal for NETCONF WG

[Juergen Schoenwaelder <[e-mail]>]

On Fri, Mar 03, 2017 at 06:41:06PM +0000, Eric Voit (evoit) wrote:
> > From: Juergen Schoenwaelder, March 3, 2017 6:52 AM
> > 
> > On Fri, Mar 03, 2017 at 11:05:53AM +0000, Eric Voit (evoit) wrote:
> > >
> > >
> > > > From: Juergen Schoenwaelder, March 3, 2017 4:24 AM
> > > >
> > > > On Fri, Mar 03, 2017 at 01:01:10AM +0000, Alexander Clemm wrote:
> > > > >
> > > > > An operator doesn't want external systems to individually address
> > > > > every
> > > > control plane VM.  Rather they want a YANG model for this
> > > > logical+physical combination.  In this case each VM might use Peer
> > > > (data) Mount to build a multi-device abstraction.  BTW: doing it
> > > > this way also allows the same mounted YANG object data to be
> > > > addressably exposed for each VM without requiring another YANG model to
> > be made.
> > > > >
> > > >
> > > > My question since the very beginning is: Is the idea to run
> > > > configuration editing transactions across mount points?
> > >
> > > My position is that there is huge value in read only access.  I have no desire to
> > champion edit operations.
> > >
> > 
> > Reading data of course has value but then NETCONF has this little 'CONF' in its
> > name...
> > 
> > Anyway, if the peer mount is designed as a read-only access mechanism, how
> > are the VMs then configured? I suppose there then needs to be a different
> > addressing mechanism to access the VM's configuration data, e.g., something
> > Andy was hinting at. Or how does this work?
> 
> There are lots of ways to approach this problem, but for this particular use case often it is unnecessary.   Configuration attempts from outside the box are often supposed to be global or VM agnostic across the box.  So each of the VMs then simply Peer Mount the global configuration data.  This eliminates lots of error-cases as it becomes very hard to push configuration data out of synch as you aren't exposing ways to do this.
>

Which particular use case are we providing a solution for?

I understand edit transactions crossing mount points is not needed for
the particular use case. Does your particular use case support editing
transactions within a mount point? Or is your particular use case a
completely read-only mount and applications have to use an entirely
different access mechanism to make any changes? Or is the particular
use case applications that never change anything?

/js

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